@claytonjames, I was specific and clear. Read my post again.
I’ll break it down more for you. To have a global and change the content directory, it’s necessary for new code to respect that and use the global when creating file paths pointing to the content directory. So when a dev adds new code and forgets this and hard codes the default directory of “wp-content”, that completely disregards the global. If an install uses WP_CONTENT_DIR, the core breaks. Not because of the global, but because somebody hard coded the path and didn’t reference the global at all. Thus, the use of a global causes the install to crash, but the bug is not the global, the bug is the lack of reference to a global in content folder file paths.
For most WordPress installs that don’t use WP_CONTENT_DIR they won’t notice.
Most developers don’t use WP_CONTENT_DIR because of this kind of neglect in the WordPress dev process, so they won’t notice either. Better safe than sorry I suppose.
If you do a text scan of the wordpress core, all references to “wp-content” should be in respect of the global. Anything beyond this is questionable. To start with, why don’t you do a scan of the core yourself and look at all the hard-coded wp-content references in some of the new code.
This is without any plugins installed. Of course, if a plugin is developed that does not reference WP_CONTENT_DIR in the file path to content, and hard codes the “wp-content” directory in the file path, then that plugin will also crash when used in a WordPress install where WP_CONTENT_DIR has been invoked in the config file.
At present, the themes folder crashes in 4.6.1 with WP_CONTENT_DIR invoked. There are other bugs, but the approach should be to scan the whole core using a text editor and make note of any questionable use of “wp-content” hard-coded into the code where it should be the global reference instead.
-
This reply was modified 8 years, 2 months ago by somedev.
-
This reply was modified 8 years, 2 months ago by somedev.