search

wesleytodd / YeoPress

A Yeoman generator for WordPress
Other
1.08k stars 163 forks source link

Problems with renaming /wp-content/ #79

Closed adaminfinitum closed 9 years ago

adaminfinitum commented 10 years ago

Preface: I originally asked this in the YouTube comments, and was asked by the original repo author to move it here.

In the video walk through you (smartly) change the default content directory from /wp-content/ to /content/. I have tried this myself, with this generator and with other WordPress sites (even brand new sites whose only content is the 'Hello World' post) and it always seems so problematic that I have abandoned trying.

Have you ever had problems with that and how have you overcome those problems?

Mostly, I am referring to other plugins which seem to rely on /wp-content/ to function. And I'm not talking about any possible obscure plugin, I try to use well supported, widely used plugins (WP SEO, Better WP Security, JetPack, Use Google Libraries, YARPP, Next Gen Gallery, Advanced Custom fields etc.)

In asking this, I suppose I could do a find and replace in all files but what about when any of those plugins (or others) releases an update, or WordPress itself comes out with an update? Along those same lines, what if it is site that my clients edit themselves and they try to install a plugin?

The number of problems (and potential problems) I have experienced with renaming /wp-content/ have caused me to give up on doing so. Am I missing something?

wesleytodd commented 10 years ago

I personally have never had any problems with this. I believe that most plugin authors know that that is a bad practice, and so they don't do it. Of the plugin's you listed, I only have experience with a coupple, JetPack and Advanced Custom Fields, none of which have had any problems with the path issue.

Also, if a developer is not aware of the issues with hard-coding paths in their plugins, I don't know that I would trust their plugin enough to use it. So my personal recommendation is to not use a plugin that has a problem with this setup.

Brendonwbrown commented 10 years ago

Agreed. Generally I avoid any plugin with a hard-coded plugin path. It shows laziness and incompetence and such a plugin will probably come with other errors.

adaminfinitum commented 9 years ago

How can I determine if a plugin has a hard-coded path?

What comes to mind is child themes which are coded like this: wp_enqueue_style( 'parent-style', get_template_directory_uri() . '/style.css' );

I assume get_template_directory_uri() means that this isn't "hard-coded" because it is effectively relative from where ever the theme is located. Is this correct?

Is this the type (even if not the exact syntax) of thing I'd want to look for when reviewing a plugin's code to determine if the path is hard coded and likely to be problematic?

I know this is sort of a novice question, so thanks for your patience with it.

Brendonwbrown commented 9 years ago

You are correct. A proper plugin should determine its directory using any number of a whole slew of Wordpress' preset functions. Please see here: http://codex.wordpress.org/Determining_Plugin_and_Content_Directories