Update: It appears that the Woo Themes guys have fixed this problem. Yay!

We deliver all the sites for our clients using Subversion. Part of making that work is that we move the custom content from it’s usually location in wp-content to a separate folder outside the regular WordPress structure. In particular, this means we have a folder structure like this:

It works quite well, since we don’t actually use the wp-content folder and when we need to roll out changes to a lot of sites, we just issue Subversion switch commands to the Wordpress folder and all the content folders remain unaffected.

We’ve found that several of the WooThemes, though, have hard-coded the wp-content folder in them. Just a single handy example is Busy Bee, line 172 of the includes/admin-custom.php file:

We’ve fixed this by replacing it with this:

Similarly, we’ve replaced references to the content folder URL, like on line 173 of that same file:

with this:

We included the uploads folder in this case so that the woo_custom folder would appear in a subfolder of uploads rather than as a peer of that folder. The reason there is that we also use Subversion to periodically back up and retain revision history on our clients’ uploads folder.

The ability to use this alternate install path structure was introduced in WordPress v2.6.

We’re defining the two constants referenced above in the wp-config.php file, which we moved up one folder from the core install for the same reasons described above.

It would be really great if WooThemes referenced the content folder and content URL using these constants, which can also be conditionally defined in the WooThemes core system as described in the above article on wordpress.org. We wouldn’t need to go through and “fix” the themes for our clients as we build out their sites, but it wouldn’t require any additional effort on the part of WooThemes users who are using the traditional installation paths.