Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Textpattern themes: a plan
There is no massive need for plugins bundled in a simple theme (although this whole mechanism is something to think about for future). What we do need is a description field in the editor (for use in meta description, Open Graph, Twitter cards, etc) – it drives me nuts having to use convoluted ways of getting this info onto a site without using a plugin. Also, built in form tags a la zem_contact_reborn would be a real boon – most sites have a contact form or something similar don’t they? Sorry, that’s a bit off topic.
Offline
Re: Textpattern themes: a plan
philwareham wrote #291639:
The whole thing would have to be handled as flat files in my opinion. I think the whole database thing for handling forms/pages/css/js is a outdated model of Textpattern that I would not be keen on keeping.
IMHO I like the fact that everything is in a db and accessible from any computer with a browser. Admittedly I always have rvm_css in my installs but I also install spf_js so as to get my javascript files in/out the database too.
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline
Re: Textpattern themes: a plan
colak wrote #291661:
IMHO I like the fact that everything is in a db and accessible from any computer with a browser.
Yes, as I said, having a way of editing the templates within the control panel is something I’d be keen to keep – the database is irrelevant to that.
Offline
Re: Textpattern themes: a plan
philwareham wrote #291660:
There is no massive need for plugins bundled in a simple theme (although this whole mechanism is something to think about for future).
True. Just wanted to throw it out there, ‘cos if it can be solved to a satisfactory degree, it make themes a lot more flexible out of the gate.
What we do need is a description field in the editor
Just add it. Seems we backed the wrong horse by adding Keywords and not Meta Description all those years ago. Assuming meta description as a <head> tag is going to stay, even now Uncle Google is semantically aware and the tag is arguably superfluous.
built in form tags a la zem_contact_reborn would be a real boon
That I’m not convinced about, even though I’ve never built a site without the plugin1. With the rate of change in W3C policy, a plugin is the only way to keep pace!
1 Oh wait, there’s one, but that was on an intranet.
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
Re: Textpattern themes: a plan
Bloke wrote #291663:
Just add it.
I don’t know how to add it, otherwise I totally would in a heartbeat. It’d also need some conditional tags such as <txp:if_description> ideally wouldn’t it?
Also, it would not need to be Textile formatted at all (because <txp:excerpt> already fulfils that criteria).
Offline
Re: Textpattern themes: a plan
philwareham wrote #291664:
I don’t know how to add it, otherwise I totally would in a heartbeat.
OK, I’ll do it. Where do you want it shoving, if that’s not too rude? Under the Meta twisty, presumably?
It’d also need some conditional tags such as
<txp:if_description>ideally wouldn’t it?
Probably. Let’s take this discussion elsewhere.
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
Re: Textpattern themes: a plan
Yes please! Under meta twisty labelled as simple ‘Description’
Offline
Re: Textpattern themes: a plan
Bloke wrote #291663:
… even though I’ve never built a site without the plugin.
I am trying to keep them to the minimum re the front end. rvm_css, spf_js and zcr are my standards… but I think that the 3 of them should be part of the core:)
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline
Re: Textpattern themes: a plan
Bloke wrote #291658:
Assuming Txp core hasn’t altered in the meantime. Though not exactly plugin related, remember the
<txp:sitename>/<txp:site_name>debacle with early themes?
I think I was not born using Txp already.
Offline
Re: Textpattern themes: a plan
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)
Offline
Re: Textpattern themes: a plan
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)
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
Re: Textpattern themes: a plan
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.
Offline