Would it be interesting to categorize the sections?

Myusername · 2020-01-15 00:59:50

There are times when I need to create a site with many sections, whether they are designed to organize content, or for other things like sitemap, contact page, disclaimer (which are usually done through separate static pages on other platforms). And it’s a real mess there.

With that in mind, wouldn’t it be interesting to have a way of “categorizing” the sections? Something similar to what already happens in the forms tab.

I think it would be a great thing especially for those who have clients like me. It would not be nice if one of them inadvertently deleted something, as it is mixed up in other sections.

Anyway, I do not know if this has already been discussed here, I would like your opinion.

Last edited by Myusername (2020-01-15 01:02:30)

Bloke · 2020-01-15 01:25:08

If you’re running 4.7+, I would think that Themes meet your goal of ‘categorizing’ (a.k.a. grouping) sections, pages and styles. You can make a set of assets for your article/blog content, and a separate theme (or three) for your static assets. Then specify which theme applies to which section(s) and you’ve ‘grouped’ them.

Nobody can delete assets that are in-use, so you’ve no worries there. And you benefit from development/tweaking of each section separately as you iterate the site design, all safely previewable on live data. This feature is improved in 4.8, btw, which’ll be out real soon.

If you mean that clients might inadvertently delete article content, I’m not sure how grouping sections in a bigger bucket will prevent that. Do you have some ideas or mockups of how this might work in the interface and serve to protect the content from meddlesome users?

Last edited by Bloke (2020-01-15 01:25:42)

Myusername · 2020-01-15 05:31:35

Sorry if I didn’t understand, but my idea doesn’t apply to any screens other than the “Sections” tab.

In fact, what I mean is just for the sake of the organization, and nothing more.

Think about if we could separate the sections created, not necessarily as I did in the image, as it has cleaner ways to do it, such as a drop down menu to show only what interests us at the moment.

Am I wrong to think this would be very useful?

jakob · 2020-01-15 09:44:31

Myusername wrote #321101:

Think about if we could separate the sections created …

If you look at your screenshot, you’re almost there if you sort your page by “page template”. Only the “Default” section and your login/register static pages don’t quite fit with your intended grouping (and that might be achievable through page template organisation).

… such as a drop down menu to show only what interests us at the moment

If you use the search widget to search via the page template name, you get a view with just those sections showing.

Bloke wrote #321100:

I would think that Themes meet your goal of ‘categorizing’ (a.k.a. grouping) sections, pages and styles. You can make a set of assets for your article/blog content, and a separate theme (or three) for your static assets. Then specify which theme applies to which section(s) and you’ve ‘grouped’ them.

That’s an interesting idea too. I have the concept of “theme = different design” so anchored in my brain that I hadn’t thought of the idea of sub-themes that share a design. That would allow you to make mytheme-posts, mytheme-static, mytheme-feeds themes if you need a grouping system defined by your own grouping concept.

Actually, that’s also a great idea for families of sites that share a core layout but different specific layouts for the site-specific features or layout differences. Would work nicely with multisite setups too!

Myusername wrote #321101:

… such as a drop down menu

I can’t remember what callbacks there are for the section pane, but might this kind of filter drop-down be insertable via a plugin that simply applies the respective page/theme search filter (like a pre-saved search filter). That could be useful on the articles page too, e.g. a section/category filter.

Bloke · 2020-01-15 11:27:03

jakob wrote #321103:

If you look at your screenshot, you’re almost there if you sort your page by “page template”.

Yes, I agree. If designs are grouped by page template, that helps a lot. In this example, as you infer, maybe ‘login’ and ‘register’ sections could share a template, with a conditional <txp:if_section> in them to detect which to display. They likely share content anyway if they’re both to do with account management.

I have the concept of “theme = different design” so anchored in my brain that I hadn’t thought of the idea of sub-themes that share a design.

Yes, it kind of works but since there’s no concept of inheritance between themes – they’re treated by Txp as independent silos – then you still have to make a physical page per section, so you do end up with duplication if your goal is to share stuff.

I swear somewhere in the mists of time I added a (hidden) theme attribute to <txp:output_form> so you could cheat: have a really super bare-bones page template and then call in logic from other themes into it via <txp::form_name theme="other-theme" />.

I’m pretty sure I patched fetch_form() to take an optional theme parameter, and added an attribute to taghandlers for output_form, but I can’t find either in the repo. Maybe I only did it locally and abandoned it. I guess it could make things super tricky to debug if someone shared form content that way from a second theme in their installation, that might not be installed on someone else’s system who downloads that first theme and tries to use it. That’s probably why I never commited it. Compartmentalising themes seems safer.

jakob · 2020-01-15 11:41:49

Bloke wrote #321109:

Yes, I agree. If designs are grouped by page template, that helps a lot. In this example, as you infer, maybe ‘login’ and ‘register’ sections could share a template, with a conditional <txp:if_section> in them to detect which to display.

Or even all static_page with the login / register form called in the article.

Yes, it kind of works but since there’s no concept of inheritance between themes – they’re treated by Txp as independent silos – then you still have to make a physical page per section, so you do end up with duplication if your goal is to share stuff.

Yes, I understand there’s no inheritance (i.e. not child themes) hence my naming suggestion above. If the the parallel-(sub-)themes are not “complete themes” in themselves, then there shouldn’t be a duplication problem?

I have one collection of sites for the same education provider where they all share the same layout but each project or course they offer has its own homepage with slightly different organisational structures and features. It’s also a multisite installation. We talked a while back about sharing/symlinking to a common themes directory in multi-site setups and the problem of overwriting theme information shared between sites. This “siloing” approach by spreading the templates/forms across core-theme, site-a-theme, site-b-theme, site-c-theme themes would avoid that.

… I added a (hidden) theme attribute to <txp:output_form> so you could cheat: have a really super bare-bones page template and then call in logic from other themes into it via <txp::form_name theme="other-theme" />.

Have to say I like that idea too!

Bloke · 2020-01-15 12:02:38

jakob wrote #321110:

If the the parallel-(sub-)themes are not “complete themes” in themselves, then there shouldn’t be a duplication problem?

True.

This “siloing” approach by spreading the templates/forms across core-theme, site-a-theme, site-b-theme, site-c-theme themes would avoid that.

Also true.

Have to say I like that idea too!

So do I, but I think it might cause too much head scratching. Not sure. Mind you, if it remains an undocumented feature… :)

Myusername · 2020-01-15 14:10:04

I still think it would be interesting to implement it. In the end, there is always a way to get where we want, no matter what happens, but “getting there” is different from a real resource. In practice, we use sections for everything we do in Textpattern; managing them better than just sorting them would be essential. Anyway, I respect your opinion, and thank you for the tips

Bloke · 2020-01-15 14:17:28

fwiw, this isn’t a “no” to the feature, we’re just assessing whether existing methods might help you out. As you may know, we like to explore and think about features before just adding them :)

Grouping sections might make sense in some situations, but we need to think about the UI and impact on their general usage. Searching, sorting and pagination, for example, might become tricky if it’s not presented in a simple table.

This may be something we defer to plugins, although right now I can’t think of a neat way to intercept the output to collate the sections. There are no useful callbacks to harness as the table is being built, unfortunately.

Thank you for raising this. It’s certainly something we can bear in mind as we iterate Textpattern.

singaz · 2020-01-22 16:04:15

It would be nice to be able to hide sections in the admin panel.

To not interfere (highlighted in red)

Many sections + many service sections – difficult to manage.

jakob · 2020-01-22 16:44:55

singaz wrote #321268:

It would be nice to be able to hide sections in the admin panel.

You can do that (and more) with bot_wtc and I’m sure there was a small code snippet somewhere on the forum for making a mini-plugin to hide certain sections from certain user classes. Search for pluggable_ui, article_ui or similar…

etc · 2020-01-22 16:46:05

singaz wrote #321268:

It would be nice to be able to hide sections in the admin panel.

You can do it via a plugin, I guess, but it’s not a very good idea to use sections to output other things (sitemaps etc) than articles. Media-typed forms suit better here.

Textpattern CMS

Textpattern CMS support forum

#1 2020-01-15 00:59:50