Textpattern themes: a plan

maverick · 2015-07-13 00:27:04

While it does not happen on many sites, I believe that theming by section is important.

For example, if you are using a single install to power multiple blogs.

Or, a use case I often run into, a church wants to give their children’s ministry a custom look, and their teen’s ministry pages a custom look, while the rest of the site uses the master theme.

For that reason, my preference is #1, with a thought:

I like the idea of having a setting for a master theme that cascades (auto populates?) to all sections, then each section has a secondary, individualized option where a different theme can be set if desired.

I’m not sure how do-able this is, but it sounds good in my head :P

Last edited by maverick (2015-07-13 00:28:52)

hcgtv · 2015-07-13 01:12:05

Bloke wrote #293103:

A chunk of the groundwork for Themes has been laid in its own branch on Github. Right now you can create a bunch of Pages, Forms and Styles under different Theme names on the admin side. The front side doesn’t know what to do with them yet (if, for example, you call two Pages the same name it’ll just get confused), but you can switch between them on the admin side and edit them as if they were separate entities. I have some markup issues that Phil’s helping me out with, so the UI isn’t clean yet, but functionally the admin-side portion works.

Will be grabbing this tonight and having a look, great news. Let me just say that I never thought this day would ever come.

Stef, the community owes you many pints at the local bar.

I’ll come out and say I’m not a huge fan of Option 2 at all, but I’m torn between 1 and 3. These are probably not the only options, but it’s all I could think of for now. Someone might be able to come up with another option or two: in which case, please present them here.

This afternoon I updated 3 of my Textpattern sites that are effectively holding pages for domains I own. They were running TXP 4.4.1, so they had the old default look. Since this is the week that I finally tackled the Mobile-Friendly todo item that’s been nagging me since April, the old 4.4.1 look doesn’t cut it with Google.

To update these sites I used a Textpattern 4.6-dev install to create a default-4.6 theme. I exported this default theme and uploaded it to each of the sites new themes folder, installed the hcg_themes plugin, and imported the new default 4.6 look. I went into the default and articles sections, and changed the Page and Style, voila!

This is so convenient, how many steps did I save from the old copy/paste method? Let me see, copy/paste 3 pages, 11 forms and 2 styles, times 3 sites, I’d still be doing the sites, and not typing this out on this forum.

I vote for K.I.S.S. – Option #1.

michaelkpate · 2015-07-13 01:50:39

Bloke wrote #293103:

Option 1: Leave the txp_section DB table roughly as it is

This entails adding only a theme column to the table so that you can assign a Theme to that Section. When Themes are installed from a package, they will only install Pages, Forms and Styles against the Theme’s name. It will then be your job to go to your Sections panel and assign them — either one by one, or using the multi-edit.

Cons:

Not able to do this automatically from the Theme bundle (yet?), which means even “out of the box” installs would need manually assigning to Sections.

Option 1 definitely would be my first choice. Option 3 is very Wordpress-like (you can install multiple themes but only activate one at a time) which isn’t what Textpattern is about. Manually activating them per section is the way things should work – You really shouldn’t want a new theme to activate itself unexpectedly.

gaekwad · 2015-07-13 09:33:47

+1 for option #1, seems to be the best fit of the bunch.

phiw13 · 2015-07-13 10:06:31

Option 1 gets my vote as well. Sections are (as I and others have argued before) too much tied to contents to allow a theme to (blindly) automatically touch that.

Destry · 2015-07-13 11:43:04

maverick wrote #293104:

While it does not happen on many sites, I believe that theming by section is important.

For example, if you are using a single install to power multiple blogs.

Another example, should the txpmag.com i18n proposal fly, is each language community having their own theme (decided upon and created by those respective language groups, of course).

Bloke · 2015-07-13 17:17:24

Thanks all. Option #1 it is. Watch this space…

tye · 2015-07-14 00:47:14

Bloke wrote #291616:

Just got back from a month away – so have only read your first post… I’m all for it :) :)

Not sure if you remember, but I emailed you something very similar a few years ago but using ‘non-coding’ terms… which may have confused the issue :)

Reading the rest of the thread now and watching this space like a hawk :)

Bloke · 2015-07-15 01:22:37

If you can put up with the stupid Theme selector disappearing behind the sidebar and shoving the twisty down (only two pixels of height are available to grab onto in the select list: any best practices for a fix, Phil?!), you can now play with Themes end-to-end. Create them, delete them, edit them, assign them to Sections (with multi-edit if you wish) yahde yahde, and see the results on the public site.

A minor glitch with the jQuery still exists on the Themes edit panel: it seems to leave more than one asset selected="selected" which confuses browsers. Although it shows the correct item in the list, when you click on the dropdown, the check mark is against the first item (presumably because the browser can’t reconcile which selected attribute to honour). Telling jQuery to remove all selected attributes except the one from the current theme — the commented out line in textpattern.js — ceases to show the correct item in the list at all. Can’t figure it out, but its getting late so if anyone with a fresher pair of eyes can spot where I’m going wrong, that’d be brilliant, thanks.

The <txp:css /> tag has been retrofitted with a theme attribute in case you wish to override it, but by default it’ll pick up the theme you’ve assigned to the Section. Haven’t tested what happens if you try to load a Stylesheet from a different theme that doesn’t exist: it’ll probably just cry.

Jumping back and forth from panel to panel remembers your last edited theme.

Possible things left to do, in no particular order:

Fix up jQuery (see above).
Improve robustness under error conditions (missing theme asset, mis-spelled theme name in URL, etc).
Add Page / Style / Form counts to the Themes panel’s details view, so you can see when a theme can be deleted. Links from these asset numbers will jump to the individual Page/Style/Forms panel respectively with the clicked theme’s assets ready for editing.
Permit arbitrary Form types to be added. Since the list of available Types is dynamic for each theme, you only see the ones that are “in use” for that theme, so making new ones only affects an individual theme, which is a bonus. Yay non-normalized tables :-)
Perhaps look at importing prefs, but this may be Phase II stuff along with plugins and other assets.
Add an import/export feature to dump the theme files from and to disk respectively (not zipped or anything, just as files in the agreed folder structure). This’ll be on the Themes panel somewhere (probably a button in each theme’s row, and a multi-edit tool so you can import/export en-masse).
- I’d also like to have import/export per asset type. So on the Pages panel there’d be a pair of buttons to import/export all Pages from/to disk. Likewise on the other panels so you can just synchronise that particular type of asset.
- If screen real estate allows it’d be neat to be able to sync just a single file, but someone’s gonna have to help me figure out the best UX here.
- Admin-side hooks on import/export and cleaner separation of functionality from the UI. This would allow an auto-sync plugin to be made such that any changes to a disk-based file could be detected and assets synchronised automatically.

The above sync stuff relies on some freshness indicator being visible. This is simply a mechanism to compare the date in the DB for that asset against the last-modified timestamp of the equivalent file on disk (if indeed that file exists on disk). The DB infrastructure is in place to do this, it just needs to be factored into the UI somewhere to show you which asset is the newest of the two. This could be a string shown below the title or near the Save button in a certain colour or something “Disk copy is newer”, etc. Or, if it can be made clutter-free somehow, an indicator alongside each asset in the right-hand pane. Like, I dunno, green tick = DB copy newer. Orange exclamation point = disk copy newer. Red warning triangle = file missing from disk (assuming other assets from this theme exist on disk, otherwise the synchronisation info should be hidden). No firm plans yet: suggestions welcome.

Remember that the DB is the master no matter what. Your site renders from what is in the database and the disk is just a backup for your editing/version control convenience. When you’ve finished editing the files you’ll need to import them to the DB before they’re live.

Most of the synchronisation gubbins is pretty easy and may be lifted from rah_flat, although the auto-sync stuff would be left out so there are no nasty surprises and you retain complete control over what is synced with disk. But I’m in two minds here. Arguably, this whole synchronisation thing could be a plugin in its own right and not a core feature. Since the core is still using the DB to render stuff and is not using the files at all in its critical path, it really does kind of fall outside the remit of core functionality. So maybe we rely on a slightly modified rah_flat and/or hcg_themes to offer import, export, and synchronisation capabilities. That would permit sharing of themes easily, and such a plugin could offer the enhanced UI sync features and indicators described above.

But on the other hand, having a way to import and export themes in core would mean a nice win for a future phase: being able to load themes from disk on setup. Any themes dropped in the /themes directory could be sucked into the DB at setup time, replacing the core theme (which would then only be installed in the absence of any custom themes).

So I might end up doing the import/export facility anyway and then plugins can piggy back off that or do zipped installs from an admin side panel, the whole nine yards.

Not an insane amount of work left to do. If anyone has any thoughts on any of the above while testing this branch (and also any ideas on best UI workflow or fixes for the outstanding visual niggles, which’d be very much appreciated) then please drop them here.

Last edited by Bloke (2015-07-15 01:28:55)

hcgtv · 2015-07-15 02:47:29

Bloke wrote #293204:

If you can put up with the stupid Theme selector disappearing behind the sidebar and shoving the twisty down (only two pixels of height are available to grab onto in the select list:

Unacceptable ( Picture the short dude from the Princess Bride :)

Downloaded, installed, mucho excited.

Some text somewhere to tell you what Theme you’re working on would be nice, the drop down seems to be the only way to tell.

I created a new Theme, it populated the Pages, Forms and Styles with empty defaults. Shouldn’t we start with a clean slate?

Edit Section – Uses page and style drop downs have items from both the skins I have in the backend.

After I added the new skin, the front page refuses to show the default article, it displays the excerpt on the Articles page, but the front page has blank space where the article should be. Both sections are set to their installed defaults. I did assign the default section to the new 2015 Theme to see what would happen, totally blank page, no freaky errors. But when I switched it back, that’s when the blank article appeared on the front page.

As for import/export, that should be baked into the core, plugins get out of date, the developer takes a hiatus, etc.

Will keep plugging away, these changes along with the admin layout update are like I’m not in Textpattern anymore.

philwareham · 2015-07-15 08:34:34

Bloke wrote #293204:

If you can put up with the stupid Theme selector disappearing behind the sidebar and shoving the twisty down (only two pixels of height are available to grab onto in the select list: any best practices for a fix, Phil?!)

Sorry, not had any spare time to check this branch out as yet, doing 12 hour days at work at the moment :( Will look into UI bits for it soon though – I promise!

phiw13 · 2015-07-15 09:21:40

Bloke wrote #293204:

If you can put up with the stupid Theme selector disappearing behind the sidebar and shoving the twisty down (only two pixels of height are available to grab onto in the select list: any best practices for a fix, Phil?!)

only had time for a very quick look.
For your disappearing selector (pages pane) – temp. hack to add to the stylesheet:

.action-create + form > p > span {float: none;}

other issue I’ve seen, on the tab_skin —> edit pane: the whole thing is wrapped in a

<skin class="txp-edit"> … </skin>

Summer heat HTML? I think you mean:

<section class="txp-edit"> … </section>

PS – I tried creating a skin from that pane, but got a few error alerts.

Gotta go cooking… hungry teens and all that Jazz.

Textpattern CMS

Textpattern CMS support forum

#121 2015-07-13 00:27:04

Re: Textpattern themes: a plan

#122 2015-07-13 01:12:05

Re: Textpattern themes: a plan

Bloke wrote #293103:

#123 2015-07-13 01:50:39

Re: Textpattern themes: a plan

Bloke wrote #293103:

#124 2015-07-13 09:33:47

Re: Textpattern themes: a plan

#125 2015-07-13 10:06:31

Re: Textpattern themes: a plan

#126 2015-07-13 11:43:04

Re: Textpattern themes: a plan

maverick wrote #293104:

#127 2015-07-13 17:17:24

Re: Textpattern themes: a plan

#128 2015-07-14 00:47:14

Re: Textpattern themes: a plan

Bloke wrote #291616:

#129 2015-07-15 01:22:37

Re: Textpattern themes: a plan

#130 2015-07-15 02:47:29

Re: Textpattern themes: a plan

Bloke wrote #293204:

#131 2015-07-15 08:34:34

Re: Textpattern themes: a plan

Bloke wrote #293204:

#132 2015-07-15 09:21:40

Re: Textpattern themes: a plan

Bloke wrote #293204:

Board footer