WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 5 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:

Description

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 5 years ago.
wp-settings.php.2.diff (843 bytes) - added by sirzooro 5 years ago.
PLUGINDIR/MUPLUGINDIR should be relative to ABSPATH
wp-settings.php.3.diff (1.1 KB) - added by sirzooro 5 years ago.
3rd attempt - check if plugin dir is within ABSPATH

Download all attachments as: .zip

Change History (11)

@sirzooro5 years ago

comment:1 @dd325 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...

comment:2 @sirzooro5 years ago

OK, I see. My mistake :)

2nd patch addresses this.

@sirzooro5 years ago

PLUGINDIR/MUPLUGINDIR should be relative to ABSPATH

comment:3 @dd325 years ago

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

@sirzooro5 years ago

3rd attempt - check if plugin dir is within ABSPATH

comment:4 @strider725 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. ;-)

comment:5 @sirzooro5 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?

comment:6 @hakre5 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.

comment:7 @sirzooro5 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.

comment:8 @westi5 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.