WordPress.org

Make WordPress Core

Opened 13 years ago

Last modified 10 years ago

#6938 closed enhancement

Allow wp-content directory to exist in a custom location (relative to ABSPATH) — at Version 9

Reported by: sambauers Owned by:
Milestone: 2.6 Priority: normal
Severity: normal Version: 2.5.1
Component: General Keywords: has-patch
Focuses: Cc:

Description (last modified by ryan)

This enhancement is related to ticket #6933, with similar reasoning.

  1. It's a little more secure if wp-content happens to also be outside the webroot
  2. It allows us to add WordPress as an external repository in other projects with plugins/themes/cache engines/database classes that sit outside that external repository (we do some of this with bbPress)

WordPress requires a few changes as there are a few hard-coded references to wp-content.

If we don't like the constant name I chose ( WP_CONTENT_DIR ), then that can be easily changed in the patch.

This will almost certainly break a few plugins where wp-config is hard-coded, but only when the blog owner chooses to use this feature. Naughty plugins should use API calls anyway :)

Change History (11)

#1 @mdawaffe
13 years ago

+1

There were some false starts to allow the plugins dir, themes dir, languages dir to be defined individually: #4039 (and maybe others).

Note that you'll also need to define WP_CONTENT_URL or something similar and have the various plugin and theme functions reference that instead of get_option( 'wp_url' ) (or whatever it is).

#2 @sambauers
13 years ago

mdawaffe raised a point on IRC that some file path sanitisation function may not like the idea of relative paths i.e. the ".." in the paths. This would need checking.

Also, directory traversal may not be allowed on some hosts in PHP safe mode, but I think it's OK to have a feature that isn't available to PHP safe mode users. IN any case, this change doesn't alter or break the default behaviour.

#3 @sambauers
13 years ago

Missed some hard-coded references in the previous patch.

#4 follow-up: @ryan
13 years ago

Can we make WP_CONTENT_DIR be an absolute path so that we don't have to worry with ".."? Things like PLUGINDIR that expect it to be relative to root will need to be changed around. Something like:

define( 'WP_CONTENT_DIR', ABSPATH . 'wp-content' );
define( 'WP_CONTENT_URL', 'wp-content'); // Relative to get_option('home'), not ABSPATH
define( 'WP_PLUGIN_DIR', WP_CONTENT_DIR . '/plugins');
define( 'WP_PLUGIN_URL', WP_CONTENT_URL . '/plugins'); // Used for plugin_basename()
define( 'PLUGINDIR', 'wp-content/plugins'); // Relative to ABSPATH.  For back compat.

Calculating WP_CONTENT_URL will require stripping get_home_path() from ABSPATH to get a path relative to home rather than siteurl.

#5 in reply to: ↑ 4 @sambauers
13 years ago

Replying to ryan:

Can we make WP_CONTENT_DIR be an absolute path so that we don't have to worry with ".."?

Sounds good and I was already looking at doing this based on some conversations with mdawaffe.

I was also uncomfortable with the dotted relative paths. I'll produce another patch which does this in a more complete and clean fashion.

#6 @sambauers
13 years ago

A more thorough patch now attached mostly based on comments by ryan.

WP_CONTENT_DIR - full path
WP_CONTENT_URL - full url
WP_PLUGIN_DIR - full path
WP_PLUGIN_URL - full url
WP_LANG_DIR - full path

Deprecated constants declared with limited backwards compatibility.

PLUGINDIR
LANGDIR

#7 @sambauers
13 years ago

Trac formatting fails me again... along with not previewing...

A more thorough patch now attached mostly based on comments by ryan.

  • WP_CONTENT_DIR - full path
  • WP_CONTENT_URL - full url
  • WP_PLUGIN_DIR - full path
  • WP_PLUGIN_URL - full url
  • WP_LANG_DIR - full path

Deprecated constants declared with limited backwards compatibility.

  • PLUGINDIR
  • LANGDIR

#8 @ryan
13 years ago

(In [7999]) Allow wp-content to exist outside of webroot. Props sambauers. see #6938

#9 @ryan
13 years ago

  • Description modified (diff)
Note: See TracTickets for help on using tickets.