How to pull my own sage based theme on deploy


This question is a little about “best practices”. And I’m not sure if deploys is the correct subsection.

I’ve got to this interesting thread: How does Trellis deploy a gulp-based theme like Sage? and this other one: Help deploying and building my sage theme from git

And I think both adress exactly the same issue I’m having but I think I’m missing something basic because I’m new to all the automation stuff and I used to FTP stuff until recently.

I have a full roots stack and I’m working on it locally. I’ve created a fork of sage so the theme I want to deploy is on github.
I have composer dependencies both on the site/composer.json and path-to-theme/composer.json. (Not sure which dependencies to put where but that is secondary right now)

As I followed the project exemple my theme is isntalled locally via git clone so it’s not a dependency of anything.

Now I got to the point I want to push everything to staging and the ansible and deploy scripts work great.

Right now I got a default template site on staging.

I have the following questions about this process:

  1. Should I make my theme a dependency of this website?
    this is the way I would feel most natural. I guess this way the deploy would pull the template from github. But I’ve seen on the linked threads that this would not run all the steps to build the theme.
    In case this is the best way:
    1.1. How should I indicate composer that a particular dependency that I am defining from github is a theme and so should be installed in the themes directory?
    1.2. How should I build the theme? I’ve read form the linked threads that I should not ssh to the server and build them.

  2. Should I push my local build of the theme?
    That would be totally new for me. Could you please point me in which way to search for documentation on this?

  3. Should I clone the theme from github?
    3.1. locally? and coping?
    3.2. SSHing?

I guess I’m missing some tutorial that adresses deploying theme but I did not find it on deploys documentation of trellis nor in the example project

Thanks a lot!

If the theme is only going to be used this once on this one site then I would not make it a dependency and would instead include the theme in the git repository for the site, like the roots-example-project does.

When the website is deployed the server will git clone the entire repository (now including the theme) and serve that code. This way, you will need to build the assets for the theme during deployment.

However if you want to have the theme in a separate repository then you will need to build the assets and commit the /dist folder to the repo. You would not need to build the assets on deployment as they are already included.

There should be a "type": "wordpress-theme" set in your composer.json if you cloned a recent copy of Sage, if not add this line yourself.

The installer-paths section in extras tells Bedrock where to install things that have their type set to wordpress-theme , wordpress-muplugin or wordpress-plugin.

You could, but it’s not the best idea. For more information read Austin’s post on it.

If you are keeping the theme inside the repo then you will need to build the theme with gulp before deploying. The easiest way to do this is to uncomment the included build-before tasks, changing the name of the theme from sage to your own.

If you are splitting the theme into its own repository and then installing it with composer then you should remove dist from the theme’s .gitignore, run gulp --production to build the theme and then commit these files to the repo like I’ve done here.

As mentioned in Austin’s post, there are three ways of compiling the theme’s assets:

  1. Build them locally - this is the method you would be using if you uncomment the build-before tasks mentioned above
  2. Compile on the application server - this is not really recommended but is still possible to do
  3. Having a CI server build the assets and copy them over for you - this is basically 1 but with a central server instead of doing it locally on your own machine

Alternatively, splitting the theme out into its own repository would involve building and committing these assets to the repo and is the same as option 1 but means your repo now contains both source and built files.

If you’re only using the theme once and want a simple process: keep it in the same repo as the rest of the site, uncomment the build-before tasks and let Trellis build the assets on deployment.

If you want to split the theme out and have Composer clone it from GitHub on each deployment you’d need to commit the dist folder and keep the built assets together in the repo with the source code.

Hope that helps,

  • Paul

Hi @paul_tibbetts,
Thanks for your reply. It has been very helpful.

Also the link to austin’s post has been super interesting.

I’m trying to build a theme that I expect to became the building block for other future wordpress websites so I’d like to keep that separate from site.

Now it seems that this will complicate my life quite a lot but I plan on making changes to the template on other projects that I would like to be able to revert to this base theme and share amongst different instalations of it so keeping it separated is a must.

Yes I had the line and it was working. Or at least it is now that I learned how to correctly create composer repositories from git repositories.

I’ll do that for now but If I understood it correctly it goes against Austin’s recomndations you linked.
It does work for me and I’m the only developer on this project and It will be that way for a long time but I’ll try to learn how to use hooks to build the project on the server when I have time for it (as per the option 2 on austin’s post which fits perfectly with the type of app and environment I have right now.

It does, a lot, thanks.

It does, but I’d rather build locally on my laptop with 8GB of RAM than on one of my 512MB/1GB Droplets. This is completely personal preference though.

This works well with Sage; I’ve recently built a theme that allows the user to change colours using the Customizer and so we have it running on three different client sites. If I need to override the template code for a module on one of the sites it’s quite easy to make a child theme for it including just the new module needed for that specific site.

Glad to hear, let me know how it goes :smile: