Iāve just started using Roots and am finding one major workflow problem: I canāt update Roots itself without clobbering/stashing/merging my customizations.
For example, modifying variables.less to change default behaviour traps me at the version of Bootstrap installed with Roots. I can obviously group my changes at the end of the file, or whatever, but I donāt think modifying core files is ever the right way to customize something.
I would propose a standard custom directory structure where files could be safely stored outside the Roots directory itself so that Roots could be pulled from GitHub without possible conflicts with local modifications.
I havenāt thought this all the way through, but Iām certain I donāt want to be modifying files that are in the Roots git repository in order to make changes to the look & feel of a particular site.
Roots is made to be a starter theme, so once you grab the latest version, you build off that. I donāt think itās really made to be kept up to dateā¦ if there is a function or class that is updated, you quite possibly could update those, but itās really made to be developed into a completely custom theme.
What youāre suggesting sounds a lot like a child theme in Roots (not based on Roots, in the Roots code). Iām not sure thatās a good way to go, even though I personally like the idea and have projects that could benefit from it.
The copy and abandon approach is the default and works great if youāre developing themes quickly or with no plans to maintain them after installāor if youāre willing to accept the āpart ways and never the twain shall meetā strategy. Some people may have longer-term projects underway and want to update if the update isnāt a major revision (converting from BS2 to BS3 is big, pulling in smaller changes that improve stability or behavior in edge casesāfor example, the last few updates in master). Itās possible to make updates work if youāre willing to do a little more work along the way. Itās up to the developer to decide if itās worth the effort.
For variables.less, I keep a separate, prefixed copy (even working with raw Bootstrap) and modify the bootstrap.less file to use my variables.less instead of the default variables.less. Thatās a one-time change to bootstrap.less, so I can make a prefixed copy of bootstrap.less and restore easily if the code base updates to Bootstrap 3.1. Even without the copy, changing bootstrap.less is easy, and failing to do so will usually be obvious. (āWhy is that PURPLE?! ā¦ Oh.ā)
You can do something similar with other filesāfor example jmjf-header-banner-image.php is intended to replace header.php, but by keeping a local-prefixed copy with a distinct name, I can recover it if I need to. Itās also code Iāll likely want to use again, so I add it to a local-master branch in my Roots repo. Prefixing lets me safely merge that branch into a new local-master branch when master updates. If the Roots team decides to include their own header-banner-image.php, prefixing keeps mine safe so I can choose which I want to use in the future and drop mine if I like theirs better. (Iām assuming they wonāt name something with my jmjf prefix.)
This strategy isnāt perfect. Itās possible to forget a significant change. Thatās where I rely on git to help me find what I lost and recover it. (And a backup, just in case.)
I guess I donāt agree with the concept of pulling a āstarter themeā at a point in time, then modifying it, losing the ability to pull future improvements/bug fixes.
The sites I do last years, through multiple versions of WordPress.
Being stuck in a point in time, where future WordPress changes might break the theme, and not being able to keep up with the base theme just doesnāt make any sense to me.
I went down this path once, with Joomla. We made (necessary) bug fixes and changes to core files, then were totally screwed when a security patch or different bug fix came out or when they fixed the same bug we fixed, but in a different way.
Having to patch patched files is a recipe for a time-sucking disaster.
Iām going to see about building a robust child theme, with support in the core with a very small configuration (i.e. point to the child theme from Roots core) and go from there.
@jmjf, I understand your strategy, and I see how it could help, it just seems that mixing modifications into the roots core directory structure would be a huge time-sink when trying to pull over roots core updates.
I can see your point, but you should also realize that the theme only refers to presentation and website-specific function. So generally, unless you are creating an all-encompassing theme to use on multiple sites, then the theme is going to be pretty customized anyways.
If you really want to keep Roots updated, I assume youāll agree that most of the markup and CSS would be ignored in updates, since this is a base theme. You could avoid modifying the Roots functions and sticking to adding new functions/classes to the custom.php file or creating your own php files and keeping your updates there. Then you could diff the lib folder once a month and see if there are any updates made.
I know you say thatāll be a huge time sink, but really thatās the option. Keep in mind, this is a starter theme, which means you use it as a base to create your own completely custom theme. Itās not anywhere near the same as modifying core Wordpress files (which nobody would suggest you do).
I have developed a child theme and all the good things about roots are preserved i.e. the search into /templates starts in the child theme, as expected, so Iām a happy camper.