Make WordPress Core

Opened 12 years ago

Closed 12 years ago

Last modified 11 years ago

#20710 closed defect (bug) (duplicate)

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

Reported by: kraftbj's profile 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)

#1 @SergeyBiryukov
12 years ago

  • Keywords reporter-feedback added

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

#2 @kraftbj
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: @kraftbj
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.

#4 @SergeyBiryukov
12 years ago

  • Milestone Awaiting Review deleted

#5 in reply to: ↑ 3 @SergeyBiryukov
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 @griffinjt
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: @dd32
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 @griffinjt
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: @dd32
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 @griffinjt
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 @griffinjt
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.

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

Last edited 12 years ago by griffinjt (previous) (diff)

#12 @kraftbj
12 years ago

  1. Confirmed that it was due to /plugins/plugin-install.php filename issue.
  1. 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 @griffinjt
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.

#14 @kraftbj
12 years ago

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.

#15 @SergeyBiryukov
11 years ago

  • Resolution changed from invalid to duplicate

Duplicate of #22079.

Note: See TracTickets for help on using tickets.