#20710 closed defect (bug) (duplicate)
Error returned when using "Add New" plugin link in the navigation menu
Reported by: | kraftbj | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 3.4 |
Component: | Administration | Keywords: | |
Focuses: | Cc: |
Description
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.
Change History (15)
#2
@
12 years ago
- Keywords reporter-feedback removed
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.
#3
follow-ups:
↓ 5
↓ 6
@
12 years ago
- Resolution set to invalid
- Status changed from new to closed
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.
#5
in reply to:
↑ 3
@
12 years ago
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.
#6
in reply to:
↑ 3
@
12 years ago
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.
#7
follow-up:
↓ 8
@
12 years ago
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
#8
in reply to:
↑ 7
@
12 years ago
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.
#9
follow-up:
↓ 10
@
12 years ago
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.
#10
in reply to:
↑ 9
@
12 years ago
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.
#11
@
12 years ago
Actually, nevermind - has nothing to do with a plugin. It's just a file itself - fail on the developer who made that plugin.
#12
@
12 years ago
- Confirmed that it was due to /plugins/plugin-install.php filename issue.
- 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.
#13
@
12 years ago
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.
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