You’re providing the argument menu-order to wp_insert_post() rather than the correct menu_order, and as such, the order of the duplicated menu is not correct.
I currently have the following workaround in place:
add_filter('wp_insert_post_data', function ($data, $postarr) {
if ($data['post_type'] === 'nav_menu_item' && isset($postarr['menu-order'])) {
$data['menu_order'] = (int) $postarr['menu-order'];
}
return $data;
}, 10, 2);
]]>
When a menu is duplicated, metadata is duplicated as well, and the original metadata is checked to see if it is serialized. When unserialize is fed data that is not serialized, in addition to returning false, it also throws a E_NOTICE.
WordPress has a helper function called maybe_unserialize which checks to see if data is serialized first, and also squelches any potential error output from unserialize. This function should probably be used instead of the conditional that checks for a false from unserialize
We are currently testing version 1.1.0. This version has a lot of underlaying changes and we want to make sure this works for everyone before pushing it out.
This version should solve issues with third-party plugins like duplicating addional menu fields. It also contains multiple bugfixes.
If everything goes well, we are planning to release this version to the stable channel in a few weeks.
]]>Creates a copy of the menu and just adds 1 /1st item to it.
]]>A fatal crash happens when server settings and debug is activated in this line : bcm-duplicate-menu.php:50
There should be a check for “isset($_GET[‘menu’])” before trying to access it because by default, when we arrive in the menu editing screen, there’s no menu specified in the query string. Doesn’t crash on most live installs because debug isn’t activated, but most devs have this activated.
]]>When duplicate a menu, images(primary and secondary) does not get copied. also the sizes.
Can you do that pls? ??
thanks in advance