Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#1 Today 10:35:34

gaekwad
Server grease monkey
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 4,477
Bitbucket GitHub

Streamline theme import process for local -> remote dev

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)

Offline

#2 Today 10:57:12

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,936
Website GitHub

Re: Streamline theme import process for local -> remote dev

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?


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#3 Today 11:18:01

gaekwad
Server grease monkey
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 4,477
Bitbucket GitHub

Re: Streamline theme import process for local -> remote dev

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…

Offline

#4 Today 11:42:57

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,936
Website GitHub

Re: Streamline theme import process for local -> remote dev

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.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#5 Today 12:13:45

gaekwad
Server grease monkey
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 4,477
Bitbucket GitHub

Re: Streamline theme import process for local -> remote dev

Thanks, Bloke – I really appreciate your insight.

Offline

#6 Today 12:39:12

etc
Developer
Registered: 2010-11-11
Posts: 5,460
Website GitHub

Re: Streamline theme import process for local -> remote dev

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.

Offline

#7 Today 12:44:11

gaekwad
Server grease monkey
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 4,477
Bitbucket GitHub

Re: Streamline theme import process for local -> remote dev

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.

Offline

#8 Today 17:38:02

giz
Plugin Author
From: New Zealand
Registered: 2004-07-26
Posts: 382
Website GitHub Twitter

Re: Streamline theme import process for local -> remote dev

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>

Offline

Board footer

Powered by FluxBB