Title: WP_CONTENT_DIR Last modified: September 18, 2016 --- # WP_CONTENT_DIR * [somedev](https://wordpress.org/support/users/somedev/) * (@somedev) * [9 years, 8 months ago](https://wordpress.org/support/topic/content_dir/) * _[ Moderator note: [moved to How-to and Troubleshooting](https://wordpress.org/support/topic/wheres-my-topic-gone?replies=1&view=all).]_ * 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. - This topic was modified 9 years, 8 months ago by [somedev](https://wordpress.org/support/users/somedev/). - This topic was modified 9 years, 8 months ago by [Jan Dembowski](https://wordpress.org/support/users/jdembowski/). Viewing 5 replies - 1 through 5 (of 5 total) * [Clayton James](https://wordpress.org/support/users/claytonjames/) * (@claytonjames) * [9 years, 8 months ago](https://wordpress.org/support/topic/content_dir/#post-8194476) * > 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? - This reply was modified 9 years, 8 months ago by [Clayton James](https://wordpress.org/support/users/claytonjames/). * Thread Starter [somedev](https://wordpress.org/support/users/somedev/) * (@somedev) * [9 years, 8 months ago](https://wordpress.org/support/topic/content_dir/#post-8195594) * [@claytonjames](https://wordpress.org/support/users/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 9 years, 8 months ago by [somedev](https://wordpress.org/support/users/somedev/). - This reply was modified 9 years, 8 months ago by [somedev](https://wordpress.org/support/users/somedev/). * [Clayton James](https://wordpress.org/support/users/claytonjames/) * (@claytonjames) * [9 years, 8 months ago](https://wordpress.org/support/topic/content_dir/#post-8195806) * > 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](https://codex.wordpress.org/Determining_Plugin_and_Content_Directories). * > 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 * [Most developers don’t use WP_CONTENT_DIR because it’s one of the constants that shouldn’t be used in themes or plugins. ](https://codex.wordpress.org/Determining_Plugin_and_Content_Directories#Constants) * Thread Starter [somedev](https://wordpress.org/support/users/somedev/) * (@somedev) * [9 years, 8 months ago](https://wordpress.org/support/topic/content_dir/#post-8200239) * Clayton, you’re not exactly understanding the issue, but that’s okay, it’s been added to the core dev team’s bug list to address soon. This thread can be closed. * [Clayton James](https://wordpress.org/support/users/claytonjames/) * (@claytonjames) * [9 years, 8 months ago](https://wordpress.org/support/topic/content_dir/#post-8200267) * [@somedev](https://wordpress.org/support/users/somedev/) * 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! Viewing 5 replies - 1 through 5 (of 5 total) The topic ‘WP_CONTENT_DIR’ is closed to new replies. ## Tags * [wp-content](https://wordpress.org/support/topic-tag/wp-content/) * In: [Fixing WordPress](https://wordpress.org/support/forum/how-to-and-troubleshooting/) * 5 replies * 2 participants * Last reply from: [Clayton James](https://wordpress.org/support/users/claytonjames/) * Last activity: [9 years, 8 months ago](https://wordpress.org/support/topic/content_dir/#post-8200267) * Status: not resolved ## Topics ### Topics with no replies ### Non-support topics ### Resolved topics ### Unresolved topics ### All topics