Textpattern themes: a plan

jstubbs · 2015-06-20 01:39:04

Moving from DB to flat files with the possibility of version control would be awesome. I’ve copied and pasted over the wrong page template so many times – only to be saved by pressing the back button…

@codewalker – how does Kirby fare against Statamic for example? I think the latter uses a very nice text editor called Redactor which would be great for TXP although the OEM licence costs $$.

@philwareham – wondering how your Texpattern Foundation templates would work for those who don’t use Grunt or other tools? Personally I use CodeKit because its just easier for me (then sync or SFTP), so I’m wondering how the import workflow might work for non-tech users assuming the new themes become a reality.

CodeWalker · 2015-06-20 08:58:41

jstubbs wrote #291723:

Moving from DB to flat files with the possibility of version control would be awesome. I’ve copied and pasted over the wrong page template so many times – only to be saved by pressing the back button…

@codewalker – how does Kirby fare against Statamic for example? I think the latter uses a very nice text editor called Redactor which would be great for TXP although the OEM licence costs $$.

Kirby does have a nice panel (that you can choose to install, its not essential) with just enough tools to write stuff and add images to posts and organise content. I like it, but i think Redactor looks like it has a lot more power in it. Im sure if we had a whip round on the forum, we could raise the $499 it costs. I’m pretty sure there are alternatives out there that do not cost money.

Last edited by CodeWalker (2015-06-20 08:58:53)

jpdupont · 2015-06-20 10:06:19

CKEditor-4.5-Beta Released : alternative ?

Bloke · 2015-06-21 16:11:07

hcgtv wrote #291718:

Now if “Form Type” could be changed to “Theme”

The idea of arbitrary names for Form Types has come up before. In fact, a long while ago (and we’re talking years here) I proposed a teensy patch to do just that, which retained the usual select list of types but with an input box alongside if you didn’t like the existing names. I seem to recall it was rejected for what were probably legitimate “convention over configuration” reasons. Maybe now would be the right time to reconsider the concept.

There are, however, a few issues with using the Types as Themes. Firstly, the “article” type has a special meaning to the admin workflow in that it can be previewed. Now, while I’ve never found a good use for that, maybe some have it as an integral part of their design workflow (speak up if you’ve used it).

Renaming Types as “Theme” or something is also going to cloud the issue of fixed, undeletable Form types. Again, I’ve never really cared for this approach, but the convention does have advantages in core code (less complexity) and from a workflow point of view it does mean that new users get some nice boilerplate Forms to play with or tweak without much hassle. The problem is the way Txp uses Forms: they’re never “released” when not in use, unlike the pre-defined Pages and Styles which can be removed once reassigned elsewhere. And to change core to permit all Form deletion would probably require invasive (slow) code.

Although it’s one extra UI widget, I’m fine with having the “Theme” as an extra selectable doohicky on the Forms panel. It’d remain consistent with the other panels that way too. And also means you can still continue to subdivide your Forms inside each theme, which is something we’d lose if we followed your proposal. Granted the subdivisions are rather arbitrary right now. I would like to be able to rename/extend them, if for no other reason that I could set up my sites with all the “fixed” Forms in a single group, then minimise it so they don’t bother me by taking up space in three other groups that I do use.

Maybe there’s a way your proposal and an extended theme proposal could be merged, while still trying to keep it straightforward. Will think about it some more over the next few days, thanks for the reminder.

Bloke · 2015-06-21 16:25:10

CodeWalker wrote #291719:

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.

Sound pretty sweet to me. Will see what we can do. How’s your coding to help out…? :-)

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.

Interesting. One thing I’ve been mulling over today is, if we do drop the DB for template stuff, how to do it in a manner which doesn’t break plugins that rely on calling safe_*() to do Section, Page, Style and Form related stuff. rvm_css, sed_section_fields, smd_admin_themes, smd_styles, adi_form_links, to name just a few would all keel over if we ripped the DB support lock stock. That’s something I don’t want to enforce.

But equally, if we do it, a lot of potential code would be required to keep things in sync with the DB for no real long-term gain. What we need is some way to “fake” it so that any calls to Txp’s internal safe_*() functions that deal with the missing DB tables get silently redirected to the files. Or, as you say, introduce a new API which uses the filesystem and encourage its adoption while leaving the DB support for legacy use only. Umm, somehow. Nothing can be done for those plugins that tinker with the DB directly via SQL calls. They’ll just break unless we can find a sensible way to run the DB and filesystem in parallel for a while.

Thank you everyone for chipping in so far. Please keep thoughts coming, they’re greatly appreciated. I really want to consider as many angles as possible before nailing down a path: I don’t want that path to pass by the bridge where the nasty troll lives that smashes people’s sites up.

CodeWalker · 2015-06-21 17:05:32

Bloke wrote #291752:

Sound pretty sweet to me. Will see what we can do. How’s your coding to help out…? :-)

I would love to help out! I am a front-end developer / creative, with 17 years in the field. Went to design school, got a Degree, and I have have at least 200 site builds under my wing to date. I do not know PHP unfortunately, however if its solid designs and front end code for a new admin panel or a reboot of the Textpattern sites you are after I would be more then happy to oblige. I would also very much like to be involved in the evolution of Textpattern.

Interesting. One thing I’ve been mulling over today is, if we do drop the DB for template stuff, how to do it in a manner which doesn’t break plugins that rely on calling safe_*() to do Section, Page, Style and Form related stuff. rvm_css, sed_section_fields, smd_admin_themes, smd_styles, adi_form_links, to name just a few would all keel over if we ripped the DB support lock stock. That’s something I don’t want to enforce.

Hmmm. It’s a tricky one isn’t it. I think if m brutally honest, what Textpattern needs is a massive overhaul, and if that means breaking a few things in the process, surely it is for the greater good?

One thing that has tempted me away from Textpattern of late is the slow progression of Textpatterns development. Great things were promised a long time ago, like improved custom fields, that have yet to materialise. I think alot of those have been hindered by trying to chisel the new promises out of the current code base.

If it was me I would tackle it like this. Freeze Textpatterns development. Stop maintaining it, other than bug and security fixes.

Then start again. Textpattern 5, the flat file CMS (with DB and panel options). fan fare and drum roll

That way, the old sticks in the mud that like the current setup and are clinging on to plugins favoured and loved don’t get upset.

It also means you are not fighting legacy ideas and architecture in order to take Textpattern to the next level.

It is drastic but I feel if Textpattern is going to rise like a phoenix and show the world again that is a force to be reckoned with (and i truly believe it is!) then this i think is the way to go. Draw a line in the sand. Keep the die hards happy by patching security and bugs, and hiccups with PHP version updates in the current version but develop it no further in terms of features. But also, do something awesome and start a fresh with all the neat ideas discussed in this thread that are unhindered by the current code base.

Peace.

Last edited by CodeWalker (2015-06-21 17:08:31)

jakob · 2015-06-21 20:10:05

philwareham wrote

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.

stef wrote

If working on a local copy, there’s nothing you can do. The two systems will drift apart … 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.

Ah ok, thanks for clarifying that. Fair enough, that sounds fine as long as you can prevent those kinds of problems happening, presumably through access privileges.

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.

Agree with you about the language. I’ve also used flat-file cmses before for simple one-off sites and for quick prototyping, also using markdown (which I find limiting in comparison to textile) and the YAML-type meta infos up top. Of those, I most liked liquid’s syntax, with which you can quickly build a prototype. It’s not quite the same paradigm as txp (more like what ruud recently wrote a plugin for), but you can build similar modularisation through the includes, so it’s fairly straightforward to transition from that to txp’s pages and forms.

They’re fine for the kind of site like your Geraldine theme, and they’ll also stretched to tag-filtered content such as blog posts, portfolios, shop items etc. It starts to get more difficult when sites get large, when you want to do something more complex, where different parts of the site relate to one another, and where some user interaction with the site should be reflected in the CMS output. That’s where a database really excels.

Bloke · 2015-06-21 21:51:13

CodeWalker wrote #291753:

I would love to help out!

Yay! For all things front-end or customer-facing, Phil Wareham’s the guy to get in touch with. He’s rebooting the main sites little by little and I’m sure could do with a hand.

I chatted with Pete (Cooper: gaekwad) about textpattern.org recently, which also need some serious (serious) love, not just from the front-end side of things but from a workflow perspective to allow plugin authors to keep the thing updated with the minimum fuss. Having to log in and add your plugins to it by hand is, frankly, a pain. I’ve shared my thoughts on it a few times, have written docs on how I feel the user experience should be, but lack the time to do it justice on my own. Any assistance massively appreciated.

what Textpattern needs is a massive overhaul, and if that means breaking a few things in the process, surely it is for the greater good?

We kinda tried that (a few times actually) and it fell on its face :-(

Like it or not, plugins are where Txp as a platform should excel. While the WPs and Joomlas of the world march on trying to equip the back-end with kitchen sinks, I think Txp works precisely because it is minimal. People that genuinely love design, like the control it offers, and a lot of that is the “add what you need” approach we’ve taken.

Sure there’s legacy cruft in there (comments, anyone?) and some silly naming conventions (Forms, argh!) but my aim is try and bring long-sought-after features in without bloating anything in the process. I want to streamline, and introduce more plugin hooks so more handy things can spring up around the core. Given the glacial release cycle (and that’s something that probably won’t change in the foreseeable future), plugins enable more rapid development in the interim.

There was a time I thought a clean break was the way to go. But it turned out that the compromises necessary, and cutting off a lot of that legacy code was actually worse for everyone than iteratively modernising the core, even if it’s harder / slower.

I know I’m s-l-o-w at doing stuff with everything else that’s going on. I know I procrastinate too much and sometimes find it tough to get motivated. But time and again, the community spirit here has brought me out of the funk and I actually get stuff done in a burst of activity.

Part of me wants to just ditch swathes of the old code because it’s sometimes maddening. But the rational side of me says there’s a better way to do things if we weave code in clever shapes with one eye on the past and two on the future. Maybe I’m wrong. Maybe someone cleverer than me will come in and say “this is how it should be done” and line our path in gold code, I don’t know.

For now, I can (finally) see a win by adding theme capability that will open up Txp to new people, while allowing existing users to retain their time investment. It’s something I think will work — heck, it needs to work — if (and it’s a big if) we can figure out what to do with Sections when importing a theme. That’s something that wouldn’t change with a reboot, unless we fundamentally altered what makes Textpattern Textpattern (i.e. the way that Pages and Styles are assigned to Sections).

There’s a solution out there somewhere to theme Nirvana, I just need loads of ideas to be thrown at me until it sparks some ingenious approach. Thank you everyone for the fish, from amoeba to whales, that have been hurled this way so far. With every comment, I get closer to working it out in my head. Someone’ll help hit upon the ultimate process very soon, I’m sure, and then nothing’ll stand in my way to get the code in place.

jstubbs · 2015-06-22 02:52:40

Just a note re Kirby – I installed it locally to see what its like and its pretty ok, but don’t like the templating language either. Installed Craft too and didn’t like the admin panel AT ALL. Interesting to check out the competition, but Textpattern is still better, at least for me. :)

hcgtv · 2015-06-22 03:23:46

Installed 4.6dev on my local server, shiny new VM running Debian “Jessie”.

Really liking the backend, wish I could turn off the tag builders on the Pages and Forms tabs with a switch, have it looking like the Styles tab.

Anyway, the default install took me to the Textpattern_Semantic_Model, the graphic of the building blocks got me thinking. So I went into the 4.6dev backend and created a section called Test, left the defaults, clicked My site, there was the Test section on the top menu, right next to Articles.

Which brought me here, to this post – I don’t think Sections should be part of “Themes”. A section is a door out to the world, where you attach a theme to. The end user should control the sections, we can automate the Styles, Pages and Forms for him/her, which is 99.5% of the work.

Also, paying attention to the building blocks graphic, the backend Presentation drop down menu could read Sections, Styles, Pages, Forms – no?

Back to Jessie…

Bloke · 2015-06-22 08:35:41

hcgtv wrote #291761:

Installed 4.6dev… wish I could turn off the tag builders

Glad you like the direction. That’s only the half of it, though. Phil’s next iteration is a two-column affair that has pretty much ditched the tag builders (the intention is to probably make them collapsible so they take up almost no space). Preview.

I don’t think Sections should be part of “Themes”.

I’m rapidly coming to the same conclusion. It does reduce the immediacy of installing a theme, selecting it from the back end and having it “there”, but that’s far less invasive than having it automatically create Sections and assign them. That’d potentially wreak havoc with tags like <txp:section_list /> which, by default, would alter your existing templates when the new one was installed by adding new Sections to your installation. Not helpful.

If that’s the case, the path is clearer. The README that accompanies the theme could indicate which Pages/Styles suit which type of Section as a hint to the designer. That way, they know which ones would fit into their own Section structure. By selecting the new Theme to work on, it’d only be a case of making a few assignments and previewing it, without any other automated nastiness creeping in. Rolling it out across the patch is then a case of assigning any remaining Sections and switching it Live.

The only remaining issue then is the flat files vs database vs hybrid approach, and the ensuing backwards compatibility debate that it raises.

the backend Presentation drop down menu could read Sections, Styles, Pages, Forms

Change the order? Sure, no sweat. If Phil agrees, it’s a one line switch in txplib_head.php.

philwareham · 2015-06-22 08:48:29

hcgtv wrote #291761:

Really liking the backend, wish I could turn off the tag builders on the Pages and Forms tabs with a switch, have it looking like the Styles tab.

You mean like this?…

Pages page

Forms page

They are in the admin-layout-update branch of Textpattern on GitHub (which I have temporarily removed and will instate again once Stef has done his descriptions feature work – maybe later today).

Textpattern CMS

Textpattern CMS support forum

#61 2015-06-20 01:39:04

Re: Textpattern themes: a plan

#62 2015-06-20 08:58:41

Re: Textpattern themes: a plan

jstubbs wrote #291723:

#63 2015-06-20 10:06:19

Re: Textpattern themes: a plan

#64 2015-06-21 16:11:07

Re: Textpattern themes: a plan

hcgtv wrote #291718:

#65 2015-06-21 16:25:10

Re: Textpattern themes: a plan

CodeWalker wrote #291719:

#66 2015-06-21 17:05:32

Re: Textpattern themes: a plan

Bloke wrote #291752:

#67 2015-06-21 20:10:05

Re: Textpattern themes: a plan

philwareham wrote

stef wrote

#68 2015-06-21 21:51:13

Re: Textpattern themes: a plan

CodeWalker wrote #291753:

#69 2015-06-22 02:52:40

Re: Textpattern themes: a plan

#70 2015-06-22 03:23:46

Re: Textpattern themes: a plan

#71 2015-06-22 08:35:41

Re: Textpattern themes: a plan

hcgtv wrote #291761:

#72 2015-06-22 08:48:29

Re: Textpattern themes: a plan

hcgtv wrote #291761:

Board footer