Issues enqueueing parent & child theme stylesheets with revised Codex method

QUESTION 1

Is it safe to include the assumption that parent themes properly enqueue the child theme styles, from the standpoint of child theme standards?

General rule of thumb, yes. But, you should never assume. Most disasters and failures in live are due to assumptions or facts based on an assumption

FACTS WITHOUT ASSUMPTIONS

• A child theme’s functions.php is loaded first, then the parent’s functions.php. This ensures that the the parent theme’s main stylesheet is loaded before the child theme’s main stylesheet from the updated code in the codex

• Lets look at the bundled theme, twentytwelve. The magic happens here wp_enqueue_style( 'twentytwelve-style', get_stylesheet_uri() );. This is how the main stylesheet is enqueued. When the theme is active as a parent theme, the style.css will be loaded from the parent theme as get_stylesheet_uri() will be pointed to the parent directory’s style.css.

• When you switch to a child theme, get_stylesheet_uri() “changes” its path to point to the child theme’s style.css, meaning now that instead that wp_enqueue_style( 'twentytwelve-style', get_stylesheet_uri() ); loading the parent style.css, it now loads the child style.css

• All other styles from the parent theme are loaded as per normal in the order that they written

POTHOLES

• Inline styles and stylesheets that are added directly to your header template. I have done some testing on this issue. If the parent stylesheet is not enqueued using wp_enqueue_scripts and directly loaded in the header, then the child theme’s main stylesheet is loaded first. As a workaround here, I have previously recommended to copy the header.php of the parent to the child theme and removing those calls. You will then have to enqueueu both the parent and child theme styles and any other stylesheets that was directly loaded in the header.php as decribed in the OP depreciated function

• I have came across this once or twice where styles (and scripts) are directly loaded in the header, and because of this the call to wp_head is omitted. This will make you enqueue action fail silently, so your styles will simply not show up.

• Wrong priorities set. It is not necessary to set priorities is either parent and child actions when you hook your enqueueu functions. When both have the same default priority, the rule of first come, first served apply. This will ensure that the loading order is correct

NOTE TO PARENT THEME AUTHORS

The proper accepted method to add styles and scripts to a theme is through the wp_enqueue_scripts action hook. Never add styles and scripts directly in the header template, and don’t set any priority in your action when hooking your function

Always also load the main stylesheet as follows:

wp_enqueue_style( 'twentytwelve-style', get_stylesheet_uri() );

This will ensure that the child’s main stylesheet is loaded when a child theme is in use

YOUR RESPONSIBILTY AS A CHILD THEME AUTHOR

• Take your time and work through the parent theme. Know your parent theme, make sure you are comfortable with the theme structures and how functions and hooks are used in the theme. You cannot create a successful child theme if you don’t have inside knowledge of how the parent theme works. It is your responsibilty to make sure that styles and scripts are properly loaded in order for your code to work as expected.

• Always make the parent theme author alert of any code you are not happy with. For instance, if the author added his styles directly to the header, make him alert of that and make him aware that this is the wrong way of doing it, and ask him to correct this in a future release

QUESTION 2

Removing the priority could potentially create more confusion for part of the WordPress community, when child theme styles start getting overwritten by a plugin. We expect themes to overwrite styles, but not so much with plugins

Unfortunately there are no direct method to safegaurd against this. The point of fact here is, plugin styles should never overwrite default theme styles without the consent of the end user. In my opinion, this is just bad practice or neglet from the plugin author. I would suggest that in a case like this, contact the plugin author and make him alert about this

You also always have the option to dequeue and deregister a style (and script) that you don’t need, or which you need to change the priority of and requeueing and reregistering them as in your code above (which is perfectly fine). Just a note on your shivm, it is best practice to dequeue and to deregister a style and script.

QUESTION 3

When using a custom stylesheet for the actual child theme styles (as supposed to putting them in the predefined style.css), manually enqueueing that file becomes necessary. In terms of maintaining continuity across a wide spectrum of developers, wouldn’t it make sense to encourage manually enqueueing the child stylesheet regardless of the possible duplicate?

I don’t think there is any direct black and white answer to this issue. I would answer by saying, do what you are comfortable with as long as it is within a certain guideline which governs the action.

Stylesheets are not there to add functionality, but are there to add visual experience to the user. Styles are also directly send as-is to the browser were it is processed. WordPress plays no role here.

Based on this fact, I really don’t see any threatening red flags in loading a stylesheet twice. This might cost a few miliseconds in performance though. To be honest, apart from this, I’m not really sure how are duplicates handled across diffirent browsers. This is something that you as a reader can go and test

IMHO, duplicates are never good and should always be avoided. I would suggest that if you really want to manually enqueue the child’s main stylesheet for what ever reason, you should make use of your code in your shivm. Dequeue and deregister the duplicate added by default and then requeueing the stylesheet as normal.

Just one thing to remember as well, the enqueue and register functions have a $dependancy parameter that you can also make use of. So it is easy to load a secondary stylesheet and making it dependant on the main stylesheet of your child theme

IN CONCLUSION

Since the recent update of the codex, the feedback has been amazing and I would like to thank everyone’s feedback on this. I would like to encourage everyone to participate in any type of feedback to this question in particular. If you have anything to add or comment on, please do.