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.