It’s the most fiercely debated topic on Genesis forums – Should you or shouldn’t you update Genesis child themes? And, as importantly, how does this affect StudioPress best-practice of applying customisations directly to child themes.
Former StudioPress support rep Andrea Whitmer said it best in her excellent article, “No, You Don’t Need to Update Your Genesis Child Theme” –”Want to start a debate that will continue until all parties are too exhausted to keep going? Ask about methods or reasons for updating Genesis child themes – Days later, when you crawl out of the fray – bruised, broken, and determined never to ask a question again – you may still be looking for a recommendation.”
Yep. That about sums it up. Andrea’s article sets the background for this fiery debate and offers a well-articulated case for saying NO to Genesis child theme updates.
In this article, I present a case for saying YES to child theme updates. And at the risk of a few more bruises, I’ll illustrate why I believe the current best-practice is becoming outdated, impractical, potentially damaging, and should be reviewed.
Progress in the update debate.
Thankfully, the debate is evolving. StudioPress fundamentalists have shifted from “Genesis child themes don’t get updated” to “Genesis child themes don’t NEED to be updated”. A necessary step given that a quick scan of StudioPress child themes reveals that out of 95 child themes (as of October 2016), 76 have received updates with nearly half occurring this year.
This statistic is likely to climb. Why? The answer is as simple as it is compelling – the most innovative framework attracts the most innovative developers.
Genesis child themes aren’t limited to StudioPress. An expanding community of creative, forward-thinking theme developers are continually pushing the Genesis framework to new and exciting levels. As a result, many child themes are no longer just aesthetic skins, they’ve become virtual theme extensions, including more complex functions, scripts and even built-in support for external plugins such as WooCommerce.
StudioPress founder Brian Gardner recently confirmed in an interview with Matt Mullenweg that StudioPress itself “has put WooCommerce compatibility on the roadmap for its themes” – further evidence the Genesis child theme landscape is changing.
- We’re seeing an increase in quality third-party theme developers creating more child themes for the Genesis framework.
- StudioPress, while expanding its own child theme vision, recognises this external asset and is adding more third-party child themes to its store.
- Many of these child themes are more functionally complex, and so have a greater susceptibility to deprecated code.
- Many of these child themes include built-in support for third-party plugins and so are susceptible to updates in supported plugins.
- Developers are keen to ensure their themes are current by removing deprecated code, including new theme support features, and maintaining compatibility with supported plugins.
Add to this the ever-increasing speed at which web technologies, protocols and standards are advancing, plus the frequent addition of theme support features to comply, and I believe it’s a mistake to bury our heads in the sand with respect to child theme updates.
After all, as a user I want the latest version, and as a developer, I want my users to be equipped with the latest version. Andrea quite rightly claims, Genesis child themes, in most, don’t need to be updated. But, my argument is not whether you need to, it’s whether you should. And if there is an update available, why you wouldn’t?
So, why wouldn’t you update your child theme?
Those that don’t, and those that won’t, have two primary reasons –
- The belief that only the parent theme receives updates, not the child theme.
- Best-practice is to customise the child theme directly, and so updates will overwrite customisations.
Only the parent theme receives updates, not the child theme.
This line is usually followed by, “That’s the point!”. However, I’m not sure it IS the point given that Genesis child themes DO get updated and the trend is sure to increase.
It’s also important to acknowledge the difference between a standard parent theme and a framework. Adopting the StudioPress ‘car’ analogy, the framework is the chassis and the child theme is the ‘cherry red’ paintwork. Both are necessary. However, a standard parent theme stands alone. The child theme is optional and created only for ‘customising’. In the context of this debate, there is a profound difference.
Best-practice is to customise the child theme directly.
This is really at the core of the entire update debate. On a near-weekly basis, we witness the Genesis newbie querying where to place customisations so they’re not overwritten by child theme updates, only to be belted with an array of conflicting responses and best-practice recommendations which, in my mind, no longer make any practical sense.
It’s an escalating issue. Why? Because Genesis users, new and old, can quite clearly see that Genesis child themes are being updated and an undeniable conflict is presented if a user wants the freedom to apply updates while subscribing to best-practice.
Updating is a good habit.
If users are encouraged to update WordPress, to update the framework and plugins, why exclude child themes? This seems genuinely illogical to me. Not only does it blur the lines on good routine, but it places a site at greater risk of faltering due to incompatibility with its up-to-date components. Andrea’s article refers to a fear and bad habits contagion in the context of “freaking out” about updates. However, I’m more likely to “freak out” over ‘not updating’ than I am having the most compatible, most secure, most up-to-date version of a child theme.
The Danger.
I believe that in the long-term, clutching onto current best-practice may actually damage Genesis framework’s well-earned market position.
Business models thrive on innovation and harmony, and wither on uncertainty and dissension. In fact, it’s fair to say that innovation and harmony have been two cornerstones in the framework’s success! However, there is now a simmering level of frustration creeping into the Genesis community in regard to the update issue. And it’s growing –
- Genesis newbies are getting caught in the crossfire of the best-practice debate. And their confusion is warranted given they’re told Genesis child themes don’t get updated when clearly they do.
- Genesis veterans are clinging onto best-practice methods while becoming increasingly cognisant of the changing landscape in child themes.
- Genesis theme developers, who should be encouraged to stretch the boundaries and push the framework’s capacity forward, may be curbing their creativity, either consciously or subconsciously, over best-practice concerns and the fear that ‘something’ in their theme may, at some time, require updating.
These factors create a feeding ground for uncertainty and disagreement, and result in retardation, at some level, of an otherwise flourishing business model.
The knuckle-biting solution.
I believe most Genesis users would apply child theme updates if it was simple and safe to do so. Therefore, the solution is obvious.
Isolate customisations from the theme folder, making them update-safe.
There. I said it. It flies in the face of current best-practice. But, there won’t be any plagues, no floods or fires, we won’t descend into darkness. All we’ve done is acknowledged that the child theme landscape is changing and either discarded or adapted best-practice accordingly.
What are the negatives?
I’ve heard several reasons why custom code should not be separated from the theme folder, ranging in extremes from overridden code costing a site a few hundredths of a second in loading time, to endangering a client’s business! However, the most popular argument is that separate files or plugins can be dangerous.
This assumes that if an active theme is substituted for another, theme-specific customisations may see the site go haywire and the owner promptly committed to a mad-house. I believe this argument is lost with quality developers, however. Good code or a good plugin should include safety measures to block a code’s engagement if a related theme is not active. So, the result should be no different to substituting any other theme.
There is a risk, however, that a plugin is neglected by its developer and becomes obsolete, or that the plugin will be accidentally deleted by another admin. Both risks are negated by writing custom code direct to accessible plugin files rather than a database, and installing these files as a must-use (mu-) plugin to prevent deletion via WordPress admin. This can be achieved manually or by installing a database-independent plugin such as WP Clips.
What are the benefits?
Simple. Customisations are safe from child theme updates. In addition, they are easy to find, easy to back-up, easy to copy and easy to transfer.
There is also an advantage when it comes to multisite. Separate files allow a user to customise each individual site using the one Genesis child theme. This is not possible with current best-practice which would require multiple copies of the theme, each with its own customisations.
To summarise.
I’ve mentioned Andrea Whitmer a few times in this article, so I’d first like to say that I have great respect for Andrea, her contributions to StudioPress, and her educated opinion in regard to this issue. I just have an alternative point of view.
In a nutshell, these are my points.
- The Genesis child theme landscape is changing. We’re seeing more child theme developers and more child themes with greater functionality and dependence on third-party peripherals.
- StudioPress recognises this asset and in addition to introducing a new league of child themes in its own right, it’s embracing more third-party products and involvement.
- Greater complexity and dependencies in child themes, plus an accelerating advancement in web technologies, means a greater susceptibility to external code changes and the need to release updates.
- Updates are already occurring. As a result, there is a perceived conflict when arguing that child themes don’t get updated (or don’t need to be updated) when there is an obvious progression in versions. This is causing a level of contradiction and uncertainty in the Genesis community, particularly with new users.
- Continuing uncertainty and dissension could have a negative effect on the Genesis brand.
- Updating is a good habit. And in general, users want the latest version, and developers want their users to be equipped with the latest version.
- Current best-practice is a limiting methodology. It prevents users from updating their child themes or, at the very least, makes it problematic to do so.
- The issue is easily resolved by changing or relaxing best-practice to endorse the isolation of code customisations from the child theme folder, and hence the debate of whether child themes should or shouldn’t be updated is annulled. The user is free to choose.
Who am I to say?
Two and a half years ago, I developed the Envy e-commerce Genesis themes. Sometime after that, I developed WP Clips to allow my clients to add update-safe theme customisations because major updates in WooCommerce occasionally required updates to my themes. My clients quickly embraced the product, so I elected to make it available to all Genesis users at http://wpclips.net.
What’s my personal process?
As you’d expect, I use WP Clips to create a custom Clip of PHP, JS and CSS files. Custom code is added to these files and any modified templates, scripts and images are added to the same custom Clip folder. I often install a few precoded Clips to serve up my common customisations, one of which is to combine and minify all CSS and JS files within the plugin.
After completion, I turn the custom Clip into a precoded Clip and specify the theme and plugins required for the Clip to activate, then transfer the plugin files to a must-use (mu-) plugin to prevent accidental deletion. And that’s it! No fuss. Easily backed-up. Easily transferrable. Database independent. Safe and secure. Quite honestly, an extremely simple solution to what I see as an unnecessary problem.
A final word.
It could easily be said that I’m perpetuating the problem by adding fuel to the debate. And that perhaps I should simply accept that ‘this is how it is’, retreat quietly into the night, and it all goes away.
However, I am quite certain it won’t go away. Users will continue raising the issue because there is a conflict. There is a problem. And avoiding discussion, even fierce discussion, is not how progress is made. It’s not how new truths emerge and it’s not how better practices are formed.
So, this debate is absolutely necessary for the good of the framework and its community. I’m not saying that mine is the right solution and I’m not saying Andrea’s is the wrong one. I’m saying it’s in everyone’s interest to have their say. Because, eventually we may “crawl out of the fray – bruised and broken”, but there will be an outcome. A decision. And if the decision is the right one, the “question will never be asked again”.
