Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Situation report for Textpattern 4.6 and beyond
etc wrote #279498:
But every content instance needs some url identifier, of course. Well, let’s sleep on it.
I’m not sure I completely agree with that.
I’ve built plenty of sites where I’ve used content instances for parts of pages, where the content instances themselves are never referenced on their own by a URL.
Offline
Re: Situation report for Textpattern 4.6 and beyond
springworks wrote #279502:
I’ve built plenty of sites where I’ve used content instances for parts of pages, where the content instances themselves are never referenced on their own by a URL.
Interesting, do you have some Page template examples you could share?
To get this straight in my head, you have articles in sections that you don’t expose to a URL (hidden status, maybe?) but you use them internally in your Page/Forms to compile a ‘master article’ that visitors can see? Is that so you can get authors to write content in a familiar interface without having to expose them to Forms?
I’m curious how that all works, given Textpattern’s one-article-to-one-URL paradigm.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
Re: Situation report for Textpattern 4.6 and beyond
I think there’s a danger here with looking at another CMS and just trying to copy that, rather than thinking about what is the best and most flexible way of implementing CFs. I realise I may be guilty of this by mentioning ExpressionEngine earlier in this thread! ;-)
And to risk digging myself in deeper…
EE has the idea of channels as content silos. Each channel has its own set of custom fields, but one or more channels can share the same set of custom fields. Similarly, each channel can have their own specific categories and statuses too.
So with EE you can have several different sets of custom fields, categories and statuses and these can be assigned to different channels at will. Note, however, that it is not necessarily normal to have the same custom fields, categories and statuses shared between several channels of content, so individual pieces of content are very much ring-fenced in their own channel. You can only move content from one channel to another if they both share the same custom fields, categories and status groups.
URLs are primarily dependent on template groups and templates, rather than channels, so there is no direct link between a content silo (channel) and a URL structure, unless the developer decides to create one.
In Textpattern, we currently have just one content silo, which includes all the custom fields created for the site, plus (article) categories, sections and statuses. So, currently in Txp the section that a piece of content resides in is fluid and can be changed easily.
But, with section, we have an attribute of a piece of content (article) that is commonly used to decide which area of a site it lives in (and hence its URL).
Txp uses sections (and linked pages) to create site structure and, commonly, URLs.
To use the same attribute to determine what type of content is represented in that part of the site seems to be overly restrictive so I think I’m coming around to idea of needing some other “thing” to determine the data structure of a piece of content other than its position in the site navigation.
Offline
Re: Situation report for Textpattern 4.6 and beyond
springworks wrote #279504:
I’m coming around to idea of needing some other “thing” to determine the data structure of a piece of content other than its position in the site navigation.
Absolutely. Any guidance or ideas on this avenue appreciated as I wrap my head round this thing. I’ve never used EE, so my views are not tainted in that regard :-)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
Re: Situation report for Textpattern 4.6 and beyond
Bloke wrote #279503:
Interesting, do you have some Page template examples you could share?
To get this straight in my head, you have articles in sections that you don’t expose to a URL (hidden status, maybe?) but you use them internally in your Page/Forms to compile a ‘master article’ that visitors can see? Is that so you can get authors to write content in a familiar interface without having to expose them to Forms?
I’m curious how that all works, given Textpattern’s one-article-to-one-URL paradigm.
Well, my own site for example (which I’m in the process of redesigning, actually!) uses a section for the testimonials that appear on the home page. Each testimonial is a separate article in that section, but they only ever appear as part of the home page, with one testimonial chosen at random from all of the ones stored in the section.
I’ve built similar systems for several of my clients.
Offline
Re: Situation report for Textpattern 4.6 and beyond
springworks wrote #279506:
Each testimonial is a separate article in that section, but they only ever appear as part of the home page
OK, yeah, I’ve done similar things in the past. But there’s still an end point at site.com/testimonials/title-of-testimonial, since if you hide the articles you can’t get them to show up on the home page unless you do a custom query. Just because you choose not to expose it doesn’t mean Txp doesn’t make a URL which someone could stumble upon.
What you’re proposing is to break that convention, if a site admin so chooses by electing to have deliberately inaccessible content?
Sorry if I’m being dim here. Just want to get a picture in my head of how this is beneficial so I can think about it more.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
Re: Situation report for Textpattern 4.6 and beyond
Bloke wrote #279507:
OK, yeah, I’ve done similar things in the past. But there’s still an end point at
site.com/testimonials/title-of-testimonial, since if you hide the articles you can’t get them to show up on the home page unless you do a custom query. Just because you choose not to expose it doesn’t mean Txp doesn’t make a URL which someone could stumble upon.What you’re proposing is to break that convention, if a site admin so chooses by electing to have deliberately inaccessible content?
Sorry if I’m being dim here. Just want to get a picture in my head of how this is beneficial so I can think about it more.
No, you’re not being dim and I’m not sure that I’m proposing breaking the convention either. I probably just haven’t thought this through completely… ;-)
I realise that someone could stumble upon my testimonials by guessing the URL, but what’s the chance of that happening? I use rah_sitemap and hide the relevant section and articles from the sitemap.xml and there are no direct links to them in any navigation. So the only way someone would stumble upon them is by actively trying to guess the URL.
Should I try and catch requests for these pages in my templates and deal with them? And are there other possible URLs that people could guess (category, author,…) that I should do the same for too?
Offline
Re: Situation report for Textpattern 4.6 and beyond
I use rah_sitemap and hide the relevant section and articles from the sitemap.xml and there are no direct links to them in any navigation. So the only way someone would stumble upon them is by actively trying to guess the URL.
I do exactly that too for numerous different situations: testimonials are one example, book lists, bio profiles, band member profiles, quickfire blog entries are some others, and there are probably many more… Usually the content is short and doesn’t warrant a page of its own. Sometimes it’s part of a list, and sometimes I attached a #link to it and make it appear in a modal overlay.
Should I try and catch requests for these pages in my templates and deal with them?
You could build your template to also show the article_list view when an individual article is plugged into the address bar and make your canonical url reflect the section url so it’s not logged by google and co. Or you can also use a redirect script (e.g. smd_redirect or manually using .htaccess) to catch and redirect those special cases back to the section root.
TXP Builders – finely-crafted code, design and txp
Offline
Re: Situation report for Textpattern 4.6 and beyond
Interesting questions, I second Stef on EE inexperience, but this “channel” concept is worth investigation. Currently, articles are “viewable” txp units, that we just try to make more flexible. Ideally, I’m looking for the XML flexibility (you may say I’m a dreamer), so “articles” could be of very different nature:
xml
<unit type="article">
<title>My Title</title>
<body>My Body</body>
<title lang="fr">Mon Titre</title>
...
</unit>
<unit type="image">
<title>Image Title</title>
<source>http://some.url</source>
</unit>Relational db do not work like this, but some compromise should be possible.
Re testimonials, why are you using articles for that, you don’t edit them yourself, right? :) You could just store them as comments to some special ‘Testimonials’ article.
Offline
Re: Situation report for Textpattern 4.6 and beyond
etc wrote #279511:
Re testimonials, why are you using articles for that, you don’t edit them yourself, right? :) You could just store them as comments to some special ‘Testimonials’ article.
Typically testimonials are submitted to my clients in a number of different ways so manually entering themselves is the easiest way to do it.
Offline
Re: Situation report for Textpattern 4.6 and beyond
springworks wrote #279512:
Typically testimonials are submitted to my clients in a number of different ways so manually entering themselves is the easiest way to do it.
Ah, ok. But you don’t need the whole article field set (title, excerpt, …) for testimonials, they fit into comments fields, that are editable too. Then you just call
<txp:article_custom id="testimonials_article_id">
<txp:comments limit="1" sort="rand()" />
<txp:article_custom >Offline
Re: Situation report for Textpattern 4.6 and beyond
etc wrote #279516:
Ah, ok. But you don’t need the whole article field set (title, excerpt, …) for testimonials, they fit into comments fields, that are editable too. Then you just call
<txp:article_custom id="testimonials_article_id">...
True, but as a rule I turn comments off for the sites I create as they are not generally applicable.
Having testimonials as a separate content section, even if they don’t appear as a separate page in the navigation, means that my clients can add additional testimonials using the same interface they use for adding all other content types to their sites. It just makes it much easier for them to understand and maintain themselves.
Offline
Re: Situation report for Textpattern 4.6 and beyond
Probably can’t be done or you’d have already done it, but in case you’re overlooking the obvious:
When creating a prototype, it is given a name and a prefix, such as video-, sound-, pod-. So url becomes example.com/video-section/title, example.com/sound-section/title, example.com/video-section2/title, example.com/sound-title etc depending on type of url and the sections that the prototype is used in.
Please ignore if stupid and I’ll get back under my rock. Custom field changes sound wonderful, by the way. Thanks.
Dozy P My attempt at music
Offline
Re: Situation report for Textpattern 4.6 and beyond
springworks wrote #279506:
I’ve built similar systems for several of my clients.
Sorry, I’ve missed this part, I thought you are speaking of your own site only.
So back to the question whether each content unit (article) should have a publicly-accessible url identifier. Seemingly no; then what is the “thing” that maps url to content?
Offline
Re: Situation report for Textpattern 4.6 and beyond
Actually, MySQL provides a few XML functions that allow for very flexible prototypes. For example, unlimited categories could be implemented in articles Category field as
xml
<item name="Category1">some-cat</item>
<item name="Category2">another-cat</item>
<item name="Category3">yet-another-cat</item>and then query it like
... WHERE ExtractValue(`Category`, 'count(item[text()="another-cat"])') ...Same holds for custom fields. And actually, you (but not your clients) can already do it with etc_query. The question is the MySQL XML functions performance on large datasets.
Offline