Add Object Page has no Position Parameter

[chriscct7]

I found this bug while installing Easy Digital Downloads, and then proceeding to install Contact 7. What happens is, Contact 7 has a menu conflict with EDD, so that EDD drops off the menu. While looking into this Pippin (EDD's author) informed me of a similar issue with Gravity Forms and EDD. Both were using add_object_page, a function previously unknown to me. So I looked it up in the [Codex](​http://codex.wordpress.org/Function_Reference/add_object_page) where it says that there's an optional position parameter. Contact 7 was not using it, so I added it to their add_object_page call and time and time again nothing happened. I noticed on the Codex page it says "This essentially does the exact same thing as add_menu_page() in case you're wondering." So I swapped that in and the menu position of Contact 7 changed, thus restoring EDD.

So then, I became curious why Contact 7 always wants to be at the bottom. After all, at one point it's position parameter was even set to 1 and it was still at the bottom.

Yet you'll notice [here](​http://core.trac.wordpress.org/browser/tags/3.5/wp-admin/includes/plugin.php#L946) in the trunk for WP 3.5 and also verified in 3.4.2 that there is ,in fact, no position parameter in that call.

Therefore, the Codex article is wrong. However, seeing that plugins are clashing over a lack of position parameter, I would suggest:

1. Parameter be added for position
2. Position parameter should be mandatory. This will prevent countless plugin conflicts while only requiring two extra characters for programmers.

I also propose the position parameter be changed to mandatory for add_menu_page as well.

[nacin]

I went ahead and removed the parameter from the Codex.

add_menu_page() should simply be used in lieu of add_object_page().

[mordauk]

Is there a reason menu_position isn't supported by add_object_page()?

[ocean90]

add_object_page() and add_utility_page() are just wrappers which passes additionally $_wp_last_utility_menu++ to add_menu_page().

[SergeyBiryukov]

Related: [9537], [9949], [11856].

Position parameter should be mandatory. This will prevent countless plugin conflicts while only requiring two extra characters for programmers.

I guess it will actually cause a lot more conflicts. From the Codex article on add_menu_page():

WARNING: if two menu items use the same position attribute, one of the items may be overwritten so that only one item displays!

Forcing plugin developers to come up with unique position parameters is not feasible. As noted above, add_menu_page() should be used instead, which uses the next available position if it's not specified:
​http://core.trac.wordpress.org/browser/tags/3.5/wp-admin/includes/plugin.php#L915

FWIW, I could not reproduce the original bug with Easy Digital Downloads 1.4.0.3 and Contact Form 7 3.3.2. All of the versions of Easy Digital Downloads I could find in the repository (from 1.0.1.1 to 1.4.0.3) use register_post_type() rather than add_object_page() to add the menu item.

[chriscct7]

EDD does use register_post_type(); Contact Form 7 is the plugin using add_object_page(). The issue is EDD's post registers at the bottom of the first bloc, which is also where add_object_page registers as well. The two cause menu conflict where EDD's post type menu item disappears.

[SergeyBiryukov]

Follow-up: #23108

[SergeyBiryukov]

Replying to chriscct7:

EDD does use register_post_type(); Contact Form 7 is the plugin using add_object_page(). The issue is EDD's post registers at the bottom of the first bloc, which is also where add_object_page registers as well. The two cause menu conflict where EDD's post type menu item disappears.

I see. But still, I can only reproduce the conflict if I manually add 'menu_position' => 26 to the register_post_type() call in EDD. Otherwise, $_wp_last_object_menu is properly incremented:
​http://core.trac.wordpress.org/browser/tags/3.5/wp-admin/menu.php#L108

[SergeyBiryukov]

#21445 was marked as a duplicate.