Textpattern CMS support forum

You are not logged in. Register | Login | Help

#11 2019-11-20 10:28:52

Destry
Moderator
From: Haut-Rhin
Registered: 2004-08-04
Posts: 4,295
Website

Re: Documentation: overview/orientation

etc wrote #320131:

I think we should provide a very basic theme with the distribution. It could reflect the content of first steps tutorial.

Just asking for numbskull reasons… This notion of providing a scaled-down, simpler theme; doesn’t that also mean providing an alternate default template structure (i.e. besides the default blog templates)? Or are you merely suggesting a simpler ‘skin’ as an alternative to Hive for the existing default markup templates?

I ask because, I assume, that if we wanted themes for a photo blog, say, or a small business website architecture, we can’t just make a theme for that to share with people, it requires them also having the same site architecture or the theme won’t fit/work. Right? I mean, you can’t just rely on sharing a theme package to change a site architecture… or can you? Maybe I’m looking at it wrong?


Wordworkin’ for you.

Offline

#12 2019-11-20 11:37:25

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,842
Website

Re: Documentation: overview/orientation

Destry wrote #320134:

if we wanted themes for a photo blog, say, or a small business website architecture, we can’t just make a theme for that to share with people, it requires them also having the same site architecture or the theme won’t fit/work. Right?

Nope, not necessarily. The beauty of the theme system we have is that it bundles up Pages, Forms and Styles (and soon, other assets after we do a little more core tweaking) into a standalone area on disk. You can import them into a parallel theme in your site, preview them on your live content and then when you’re happy, apply them – make them live – on any Section(s) of your choosing. Mix and match to taste.


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

#13 2019-11-20 11:52:41

Destry
Moderator
From: Haut-Rhin
Registered: 2004-08-04
Posts: 4,295
Website

Re: Documentation: overview/orientation

The vision on this is more significant than I thought, then; suggesting a much different meaning of ‘theme’ than what most people are going to have, including me. Maybe we should have called it ‘Types’ or ‘Genres’ or ‘Site structures’, or whatever, because it’s a lot more than just a visual theme. That distinction will have to be spelled out and emphasized in docs (thinking aloud).

So what you’re saying, then, if in the future you tie in Sections, for example, is if I’m running a default install and the core blog setup, I could import a ‘genre’ package for ‘web magazine’ or ‘real estate agency’ and it can literally change the site structure and off I go in my new direction?


Wordworkin’ for you.

Offline

#14 2019-11-20 11:55:16

etc
Developer
Registered: 2010-11-11
Posts: 3,427
Website

Re: Documentation: overview/orientation

Destry wrote #320134:

This notion of providing a scaled-down, simpler theme; doesn’t that also mean providing an alternate default template structure (i.e. besides the default blog templates)? Or are you merely suggesting a simpler ‘skin’ as an alternative to Hive for the existing default markup templates?

What I suggest is a theme where default Page, Style and Form templates are reduced to a bare minimum (e.g. <txp:article /> plus few other tags). It would by no means be a “real” theme (with SEO etc) like Hive, but just a playground for beginners that try to understand txp workflow. As additional benefit users would learn how to switch between two themes.

I assume, that if we wanted themes for a photo blog, say, or a small business website architecture, we can’t just make a theme for that to share with people, it requires them also having the same site architecture or the theme won’t fit/work. Right? I mean, you can’t just rely on sharing a theme package to change a site architecture… or can you? Maybe I’m looking at it wrong?

You are absolutely right, themes can be related to the site structure, for example by using some specific custom fields. But the one I suggest would use only common elements, like Hive does.

Offline

#15 2019-11-20 12:01:33

Destry
Moderator
From: Haut-Rhin
Registered: 2004-08-04
Posts: 4,295
Website

Re: Documentation: overview/orientation

Thanks, guys. That was a sudden wake up. I grock it a little better now.

Again, I think the term ‘themes’ is really going to confuse people coming to this from other notions of website themes.

But, wow, so much more powerful.


Wordworkin’ for you.

Offline

#16 2019-11-20 12:03:39

etc
Developer
Registered: 2010-11-11
Posts: 3,427
Website

Re: Documentation: overview/orientation

Destry wrote #320138:

Again, I think the term ‘themes’ is really going to confuse people coming to this from other notions of website themes.

But, wow, so much more powerful.

Wait, we have not yet included plugins and prefs in the package..

Offline

#17 2019-11-20 12:31:35

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,842
Website

Re: Documentation: overview/orientation

We’ve deliberately left Sections out of theming. And, so far, content too. Although both are possible, it’s a minefield. Imagine importing a theme that has article content: where does it go? Overwrite your existing article IDs? If so, you lose content. If not, then the theme author who may have used <txp:article_custom id="1" /> in an imported Page/Form, no longer links to the article they bundled with the theme – it instead points at your article ID 1.

Same with Sections. If you have Sections default and blog linked to your existing content and you import a theme with a blog section defined and linked to the theme author’s Pages (or with different properties such as description), your live site is mashed the instant you import. And what if you have used <txp:section_list sections="about, blog, portfolio" /> and a theme adds/overwrites the blog section or uses its own sections? Your content changes to visitors.

It’s far better/safer for the theme author to bundle up section-agnostic structure and scaffolding – and that will include plugins and prefs once we figure out how to handle clashes – so the site administrator can then test (on their own live data) the theme to see if they like it, and manually apply it to the Section(s) of their choosing once they’re happy it works.

Somewhere in the dim and distant past, Bert Garcia came up with a nomenclature which we loosely adopted, although I’m not sure now if we want to stick to the distinction. Part of me likes it, another part thinks that it’s just confusing to have three ‘levels’ of theming with different capabilities. But essentially, a Package is what you were alluding to above that could make sweeping changes, whereas a simple Theme is just different presentational confetti – <div>s in different places, different colours, different way of laying out article lists, etc.

Last edited by Bloke (2019-11-20 12:39:16)


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

#18 2019-11-20 13:11:24

Destry
Moderator
From: Haut-Rhin
Registered: 2004-08-04
Posts: 4,295
Website

Re: Documentation: overview/orientation

Bloke wrote #320141:

We’ve deliberately left Sections out of theming. And, so far, content too.

Ah, yes. The actual content. How do I forget that? Another mini wake-up moment.

Same with Sections.

Okay, so there is some limit, and probably wise to keep it that way, with how deep and wide the plug-and-play game goes.

It’s far better/safer for the theme author to bundle up section-agnostic structure and scaffolding – and that will include plugins and prefs once we figure out how to handle clashes – so the site administrator can then test (on their own live data) the theme to see if they like it, and manually apply it to the Section(s) of their choosing once they’re happy it works.

Like. I’ll use some of that.

Somewhere in the dim and distant past, Bert Garcia came up with a nomenclature which we loosely adopted, although I’m not sure now if we want to stick to the distinction. Part of me likes it, another part thinks that it’s just confusing to have three ‘levels’ of theming with different capabilities. But essentially, a Package is what you were alluding to above that could make sweeping changes, whereas a simple Theme is just different presentational confetti – <div>s in different places, different colours, different way of laying out article lists, etc.

Also like, without even reviewing that yet (but I will). I think we’ll see it necessary for people to talk about this functionality (and in terms of their needs) at two levels. We could try and restrict it there: package and skin (as I did in that other thread about seasons rotation), or whatever other terms might better suggest the whole can of sardines versus just the label on it. I suspect most people will just want to mess around at the label level, at least at first until this sinks in.


Wordworkin’ for you.

Offline

#19 2019-11-20 13:28:03

Destry
Moderator
From: Haut-Rhin
Registered: 2004-08-04
Posts: 4,295
Website

Re: Documentation: overview/orientation

Bloke wrote #320141:

dim and distant past

Haha. Deja vu !

Yeah, not with the intention of forcing any semantic changes at this point, but I think I’ll be framing it in tutorials like this: ‘themes can be thought of as packages of template assets, and the simplest kind of change is at the presentation layer, or ‘skin’ layer only’. Something along those lines, with some clear demos either way.


Wordworkin’ for you.

Offline

#20 2019-11-20 13:52:00

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,842
Website

Re: Documentation: overview/orientation

Destry wrote #320145:

‘themes can be thought of as packages of template assets, and the simplest kind of change is at the presentation layer, or ‘skin’ layer only’.

Yeah, sure. At its bare minimum, a skin can be analogous with a change of Stylesheet only; that’s what CSS was designed for after all, to keep the structure the same but change the look.

Our skins (which is what they’re actually called in the code, because we’d already used ‘theme’ for administration themes) can simply be a new Stylesheet, but they can come with additional furniture to dictate where blocks like header, navigation, sidebar, footer and so forth reside in relation to one another if the author supplies Page templates.

Other themes might go further and change the way articles are laid out (usually by changing Form content) or set up list templates in year-month-date format.

Separating out what is ‘the presentation layer’ might be tricky, since we lump Pages, Forms and Stylesheets into “Presentation” in Textpattern, and that’s our only (currently) supported definition of a “Theme”.

When 4.8 rolls in, not only are we considering per-theme prefs and plugins, we’ve gone a bit further as Sections can have their own permlink schemes. Slightly OT, but this has interesting ramifications for anyone building URLs by hand in their Themes. If, for example, you as admin choose breadcrumb_title permlinks for a given Section, apply a theme where the Page/Form hard-codes /section/title links, then your resulting URL structure becomes inconsistent.

Using the <txp:> tags’ built-in link generation will of course honour the in-force permlink scheme so that is the “preferred” method if possible.

Note to self: <txp:if_section permlink="section_title, breadcrumb_title"> ... </txp:if_section> ??


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

Board footer

Powered by FluxBB