When doing a text search of the WordPress 4.6.1 install, as well as previous recent versions, there are many file paths with the wp-content folder hard-coded into the core. This causes the WP_CONTENT_DIR feature to break, in my estimation. Can anyone else verify this? What’s the point of having the functionality of changing the wp-content directory if new code breaks it?
In addition, this has been an issue in the past, including the themes folder path being broken because the core was not even considering WP_CONTENT_DIR at times. I did two weeks of solid testing on this one issue using a completely new 4.6, completely new 4.6.1, and zero plugins. It seems to be a real problem that has been overlooked or neglected.
]]>When doing a text search of the WordPress 4.6.1 install, as well as previous recent versions, there are many file paths with the wp-content folder hard-coded into the core. This causes the WP_CONTENT_DIR feature to break, in my estimation
WP_CONTENT_DIR is one of several constants used to determine paths to directories, so yes, you’re going to see references to in the core files. Why – and be specific please – do you feel it’s breaking something by being there?
I did two weeks of solid testing on this one issue using a completely new 4.6, completely new 4.6.1, and zero plugins.
What exactly were your tests, and what result caused you to conclude that something was broken?
]]>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.
]]>I was specific and clear. Read my post again.
I read your post, thanks. However I really do appreciate you taking the time to clarify a bit for me.
, 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
If I more clearly understand your concern now, I think there could be a couple of reasons for that.
– You shouldn’t be hard-coding paths to the wp-content directory in themes and plugins.
]]>Most developers don’t use WP_CONTENT_DIR because of this kind of neglect in the WordPress dev process..
..At present, the themes folder crashes in 4.6.1 with WP_CONTENT_DIR invoked
Yeah, I must really be missing the boat on this one for some reason. There’s something I’m not seeing. I was under the impression that the WP_CONTENT_DIR constant was intended for use in the wp-config.php file in the event that the user wanted to move the location of the /wp-content directory. At least that’s how I’m using it, and it works perfectly for me in 4.6.1.
Thank you for being so patient. Can you please leave a link to the Trac ticket in this conversation for me? I would love to follow the conversation and see what I’m having difficulty understanding – as well as maybe finding out why defining WP_CONTENT_DIR in the wp-config.php file works perfectly on my server, but not yours. Thanks!