Make WordPress Core

Opened 8 years ago

Closed 8 years ago

#11494 closed enhancement (wontfix)

Change way how PLUGINDIR and MUPLUGINDIR are defined

Reported by: sirzooro Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.9
Component: Upgrade/Install Keywords: has-patch
Focuses: Cc:


When someone uses non-standard plugin locations and forgot to define PLUGINDIR and MUPLUGINDIR (wpmu only), some plugins may break. These two defines exists for backward compatibility only, so I think they can point to the same location as WP_PLUGIN_DIR and WPMU_PLUGIN_DIR. Attached patch changes this.

Attachments (3)

wp-settings.php.diff (783 bytes) - added by sirzooro 8 years ago.
wp-settings.php.2.diff (843 bytes) - added by sirzooro 8 years ago.
wp-settings.php.3.diff (1.1 KB) - added by sirzooro 8 years ago.
3rd attempt - check if plugin dir is within ABSPATH

Download all attachments as: .zip

Change History (11)

#1 @dd32
8 years ago

Those constants are relative to ABSPATH, whereas the new constants are absolute to the filesystem.

You cannot use them interchangably, as you've found.

The only way around this, is to completely remove those constants, and force people to use the fucnction calls (plugin_url() etc).. Changing that in 3.0 since MU is merging would be a really good time honestly...

#2 @sirzooro
8 years ago

OK, I see. My mistake :)

2nd patch addresses this.

8 years ago


#3 @dd32
8 years ago

Thats assuming that the plugin directories are within ABSPATH.. A strpos(ABSPATH) > 0 ? substr() : 'wp-content/whatever'; might be better

8 years ago

3rd attempt - check if plugin dir is within ABSPATH

#4 @strider72
8 years ago

-1 on this.

If plugins are still using PLUGINDIR they need to be updated by the author. This patch makes bad assumptions and in many cases will be setting an incorrect path, which will in turn make things harder to troubleshoot.

There is no longer any "safe" way to set PLUGINDIR in code; because it is now valid for the plugin directory to be outside of ABSPATH. PLUGINDIR has been entirely supplanted by WP_PLUGIN_DIR.

I have no comment on MU constants, as I've never used it. ;-)

#5 @sirzooro
8 years ago

This is addressed by 3rd patch - it if PLUGINDIR is within ABSPATH first, and then either generates correct value or uses default (wp-content/plugins). BTW, maybe it will be good to die() instead of using default?

#6 @hakre
8 years ago

I actually do not undertand why plugins break. Do those plugins rely on optional constants? Please explain why something might break. Your patch touches fairly old code so I want so that double checked.

#7 @sirzooro
8 years ago

These plugins uses PLUGINDIR for loading translations or accessing other files within plugin's directory. When someone will redefine WP_PLUGIN_DIR and WP_PLUGIN_URL but forget about PLUGINDIR, plugin will not find these files.

The same for WPMU defines.

#8 @westi
8 years ago

  • Milestone 3.0 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Current patch incorrectly defines PLUGINDIR as wp-content/mu-plugins

I don't really see the benefit of this extra code.

When people are using WP_PLUGIN_DIR to move the plugin directory there are most likely moving it outside of ABSPATH completely and then PLUGINDIR can never be right.

The time invested in this ticket would be better spent on sending patches to the plugins which don't work when the new defines are used to fix them such that they do there by improving them.

Closing as WONTFIX as I don't see an end-user benefit in adding this extra code - it would be great if we could mark these as deprecated in a meaningful way such that we could hi-light there use like we do for old includes/functions.

Note: See TracTickets for help on using tickets.