Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#37 2009-08-11 02:01:24

johnstephens
Plugin Author
From: Woodbridge, VA
Registered: 2008-06-01
Posts: 999
Website

Re: Improvements to Content Control

I mean what do sections really offer? why would categories not be sufficient like in WordPress?

Categories provide semantic links between content, sections offer site structure. Categories create relationships based on meaning across sections, which form the big buckets of site content.

Offline

#38 2009-08-11 11:22:35

driz
Member
From: Huddersfield, UK
Registered: 2008-03-18
Posts: 441
Website

Re: Improvements to Content Control

Quoting hakjon “One thing that could be done is to move all organization to categories and assign categories to sections for their presentation. So sections get removed from the url, but when items in category X are retrieved we know it belongs in section Y and we apply the appropriate page. This actually removes the presentation aspect even more from the client who should really be thinking of where things belong.”

I think this sounds quite good. But I still think sections need to be more like categories so we get double the amount of control.


~ Cameron

Offline

#39 2009-08-11 15:28:35

johnstephens
Plugin Author
From: Woodbridge, VA
Registered: 2008-06-01
Posts: 999
Website

Re: Improvements to Content Control

Quoting hakjon…

I saw Patrick’s post. But I think the suggestion ignores a very important difference between categories and sections: categories are based on meaning, sections are based on presentation. In Textpattern you can choose to arrange your content by either one or both (graphicpush) is a good example of a site with only one section to speak of, which uses the /title url scheme).

This suggestion would fundamentally alter Textpattern, and in my oppinion degrade it, by removing that choice. Sections are presentational— they define the url, page template, and styles used. Categories are not presentational— they create links between content based on shared meaning rather than shared presentation.

Again, in Textpattern, it’s up to the intelligent designer to choose a sensible way to organize the content, informed by one’s knowledge of the client and the site’s communication needs. The existing system gives you two very different options that can work together to create very robust sites. But if that’s too confusing, you can just use one, or none.

Offline

#40 2009-08-11 16:55:00

hakjoon
Member
From: Arlington, VA
Registered: 2004-07-29
Posts: 1,634
Website

Re: Improvements to Content Control

I agree that sections are presentational but I think them being in the url is a side effect. For example in a site using /title scheme you can in fact have many different sections but they are not in the url. I think sections as url artifacts is a limiting factor imo.

Sections serve to attach a certain site area to a certain presentation scheme. Those areas can be defined a number of ways. Removing sections as an organizational system doesn’t really change anything capability wise it simply changes the semantics.

The main issue for me is that in order to create certain URL structures you are forced to organize things in certain ways, and some structures are impossible out of the box using just the content writing interface, and not forcing the client to dig into the implementation aspects

Creating a site like this

/about
/welcome
/programs
/programs/overview
/calendar
/calendar/by-event

without forcing the client to create sections, assign pages and styles (even if they all use the same page and styles), can’t be done out of the box because the only way to create a nested url structure is through sections, but they all use the same presentation, so the sections are not serving their purpose which is to define presentation.

Let me make clear that I don’t see this as some huge limitation. The system is flexible enough to accommodate most demands. The flow in soem cases is just sub optimal. Static page sites for example are an area where TXP is not super great at if you can’t just have /title url schemes.

Maybe I care about the url way too much.

Last edited by hakjoon (2009-08-11 16:58:41)


Shoving is the answer – pusher robot

Offline

#41 2009-08-20 16:01:22

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,269
Website GitHub

Re: Improvements to Content Control

Just wondered if this old thread on the TXP front page was relevant here? Or does it chuck a heavy mechanic’s wrench in the workings?


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

#42 2014-10-23 09:59:14

admi
Member
From: BY
Registered: 2007-12-10
Posts: 145
Website

Re: Improvements to Content Control

Hello TXP guys!

I thought long over the issue Parent – Child Page in TXP to be similar to WP. It is useful oftent when one does not want to mess with creating sections for the sake of 3 or for child artilces. May be, somebody already came with this or better idea but let me share the method with those who may be interesed.

I used the category with the same name as so called “Parent Article” url. Thus I have something like that –

<ul class="Parent-Articles">
<txp:article_custom section="your-section"  limit="10"  sort="posted desc">
<li><txp:permlink><txp:title /></txp:permlink></li>
    <ul class="Child-Articles">
    <txp:article_custom  category='<txp:article_url_title />' limit="10"  sort="posted desc">
    <li><txp:permlink><txp:title /></txp:permlink></li>
    </txp:article_custom>
    </ul>
</txp:article_custom>
</ul>

Also one can add in the form “default” under the tag “body”, then if there are any child articles they will be listed under the parent in whatever style you set.

<ul class="Child-Articles">
<txp:article_custom  category='<txp:article_url_title />' limit="10"  sort="posted desc">
<li><txp:permlink><txp:title /></txp:permlink></li>
</txp:article_custom>
</ul>

Offline

Board footer

Powered by FluxBB