IDEA: Themes done right, via über-cats

mrdale · 2013-03-11 16:05:27

One perennial discussion at TXP is a desire for a themeing mechanism which is somewhat controversial.

For: There has to be an easier way to load a front side look in TXP (like Wordpress, Drupal)
Against: TXP is a lightweight conceptually simple framework that the wrong kind of theme mechanism would compromise, detract from and destroy.

I agree with both ideas. Which is why this morning I dusted off an old idea.

Update and EXTEND CATEGORIES to do the following:

make categories UNIVERSAL: (One category could extend across all content and presentation items ,i.e. articles, images, links, files, pages, forms, css, js)
make categories UNLIMITED: (one item could have as many categories associated as you like)
MOST IMPORTANT: Add a checkbox to the category setup which just updates the collection of items in that category to a directory set elsewhere in the UI (ie “/sets/”) when any of the items in this category is saved. The checkbox[en] could be either…
- auto/sync [] or
- sync [] in [] out

This is a lot like the *_templates plugins, but cleaner, leaner, less buggy and in core.

As far as I can tell that would get you 99% of the way to themeing in core without even touching TXPs simple conceptual model. Universal/Unlimited cats are just a no brainer (old tech now). Someone can make a plugin to switch front-side themes, based on naming conventions inside collections and applying stuff to sections.

And it extends way beyond themeing and into app building framework territory.

OK, lemme have it.

-Dale

tye · 2013-03-11 22:14:27

I’m all for it – Good work Dale

I sent a similar idea to Stef creating a section ‘like’ system for templates, with each template enveloping its own set of forms, pages & styles…. , with the section being the template name which you could enable/disable when you wanted to change templates.

Pretty much the same as above, but I think categories is a much better idea.

So I’m all for it +100000

springworks · 2013-03-12 09:53:23

Sounds very interesting. I can see that universal categories could be very powerful and save time when creating sites. It also makes sense to allow unlimited categories too.

I’m not sure what you mean by this though:

mrdale wrote:

MOST IMPORTANT: Add a checkbox to the category setup which just updates the collection of items in that category to a directory set elsewhere in the UI (ie “/sets/”) when any of the items in this category is saved. The checkbox[en] could be either…

auto/sync [] or

sync [] in [] out

What benefits would it give and what would it be used for? (I’m probably just being a bit thick here) I can’t work out what the purpose of this proposed functionality is. Is /sets/ on the public or admin side of the site? What does it do?

mrdale · 2013-03-12 15:34:53

Use cases:

Image Archive. You want to keep an up to date file copy of a certain category heirarchy of images ready to share at any time. /sets/gallery/ to include subfolders /cats and /dogs
Front Side Theme. You want a portable collection of files, ie images, pages, forms, css, js etc that always stays in sync. it get’s pushed to /sets/themes/fruitytheme/pages/myform.html and /sets/themes/fruitytheme/forms/mypage.html
Site Modules Lets say you have 20 sites that all support different combinations of some clever modular markup. each module is a collection of (forms, pages and js.) Let’s call them modules “A”, “B” and “Z”. Site “deathstar” uses “A” and “B” while site “puppylove” is more recent and uses all three, and you’ve really improved “B” recently. pushing a new version of “B” to the deathstar is just a matter of overwriting deathstar.com/sets/modules/B with the new version from puppylove.com/sets/B.
Master/Slave Module Sets In the example above, Let’s say you have 50 sites “mummy” and “kid-1” through “kid-49”. You always want to have up to date versions of “A”, “B” and “C” modules on “kid-x”. You set up a categories “A”, “B” and “C” on all sites.
- On “mummy” those cats are set to sync in [ ] out [x]
- On the rest they are set to sync in [x] out [ ]
- Then you make a symbolic link from
  kid-27.com/sets/modules/A --> mummy.com/sets/modules/A
  and “kid-27” will always have module A syncd from “mummy”

michaelkpate · 2013-03-12 19:47:15

So, how about this?

In Sections, you could still have Name, Title and Page like you do now. The Fourth Column, though, instead of Style would be Theme.

Each Theme would have it’s own set of Pages, Forms, and Styles and be segregated off into a separate namespace.

mrdale · 2013-03-13 01:55:56

That would tie a theme to section tho, no? Personally I think a theme needs to be site-wide.

What I’m suggesting is more of a site wide intelligent grouping system with an auto export/import mechanism that extends beyond themes (see example use cases).

I’ll see your orange and raise you an apple ;)

Last edited by mrdale (2013-03-13 15:03:09)

michaelkpate · 2013-03-14 14:46:59

I like the idea of being able to theme an individual section (and something that WordPress can’t do if I can be so bold to mention that) but just being able to theme a site would be a major improvement.

h33x · 2013-03-15 17:45:03

mrdale wrote:

4. Master/Slave Module Sets In the example above, Let’s say you have 50 sites “mummy” and “kid-1” through “kid-49”. You always want to have up to date versions of “A”, “B” and “C” modules on “kid-x”. You set up a categories “A”, “B” and “C” on all sites.
** On “mummy” those cats are set to sync in [ ] out [x]
** On the rest they are set to sync in [x] out [ ]
** Then you make a symbolic link from
kid-27.com/sets/modules/A --> mummy.com/sets/modules/A
and “kid-27” will always have module A syncd from “mummy”

About item 4 – I think, that this feature can create very biggest load on server , if one or few sites will be attacked from internet (DDoS or more). But anyway, this great idea! If creating this function, must be considered request per second to module and blocking him, if load more than critical restriction.

Gocom · 2013-03-15 18:45:06

In Textpattern sections are what divide a site to separate pages. They are the glue between content and presentation, giving the content the means to make itself visible. Categories on the other hand, are not part of presentation or that mix. They are essentially content. If themes were tied to something, it would be a section as Michael says, apart from that is not the case really at all.

Essentially, a theme’s assets would be collected to a single a single entity, composing a theme. This theme, like currently pages, could then be assigned to a section. Theme would basically be a ‘page template’ or ‘collection of page templates’. Nothing would really change from the current section and presentation model on that side.

The thing what a theme would need is the ability to collect it’s assets and get them to the end-users’ installations. But not necessarily using categories. It could as well be just a prefix. Common prefix, that can be used to collect the assets. And really, it should be a prefix. All assets would have to be namespaced anyway.

After that what you need is a tool that collects those assets. A compiler essentially. Textpattern does have a existing installer. So, way to install stuff is there already. The thing you do need is a way to create stuff that can be installed using that installer.

Originally we didn’t have have installer system tied into the plugin system, but now when there is, it becomes a question why some have been so inclined to create installers, opposed to compilers. Compilers, like we know, don’t need nothing from the end user. A compiled package can be installed like any other module/plugin.

As any synchronization depending system (DB-to-filesystem) goes, that ain’t fun. Syncing becomes error prone and hard to use. It creates odd scenarios where the end-user has no idea why the stuff isn’t syncing properly. Even that I’ve written those as plugins, they are not the correct way of managing content. They are workarounds over the storage limitations.

I’ve mentioned some other ways on the forums before. They are pretty shitty too, due to there being ‘meta’ data attached to the presentational entities and there is that backwards compatibility to keep.

mrdale · 2013-03-17 05:23:20

Gocom wrote: In Textpattern sections are what divide a site to separate pages. They are the glue between content and presentation, giving the content the means to make itself visible. Categories on the other hand, are not part of presentation or that mix. They are essentially content. If themes were tied to something, it would be a section as Michael says, apart from that is not the case really at all.

I agree, cats are not part of the presentation specific taxonomy. I disagree though that structured, tags or (in txp parlance) categories should be restricted to categorizing or grouping items merely in the content realm, To what end?

Clean differentiation between content/presentation is what brought me to textpattern. But I don’t see why you should not use a taxonomy to group related items of ALL types, be able to bundle them up and toss them around.

What I think you’re missing in the concept I described is that: making a few small changes to category thinking in textpattern (or calling them tags for backward compatibility reasons), would essentially allow all sorts of modularity, portability and massive time-saving in site building. The side benefit here is that it could also handle themes.

Now, I agree that the handling of themes this way is not the WP way, ie. super dumbed down “point me to your theme file” but it’s far more versatile…

But in reality, I’m just suggesting a possible way to make TXP sites super modular, at my level of expertise. Obviously there may be practicalities and implications to this approach that look a bit like a howitzer. I don’t know, I can see myself saving a tonnne of time tho if I was able to group all kinds of stuff into file groups that suck in – or out of txp via files.

Last edited by mrdale (2013-03-17 05:29:04)

Textpattern CMS

Textpattern CMS support forum

#1 2013-03-11 16:05:27

IDEA: Themes done right, via über-cats

Update and EXTEND CATEGORIES to do the following:

#2 2013-03-11 22:14:27

Re: IDEA: Themes done right, via über-cats

#3 2013-03-12 09:53:23

Re: IDEA: Themes done right, via über-cats

#4 2013-03-12 15:34:53

Re: IDEA: Themes done right, via über-cats

#5 2013-03-12 19:47:15

Re: IDEA: Themes done right, via über-cats

#6 2013-03-13 01:55:56

Re: IDEA: Themes done right, via über-cats

#7 2013-03-14 14:46:59

Re: IDEA: Themes done right, via über-cats

#8 2013-03-15 17:45:03

Re: IDEA: Themes done right, via über-cats

#9 2013-03-15 18:45:06

Re: IDEA: Themes done right, via über-cats

#10 2013-03-17 05:23:20

Re: IDEA: Themes done right, via über-cats

Board footer