Textpattern themes: a plan

CodeWalker · 2015-06-18 17:17:54

Just to throw in my tuppence worth.

Having personally built dozens of commercial Textpattern sites, the ability to switch themes would be a god send and a very long time coming!

I have along the way come up with some work arounds that are almost perfect if a little clunky. In my opinion the way to go is this.

Take rah_flat and merge it with sed_cleaner.

Why?

Using flat files for the pages and forms is awesome, and means i can keep them under version control. It also allows me to develop using a gulp based build system and rsync/ftp the files to the test/production server as part of the build process.

Were sed_cleaner comes in is that it is capable of setting preferences, installing plugins, and creating sections and categories etc, from am external config file.

My currently process usually means doing an initial wave with sed_cleaner to nuke all of textpatterns default settings, set them as I like, and then configure stuff automatically as per the current sites demands. I also get it to install a few choice plugins i use on every site like zem_contact.

From there on its rah_template files and manually installing plugins as needed.

As for assets, these are best kept out of the database in my opinon. Apart from the very first site i built, i have never used the build in database stored style sheets. I use an assets folder in the root of the server containing all images to do with the sites design (as apposed to content images) and i also have CSS and Javascripts in there.

So thats it really. If we had a native plugin that is polished combination of sed_cleaner and rah flat i think you are on to a winner.

Last edited by CodeWalker (2015-06-18 17:45:49)

Bloke · 2015-06-18 19:51:36

CodeWalker wrote #291670:

the ability to switch themes would be a god send and a very long time coming!

Yeah, should be able to hammer out something sensible. I’ve changed my outlook from “too hard” yesterday to “less tricky than I thought” today, which is a start.

Take rah_flat and merge it with sed_cleaner.

Seems you’re thinking along the same lines as sacripant here: a clean start, then file-based management from then on. While that’d be the holy grail for some applications, I feel it’s kind of outside the scope for a simple theme switching experience. But I’m keeping that eventual aim in the back of my head as this thing rumbles along. If there are any suitable callbacks and infrastructure that can be put in to help a new sed_cleaner-like plugin from surfacing, then that’ll be grand.

allows me to develop using a gulp based build system and rsync/ftp the files to the test/production server as part of the build process.

Sounds great, you’re way ahead of me here!

If we had a native plugin that is polished combination of sed_cleaner and rah flat i think you are on to a winner.

I’ve been looking through Jukka’s code just now. Unless I’m missing something it doesn’t seem to do anything more than cleverly resync the local content with the database. If we manage to design the database out of the process then there shouldn’t be any need for the plugin… uhh, right? Changes you make to the files — whether in your favourite text editor or the admin-side panel — will be the de facto versions that tags and the public side uses.

The only sticking point is Sections. They are kind of an anomaly, because they’re silos for content and not strictly presentational, but the templates are linked to them. rah_flat treats them as presentation and can sync them, but I’m not sure if a “theme” in this regard should be adding and removing site Sections. For a start-up site, that’s great, but a site that already has a bunch of Sections set up with content assigned, isn’t going to fare so well.

Imagine you have five sections set up in your site: default, blog, design, services and contact. Content is brilliant and assigned throughout those five Sections, but you’re not entirely happy with the visuals and like the look of colak’s “Halibut” theme I mentioned earlier. You download it. You hit Import, it unzips the template Pages, Forms, CSS, Images, JS, etc and puts them all in its own folder under /themes. But you can’t preview it until the Pages and Stylesheets in the theme are associated with your existing site Sections.

Dilemma:

Option 1 package up Sections in the template itself. In which case, the theme author might have defined about, contact and default. Well, two of those already exist so it’ll have to skip them and just make the about Section. It then assigns all the templates to them as set in the theme: maybe the “squid” Page/Stylesheet is assigned to the default Section, and “cuttlefish” Page/Stylesheet is associated with the others. You can preview the template with your content in place, but you now have a dangling Section with no content that you don’t want, and have to go and delete it.

Option 2 leave Sections out of the template entirely. When you import the theme, it’s up to you to make the links between Section and Page/Stylesheet before you can preview the theme. Ultimate control, not as immediate results.

Option 3 find some way to offer a choice during import. “Hey, looks like this theme is going to install this section and skip these two, then assign Page X and Stylesheet Y to Section Z. That OK?” and you get to uncheck the stuff you don’t want. That’s more work and kind of OK, but more faff during import.

Option 4 a merger of Options 2+3 is showing you what Pages/Styesheets are on offer, shows you what Sections you have already set up, and asks you to make the associations there. The trouble is, you don’t know what each Page does (in terms of its markup) so you don’t know which to assign where.

Option 5 something else I’ve not thought of… maybe it only assigns Pages/Stylesheets to Sections that are common to your current theme and one you just installed. Chances of the Section names matching are quite slim though. Maybe this option does NOT add any Sections that don’t already exist. Hmmmm.

None of the above are ideal, and none solve the issue of what happens if the theme author employs links to Sections that don’t exist. If there were some navigation elements in a Form that relied on the about Section being available, they’ll break so they need to be hunted down and zapped.

Ultimately, when the owner of an already-populated site installs a theme, there needs to be a solution to take a path of best fit, I just can’t see what it is yet. Anyone got any bright ideas?

Thanks to all the wonderful insights and ideas in this thread, I’m coming closer to formulating what I think a theme is, and what it isn’t, but I’m not there yet so any more thoughts and opinions, ideas, tricks, tips, whatever are most welcome.

Last edited by Bloke (2015-06-18 19:59:52)

detail · 2015-06-19 08:50:08

Dunno, somehow I think we have moved on quite dramatically in the last two years and a fair amount of this is almost redundant.

Why?

1. For a New Site

Standard HTML5 templates are already being done by others with more resources. ie, responsive design, menus, etc.

There’s no need to replicate the work done on a site like HTML5up. There’s more than 30 sophisticated totally free templates to give a basic structure for a new design.

They have started with 60 different $19 templates at the associated Pixelarity. There’s gotta be more of those springing up.

I’m looking for a different method of working using one of those freely available free templates where you just plonk them into Txp. Many of the structuring elements are in place WP-style, all the js stuff already embedded, and you just adapt the standard code, ie, copying and pasting the responsive page layouts, and fiddling around with the CSS so it doesn’t look generic.

There’s still design involved but you already have a working grid and complexity of classes set up so you can have a two or three column desktop website sliding around responsively right from the start.

And you can do all the usual stuff like adding categories, shopping, just like you would if you started from Hive.

But those HTML5 templates are being created elsewhere already.

2. Migrating old websites.

Man, so much has changed to the underlying structure of websites in the last few years there’s no push-a-button-type fix.

It’s so much more involved than what was once thought of as reskinning, it’s totally rebuilding the framework and importing the old articles. It’s a whole bucket of work.

philwareham · 2015-06-19 09:08:50

detail wrote #291683:

Dunno, somehow I think we have moved on quite dramatically in the last two years and a fair amount of this is almost redundant.

It’s not necessarily redundant – the proposal is to have a standardised directory structure in place to make installing a theme/framework easier at a basic level. For example I’m just working through getting a vanilla version of the Foundation framework into Textpattern for use in quickly building websites. At the moment the only install options are:

Manually copying/pasting the various forms and pages into the control panel, or
Use rah_flat via Composer and a Grunt/Gulp Textpattern install to do a more automated setup.

That would be a lot more straightforward if there was a theme directory I could build into which did what rah_flat does but in the core (along with the aforementioned way of editing flat files in control panel).

I would then do a Bootstrap version too and a Hive version, then I could easily switch between the 3 frameworks depending on which is more suitable to a certain site build.

I’m not too bothered about the plugin side, as I can’t see a good way of incorporating plugins into a theme folder. But if others have a need/solution to it I’m on board with that.

Bloke · 2015-06-19 09:25:17

detail wrote #291683:

There’s no need to replicate the work done on a site like HTML5up.

Hey, nice resource, thanks! Those are dead simple to drop into a new template, upload the assets and then go through the template, pulling out repetitive bits into Forms and swapping out hard-coded pieces with <txp:...> tags.

And therein lies the point. If one person has gone through the process of doing that to “txpify” such a theme and has made a damn good job of it, why not make it available to export from their system and import it into someone else’s as a baseline? Wouldn’t that be neat? Especially if there was some easy way to tweak the colour scheme.

You’re right that design is much more involved now, but there are also people who want to get into this web design malarky and are faced with a choice of CMS. Given the fact that there are pretty much zero themes available for Txp (certainly compared to other leading brands, as adverts would have it) we’re not on people’s radar as a contender. Having at least the ability to share themes in a standard format might give someone the leg-up they need to pick up Textpattern and start to learn it, reducing the entry hurdle to “know” HTML up-front.

After tweaking and learning a bit of HTML/CSS, when would-be designers find out that to customise Txp really only requires adding HTML-ish tags and attributes (compared with having to know PHP to do the same in WP, for example), we’ve got a potential convert for life.

so much has changed to the underlying structure of websites in the last few years there’s no push-a-button-type fix.

I concur. But if we can solve the Section-to-Page-and-Stylesheet assignment thing in a meaningful way, there’s no need to do any reshuffling of content to try out a theme. Applying new template code to an existing Section in a non-destructive fashion is a great way to just get an idea of whether a theme is suitable as a baseline for further tweakage.

That’s really my main focus here, nothing more fancy at first. All the stuff about workflows and offline editing and version control is a side benefit of coming up with a standard, portable format for template code.

NicolasGraph · 2015-06-19 10:36:40

philwareham wrote #291687:

Manually copying/pasting the various forms and pages into the control panel.

Yes that is the essential thing we should improve. I’m also starting to think that it is really the main thing we need; beside that plugins could even be installed by the user (but a multiple import feature would be nice)… and about the sections it is maybe a good thing to just let the user know which page do what and let him assign his own sections. For prefs, maybe smd_prefset should stay a plugin.

Bloke wrote #291688:

Given the fact that there are pretty much zero themes available for Txp (certainly compared to other leading brands, as adverts would have it) we’re not on people’s radar as a contender. Having at least the ability to share themes in a standard format might give someone the leg-up they need to pick up Textpattern and start to learn it, reducing the entry hurdle to “know” HTML up-front.

For sure.

Last edited by NicolasGraph (2015-06-19 13:32:26)

philwareham · 2015-06-19 11:09:06

NicolasGraph wrote #291689:

Yes that is the essential thing we should improve. I’m also starting to think that it is really the main thing we need; beside that plugins could even be installed by the user…

Agree with this. Just lock down a theme directory structure and build the functionality of rah_flat into the core somehow (including the public callback hook feature). If editing can be kept in the control panel as well as from flat files then that would be brilliant. Doesn’t need to be much more than that really at this stage.

jakob · 2015-06-19 13:18:37

philwareham wrote #291645:

If there was a future rah_flat type plugin that allowed flat files with the ability to also edit in the control panel, that would be my top choice for a theme system. i.e.:

Have a theme directory in the root, within that the theme’s directory itself, within that a specific expected directory structure to store pages/forms/css/(theme)images/js/prefs

That would be beautiful. Allows versioning, allows natural browser caching (i.e. CSS and JS as flat files if desired), easy switching between themes. Lovely stuff.

I really like the sound of that too, and of the themes idea in general.

How would being able to make edits via the admin area will work with a versioning setup? I’m a comparative beginner with versioning, so perhaps I’ve missed something obvious, but wouldn’t any changes made to the db via the admin area also have to be written back to the flat files, which would then need remotely committing back to a repo, and then finally pulled back to your local repo. If the txp directory is also the remote repo, then git / svn will notice the change and all that is needed is a commit somehow. But for those who build their site from a parallel directory (like phil described in another thread) or rsync it from a repo (also a common scenario), there would need to be a way of detecting that something has changed in txp directory and ‘reflecting’ it back to the repo. Things will otherwise get out of sync and then changes made via the admin area will be overwritten with the next commit you make from your local repo. That was always my understanding why rah_flat only worked in one direction and took an either/or approach to the presentation tabs, and partially also why it replaces all files, rather than just what is new (maybe that last bit was for simplicity’s sake).

—

Otherwise, I think defining the scope / usage scenario is essential, not just because many wishes have been mentioned in this thread.

I suspect many developers and designers would welcome it but would probably use it as a method of streamlining their start process and not have much interest in theme switching (except for perhaps what colak mentioned, or for presenting alternatives to clients). They are also already experienced enough to deal with special cases and extra admin setups.
At the other end of the extreme is the commercial theme market expectations, which are pretty high nowadays if you look at sites like themeforest. You need to be able to offer a pretty fully-fledged theme to have a viable commercial proposition. Many WP templates are virtually fully-fledged sites that are ready to go with some replaced content, and a couple of changes – upload a logo, change some of the colours (with a colour picker), choose another webfont (combo) and it’s yours. You don’t really have to gets your hands dirty with any code (or even can’t without borking the theme update process). Is that realistic for txp? Will people spend money on a theme that offers less, e.g. where they still have to get their hands dirty with code and css to make it how they want?
In the middle is a grey zone that is probably more viable to realise technically and would probably also attract more users to txp because it allows people to get started more quickly with what they want than the present default template (nothing against it, but it’s only one kind of site setup). I’m not sure there’s the basis for a market there, though.

philwareham · 2015-06-19 13:30:45

jakob wrote #291706:

How would being able to make edits via the admin area will work with a versioning setup? I’m a comparative beginner with versioning, so perhaps I’ve missed something obvious, but wouldn’t any changes made to the db via the admin area also have to be written back to the flat files, which would then need remotely committing back to a repo, and then finally pulled back to your local repo.

It would work the same way editing a theme directly within WordPress works with it – i.e. it doesn’t work. Anyone who wants to version their templates will not be editing in the control panel really, or if they do, they will have to come up with their own solutions to get the files back into their repo.

I’m just thinking of a way that we can appease people that do use the control panel for edits, while also providing a way for flat files (and themes) to be used by people too.

Bloke · 2015-06-19 13:36:57

jakob wrote #291706:

How would being able to make edits via the admin area will work with a versioning setup?

At the moment it’s tricky, but if we design the DB out of the equation entirely and store all content in flat files, the problem goes away. So if you edit in the admin interface, it writes to the file and your text editor goes “urk there’s been a change: wanna reload?” If you edit in your text editor, next time you visit the admin panel, the content is read from disk so it reflects the current content.

The only situations it could ever get out of sync are:

if you had the admin panel open while editing the same file outside.
if two people were working on the same file (in either environment). Although if doing it outside, the VCS may well be able to handle it with a merge.

Most people will only ever use one editing method and stick to it for any particular site.

This all assumes you’re working live. If working on a local copy, there’s nothing you can do. The two systems will drift apart. But presumably the reason you’re working locally is so you can get things set up for the next version of a site. So in that case, once your staging / testing is done, whatever content is in the files will become the new Master content, and will be destined to overwrite the stuff on the server when the rsync / FTP / SSH takes place anyway.

philwareham · 2015-06-19 13:39:04

Bloke wrote #291710:

At the moment it’s tricky, but if we design the DB out of the equation entirely and store all content in flat files, the problem goes away. So if you edit in the admin interface, it writes to the file and your text editor goes “urk there’s been a change: wanna reload?” If you edit in your text editor, next time you visit the admin panel, the content is read from disk so it reflects the current content.

Of course, this is the optimal solution, and one that every other CMS known to man uses. So +1 for that.

Bloke · 2015-06-19 13:41:02

philwareham wrote #291711:

Of course, this is the optimal solution, and one every other CMS known to man uses. So +1 for that.

Fine. So regardless of how much work is involved with themes on top, how about doing this first? Bin the DB for Pages, Forms and Styles now. As for Sections, I dunno…

hcgtv · 2015-06-19 13:41:17

Bloke wrote #291688:

And therein lies the point. If one person has gone through the process of doing that to “txpify” such a theme and has made a damn good job of it, why not make it available to export from their system and import it into someone else’s as a baseline? Wouldn’t that be neat?

There’s nothing more to say really.

Let’s hammer down a themes directory structure, naming schemes, etc. I can start working on a theme for testing purposes, just point to one or I could use Textpattern’s default theme.

hcgtv · 2015-06-19 17:38:20

Stef,

Keeping with the K.I.S.S. principle, these are my thoughts.

Let’s just concentrate on the Pages, Forms and Styles for now:

Pages: No problem, each theme can have their own page(s), like “Kubrick”.

Styles: Same thing “Kubrick”

Forms: Here’s the fly in the ointment, this is what I do:

a) Form type is not used for anything internally other than to group forms on the backend.
b) When I start a design, I throw all forms under a new form type I create.
c) Since forms are unique names, I have to name them something like article.kub, footer.kub, etc.

Now if “Form Type” could be changed to “Theme”, and each form grouped under said theme, naming collisions accounted for in core code, and a top level uses theme setting which affects all access to forms in the parser, then we’re most of the way there. The backend doesn’t need to change much, since “Form Types” already has the grouping mechanism working just fine. I actually have a Textpattern site running locally with quite a lot themes in the backend, I do add a new “Form Type” to the core code per theme though.

As for workflow, backups, etc. I use hcg_templates to import and export my templates. Whenever I’m going to make extensive changes to a site, I export the current pages, forms and styles, giving them a unique name. Then I’m free to make changes, knowing full well I have a backup. Since I rysnc my sites on a daily basis to my local Debian server, I always have at my disposal, archives to go back to via my text editor.

That’s it, pretty simple.

CodeWalker · 2015-06-19 20:02:39

Bloke wrote #291712:

Fine. So regardless of how much work is involved with themes on top, how about doing this first? Bin the DB for Pages, Forms and Styles now. As for Sections, I dunno…

This is not such a crazy idea. I’m going to come clean. I have recently been flirting with Kirby CMS. There. I have said it. Why? Because it its the closest thing I can find Textpattern that also ticks the boxes with themes.

Here’s the deal with kirby. It’s a flat file CMS. The sections are dicatated by folder structure. Content is markdown. There is a control panel, you can wysiwyg new content but if your a textfile nut like me, then thats also fine.

I think this approach would work with Textpattern. I LOVE textpatterns template language. It is the best one out there. Im not a fan of Kirby’s language.

My ultimate CMS would be one that has textpatterns template language smashed into Kirbys flat file for templates and content, but also has a wysiwyg.

To try it out I actually built a textpattern theme and then ported it to kirby to see what the deal was. They are actually pretty similar. I think its worth you guys taking a look at Kirby and seeing what you can take away from it. Oh, and the fact it uses flat files doesnt mean it cant use a database. Kirby has an API that allows you to store stuff in a DB if you wish and pull it back out using front end tags in templates.

If anyones interested you can get the above mentioned themes here:

Geraldine Theme for Textpattern

Geraldine Theme for Kirby

Online Demo

Last edited by CodeWalker (2015-06-19 20:06:23)

Textpattern CMS support forum

#46 2015-06-18 17:17:54

Re: Textpattern themes: a plan

#47 2015-06-18 19:51:36

Re: Textpattern themes: a plan

CodeWalker wrote #291670:

#48 2015-06-19 08:50:08

Re: Textpattern themes: a plan

#49 2015-06-19 09:08:50

Re: Textpattern themes: a plan

detail wrote #291683:

#50 2015-06-19 09:25:17

Re: Textpattern themes: a plan

detail wrote #291683:

#51 2015-06-19 10:36:40

Re: Textpattern themes: a plan

philwareham wrote #291687:

Bloke wrote #291688:

#52 2015-06-19 11:09:06

Re: Textpattern themes: a plan

NicolasGraph wrote #291689:

#53 2015-06-19 13:18:37

Re: Textpattern themes: a plan

philwareham wrote #291645:

#54 2015-06-19 13:30:45

Re: Textpattern themes: a plan

jakob wrote #291706:

#55 2015-06-19 13:36:57

Re: Textpattern themes: a plan

jakob wrote #291706:

#56 2015-06-19 13:39:04

Re: Textpattern themes: a plan

Bloke wrote #291710:

#57 2015-06-19 13:41:02

Re: Textpattern themes: a plan

philwareham wrote #291711:

#58 2015-06-19 13:41:17

Re: Textpattern themes: a plan

Bloke wrote #291688:

#59 2015-06-19 17:38:20

Re: Textpattern themes: a plan

#60 2015-06-19 20:02:39

Re: Textpattern themes: a plan

Bloke wrote #291712:

Board footer