Combined WP (platform) + _tw (theme) development/management within a dev/test/production worflow?

[kmaling]

Hello!

Just giving _tw a spin, have gone through the documentation and have some questions with regards to "other deployment options" and how I can integrate development of a _tw-based theme into our current workflow.

We're not developing themes for general/published release; they're custom, one-off, maintained themes, per client.

Sites are hosted on the Pantheon platform. Pantheon provides dev/staging/production environments; staging and production are read-only environments (excluding the "uploads" folder). Moving code to these environments requires pushing code from DEV to TEST, then TEST to PRODUCTION via GIT.

The development environment can be set to SFTP or GIT (one of the other); we use GIT for the dev environment as well, and when using GIT, the development environment is also read-only (again, excluding "uploads"). So, all development (mainly theme-related) and maintenance (mainly plugin updates) is done via local dev environments, pulling/pushing from the master (Pantheon dev environment).

So I'm curious as to the best approach for integrating a _tw theme into this workflow, with the following in mind:

• the master branch/repo is the hosted via the Pantheon-based "development environment" (there are also branch-based environments, branching from the master, for new features, etc., but I don't want to overcomplicate this post too much)
• WP Core, plugins, themes, etc. are all included in the repo (though there are some specific files/directories in .gitignore, mainly environment-specific files such as uploads, caching, backups, logs, that don't need to be moved between environments)
• there's no separate repo for theme development; everything is included in the one repo
• new developers on a project would clone from the master and need to be able to develop with not only the theme itself, but also non-theme related

To make this work, I'm thinking...

1. I'd need to include the following in GIT (i.e., remove the following from .gitignore):

• *.min.js
• style.css
• style-editor.css
• style-editor-extra.css

I'd still ignore /node_modules and /vendor (and the .zip that could be generated if someone ran npm run bundle).

2. Developers coming into an in-development project would clone from the master, and then run both npm install and composer install, but shouldn't run npm run dev, as the theme's stylesheet would already exist (and would be included in the repo clone).

3. We'd also need to ensure that npm run prod was always run (with results committed to GIT) prior to any push back to the remote master/repo.

Hoping someone might be able point out anything I'm missing/doing wrong with the above, suggest something, etc. Just hoping to come up with a solution that will work for us so we can move forward with _tw.

Thanks,
Kristin.

[gregsullivan]

Hi Kristin—Thanks for posting this!

I haven't used Pantheon with WordPress before, but I've spent some time in the Pantheon–Drupal world. I haven't had time to test this, but my proposed approach would be as follows, pretending your theme slug is kmaling:

• Use a nested docroot to serve your site
• In the root directory, include your kmaling folder as created by the generator
• Create a symlink from ./web/wp-content/themes/kmaling to ../../../kmaling/theme
• Remove the files you suggested from .gitignore

For clarity, this is the proposed directory structure:

├── kmaling
  ├── tailwind
  ├── theme
  ├── [other folders and files from _tw]
├── web
  ├── index.php
  ├── wp-activate.php
  ├── wp-config.php
  ├── wp-config-local-sample.php
  ├── wp-config-pantheon.php
  ├── wp-comments-post.php
  ├── wp-blog-header.php
  ├── wp-admin
  ├── wp-cron.php
  ├── wp-load.php
  ├── wp-links-opml.php
  ├── wp-includes
  ├── xmlrpc.php
  ├── wp-trackback.php
  ├── wp-signup.php
  ├── wp-settings.php
  ├── wp-mail.php
  ├── wp-login.php
  ├── wp-content
    ├── index.php
    ├── mu-plugins
    ├── themes
      ├── kmaling [symlinked to ../../../kmaling/theme]
    ├── plugins

My one piece of feedback on what you wrote is that there would be no harm in running npm run dev so long as developers don't commit the results. Running npm run watch would have a similar effect, and I wouldn't suggest working without watch. But the initial run of npm run dev wouldn't be required to get started, since they would have the style.css file from git.

The approach above would remove the automated versioning that comes with npm run bundle. I'm not how Pantheon handles caching on the WordPress side, so I don't know whether that's something you need to work out yourself.

You could potentially add a script that does something like npm run prod followed by a git commit with a standard message about minifying assets.

You could also have a policy of committing unminified assets to the dev environment, with a script that does npm run prod followed by the git command / standard message described above, and then uses Terminus to push from dev to test. So minified assets would only be added immediately before pushing up from the dev server to test.

Happy to brainstorm this further, but that's it from me off the top of my head!