The Developer’s Condition
So you have a base theme and you have people who want websites. You want to use the same base theme across client projects, for obvious reasons. But the client wants you to make all these fancy custom changes to the theme, but then they also want to personally mess with the CSS or who knows maybe some PHP; all edits of variable quality. Oh, and you just noticed a visual bug in the base theme, which now must be fixed across every site you have. Or did the client create the visual bug? Who knows?
At CovertNine, we wanted a system that would address the common complications associated with managing multiple clients on a similar codebase. More specifically, we wanted to
- Update the theme without overwriting any client stuff, by design
- Version all client-specific code
- Allow the client to mess with their code as much as they like, up to and including creating a child theme
Our solution was to maintain one git repo for the parent theme (c9), alongside a
gitignore‘d repo inside the c9 directory. That’s this repo. So, in WordPress, the directory stucture is
wp-content/themes/c9-starter/client. Both ‘c9’ and ‘client’ are git repos. We have added functions to the
c9-starter theme that then check in the
client directory for stuff before anywhere else. It’s kind of like a child theme in that way, but a child theme only you mess with.
That leaves the actual child theme for your client theme (that’s c9-child).
// from themes directory git clone https://github.com/covertnine/c9-starter.git cd c9-starter git clone https://github.com/covertnine/client-starter.git client
Integration with C9 Starter theme development
While the client directory has a few useful functions and adds client-specific stuff like assets and custom fields, a lot of the magic happens in the parent c9 theme.
The C9 build process integrates with the client boilerplate via the gulpfile.js, which watches the scss files in the
client/client-assets directory, and drops everything in the
client/dist folder. This way, you can even overwrite scss variables defined in the parent theme (via
c9-starter, just run
npm run start and get going! You can get more details about the npm process here.
1. Clone C9 Starter parent theme into your theme folder
// from wp-content/themes git clone https://github.com/covertnine/c9-starter.git
2. Clone C9 Starter client boilerplate into just-created c9-starter directory, and call it “client”
cd c9-starter git clone https://github.com/covertnine/client-starter.git client
3. Run npm
// from wp-content/themes/c9-starter npm install npm run start
4. Do your development in the c9-starter/client directory
Make all client-specific changes inside the client directory.
5. Create your own client project repo on github and set remote accordingly
// replace myaccount and client-project git remote add origin https://github.com/<my-account>/<client-project>.git // first commit! git add . git commit -m "first commit" git push origin master
6. Optionally, maintain your own version of the C9-starter parent theme or merge in any new updates from us!
C9 Starter Child Theme – Don’t want to mess with any of this?
If these are not problems you face, and you just want to get rolling, feel free to ignore all this, and just use a regular child theme, which you can get the boilerplate for here.
The C9 child theme works just like any other child theme, with the added bonus that our child theme adds any of your CSS customizations to the Gutenberg editor in the backend as well so you’re seeing any changes you make on both the frontend and the backend while working with a child theme.