Error returned when using "Add New" plugin link in the navigation menu

[kraftbj]

In latest 3.4 nightly (20825), when clicking on the "Add New" Plugin link in the side navigation bar directs admin to /wp-admin/plugins.php?page=plugin-install.php which returns "You do not have sufficient permissions to access this page."

Clicking on "Add New" on the plugins page (e.g. /wp-admin/plugins.php) directs user to /wp-admin/plugin-install.php which works as it should.

I'd like to patch this, but new to diving into the core code and unsure where to look into the code to attempt a patch.

Which link are you referring to? The one in the admin menu leads to wp-admin/plugin-install.php:

http://core.trac.wordpress.org/browser/trunk/wp-admin/menu.php?rev=20449#L160

This is the page source, as it is rendering for me (when at /wp-admin/plugins.php, although it exists for the flyout when on other pages too):

​https://gist.github.com/2732761 -- notice line 16.

To confirm, I'm running 3.4-beta4-20825 with no plugins active currently (some had been previously). I verified that my source code for /wp-admin/menu.php at 160 matches what trunk is showing.

I had a plugin based on TGM-Plugin-Activation in my /wp-content/plugins/ folder (not activated). The presence of the file changed the link.

Deleted the file, expected activity resumed. Strange to me that an unactivated plugin would cause the issue, but new to core.

Replying to kraftbj:

Strange to me that an unactivated plugin would cause the issue, but new to core.

Generally, the code from non-active plugins doesn't get included. Perhaps this has to do with how TGM-Plugin-Activation handles plugins.

Replying to kraftbj:

I had a plugin based on TGM-Plugin-Activation in my /wp-content/plugins/ folder (not activated). The presence of the file changed the link.

Deleted the file, expected activity resumed. Strange to me that an unactivated plugin would cause the issue, but new to core.

You deleted the plugin file or the TGM Plugin Activation file? Can I ask what version of TGMPA and can I see how the person registered the plugin? In all likelihood, there is an error on the developer end with registering the plugins, but I'd like to see the code to rule out other possibilities.

This sounds like it was caused by a file directly in WP_PLUGIN_DIR called 'plugin-install.php'.

The WordPress admin menu has some weird code in there, that I honestly don't know how much would still be used:
http://core.trac.wordpress.org/browser/trunk/wp-admin/menu-header.php#L151

Put basically, If a $file is provided in a menu registration, it first checks to see if that exists in the plugins directory, and if it does, redirects it to the $parent?page=$file on the parent, If the file doesn't exist, it directs it to /$file

Replying to dd32:

Put basically, If a $file is provided in a menu registration, it first checks to see if that exists in the plugins directory, and if it does, redirects it to the $parent?page=$file on the parent, If the file doesn't exist, it directs it to /$file

What would be a use-case for that? Backwards compat? Seems like an odd piece of code.

What would be a use-case for that? Backwards compat? Seems like an odd piece of code.

Back-compat for a looong time ago, when plugins registered menu's directing to specific files rather than a slug+function is my guess.

Any plugin that passes a __FILE__ to add_sub_menu() (or the other variants of it) and don't specify a callback function will trigger it.

Replying to dd32:

Any plugin that passes a __FILE__ to add_sub_menu() (or the other variants of it) and don't specify a callback function will trigger it.

Since inactive plugins can still trigger this, there should be probably be a check (although I don't know how feasible it is in this case) to make sure that the plugin from which the file is being called is actually active before it adds that particular menu item.

Actually, nevermind - has nothing to do with a plugin. It's just a file itself - fail on the developer who made that plugin.

And now I see your comment where you say just that. :-)

1. Confirmed that it was due to /plugins/plugin-install.php filename issue.

2. The plugin was a part of an install script that would auto-install the latest WP, install a pre-determine theme, add the TGM-Plugin-Activation-based plugin to load other 'standard' plugins, delete Twenty-Ten, etc for ease in starting a new client project. The plugin-install.php plugin would be deleted very early on as soon as the standard plugins were installed. I just never left it in there long enough to discover this little feature of WordPress.

I was using a fork of the script. I've notified the original author to make sure he's aware of the clash. Thanks all for educating me on what happened.

Ahh, you are using Jared's WP Prep script - tsk tsk Jared. :-) But who would've known? I'm sure he'll get it fixed up right away when you mention it to him.

Heh, yeah, didn't want to mention his name. :-) It's a handy script. I just submitted a pull request to the github repo so it'll be fixed for the world soon enough.

Duplicate of #22079.