Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Textpattern themes: a plan
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.
Offline
Re: Textpattern themes: a plan
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.
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
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)
Offline
Re: Textpattern themes: a plan
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.
Offline
Re: Textpattern themes: a plan
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.
TXP Builders – finely-crafted code, design and txp
Offline
Re: Textpattern themes: a plan
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.
Offline
Re: Textpattern themes: a plan
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.
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 #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.
Offline
Re: Textpattern themes: a plan
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…
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 #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.
We Love TXP . TXP Themes . TXP Tags . TXP Planet . TXP Make
Offline
Re: Textpattern themes: a plan
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.
We Love TXP . TXP Themes . TXP Tags . TXP Planet . TXP Make
Offline
Re: Textpattern themes: a plan
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
Last edited by CodeWalker (2015-06-19 20:06:23)
Offline