Streamline theme import process for local -> remote dev

gaekwad · Today 10:35:34

BLUF: is to viable to add a shortcut link inline the theme name to reduce the steps involved with importing a theme from disk?

I’m building a new site – my first in a while, for various reasons – and I’m trying to do local (macOS with Nova and some hacky scripts) theme development as comprehensively as I can markup-wise, and I use a web-side Textpattern to render assets, test, and inspect.

Local changes are frequent, and I’m trying to streamline the local -> remote process as much as possible. The process currently looks like this:

Write / modify theme assets on local drive with Nova.
Set the version number in manifest.json and all the assets to the epoch so I can ensure the current asset version is being used.
Commit to a repo.
Upload from local theme directory to remote theme directory, overwriting all files & directories.
Update theme from Textpattern UI.
Reload browser for front-side site.

I’m iterating on most of the above as I go to automate as much as possible, and my question here relates to the ‘Update theme from Textpattern UI’ part.

Currently, I’m using this route:

When theme name is selected, click (#1) dropdown.
Click (#2) ‘Update from drive’.
Click (#3) ‘Go’ button.
Click (#4) ‘OK’ on ‘Are you sure?’

That’s 4 clicks. I often do this 20 or more times in a dev session. I’m not handy enough with keys in a browser to completely avoid the mouse (hence the clicks), but I suspect there’d be a lot more tabbing and confirming to achieve the above purely with key presses.

I totally understand the cautious, small-c conservative approach with overwriting a theme and potentially affecting a live / dev site. I’m happy with the risks and I want to clobber the theme, is there a route in for a plugin to make it one-click with an “Update” (or similar) hyperlink in the ‘name’ column?

Thank you for reading. Any and all advice / feedback very welcome.

Last edited by gaekwad (Today 12:44:50)

Bloke · Today 10:57:12

A more streamlined process might be neat if we can do it.

In the meantime, have you tried the etc_flat plugin which serves assets directly from disk to site, bypassing the database?

gaekwad · Today 11:18:01

Bloke wrote #340517:

In the meantime, have you tried the etc_flat plugin which serves assets directly from disk to site, bypassing the database?

Thanks, Bloke – good shout. I’ll give that more of a soak test.

I am aiming to minimise the plugin requirements on the live site, mostly from an admin perspective, but I suppose it would make good sense to dev it with etc_flat and go native (database) for the GA release. I’m fully on board with the idea of flat files, it’s the plugin glue that has an extra surface area to break on a live site.

No reflection on etc’s code quality at all, it’s more an in-built nod to making things work with minimal moving parts: more moving parts = more things that can break. The irony of this isn’t lost on me given my opening post…

Bloke · Today 11:42:57

Totally. The good thing about etc_flat is that it is normally only a development tool, so once you’re happy with the site, you import the theme to the dB and can delete the plugin.

If you want to then iterate your design in future, you can choose between using the native dev lane feature or reinstalling/re-enabling etc_flat if you prefer its workflow.

Not ruling out some more streamlined native workflow in core. Just haven’t figured the best route yet.

gaekwad · Today 12:13:45

Thanks, Bloke – I really appreciate your insight.

etc · Today 12:39:12

gaekwad wrote #340518:

No reflection on etc’s code quality _at all_…

Me neither, it’s a bloat :-) The plugin is very primitive, but integrating it in core would mean tune the interface, create webhooks, db syncs etc. Not sure everybody wants to inflate core with a feature used only rarely.

gaekwad · Today 12:44:11

etc wrote #340521:

The plugin is very primitive, but integrating it in core would mean tune the interface, create webhooks, db syncs etc. Not sure everybody wants to inflate core with a feature used only rarely.

100% agreed. I’m being a big, brave boy and keeping my four-click dance above for now.

giz · Today 17:38:02

etc wrote #340521:

Not sure everybody wants to inflate core with a feature used only rarely.

It works well as a plugin. etc_flat is the first plugin I install, and is the key to my workflow on every site (I leave it on permanently). Need to make a quick change to the public site only? Edit the database version in Presentation (and don’t export to disk when saving).

The site needs to be in ‘Testing’ mode to do its stuff, so any TXP error or warning messages are exposed to logged in users until they are resolved. I get around this by including a little snippet in my head form:

<txp:if_logged_in name="giz" not>
  <style>
    body > pre {
      display: none;
    }
  </style>
</txp:if_logged_in>

jakob · Today 21:06:54

I use etc_flat regularly too for those exact reasons. As Gary says, you can leave it on, as it disables in live mode, but I’ve caught myself out int past when setting a live site to testing/debug mode only to find the db them and theme files weren’t synced. So usually, I set the site to live and then turn off etc_flat until I need it again.

There are the odd cases (like if you use ?f=form_name) where you need to make sure you have imported from disk for Textpattern to find them.

Developing on a local webserver avoids the need for upload-syncing or committing to a repo, except when you have a major update.

Textpattern CMS

Textpattern CMS support forum

#1 Today 10:35:34