Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
#1 2012-06-20 21:44:13
- Szorstki
- Member
- From: Poland
- Registered: 2012-05-27
- Posts: 20
[feedback] Quite hard Textpattern customizing
- Home
- Products
- For smth
- For smth else
- Contact
Seems like “Houston, we have a problem”, especially when one article should display in several places :P
First I decided to make it with categories, but all the navigation must be solved on categories then – a home page is section named “default”, there should be also search included in page template and all the categories based menu and content displaying module… Maybe I’m doing something wrong, but now I think it would be faster to use a PHP framework :P Make some SQL statements to build table for content and categories, etc. – but it’s a simple CMS again.
So, I understand that TXP gives you many possibilities to design a template for each sections, etc. but it looks like advanced content management is missing and each of TXP users have to invent the wheel again. Of course there are plugins, but they aren’t perfect – the pure cms should have this functionality. Building template for each section, when there are “subsections”? Not a good idea… Simple content (sections?) managing can solve this in really easy way.
Or I missed something in all these tutorials and topics (I hope so) ;) I couldn’t find a straight instructions “how to” make a website with more complicated structure. Just installed adi_menu, created many sections, a few pages assigned to sections… It works, but I feel like my website was made with duct tape :P (because of many sections, organized by the plugin – not cms itself)
Offline
Re: [feedback] Quite hard Textpattern customizing
but it looks like advanced content management is missing
Define “advanced”—there will always be something TXP can’t do. If you’ve run into a situation where you feel your site is held together with duct tape, there’s no need to use it. Especially if you are comfortable creating your own solution in PHP. I don’t use TXP for every site I build, but that doesn’t make me feel like it’s useless—far from it. :-)
Offline
Re: [feedback] Quite hard Textpattern customizing
You could somehow achieve subsections with gbp_permanent_links, and then also use adi_menu to reflect the section/subsection structure in the Section dropdown (in the Write tab).
With gbp_permanent_links, I have tried to approaches to get this kind of URL structure: /section/subsection/some-article-title.
Hey, Szorstki, don’t just run and try to get the plugin before finishing reading this post, just to read the documentation… because this plugin… it doesn’t have documentation. Muahahahaha!
We, TXPers, learnt to tame it after many years of research and trial & error.
One is to use a mix of sections and categories.
In this case, you use gbp_permanent_links to craft URLs like this one: /some-section/some-category/some-article-title (/products/for-nailing/a-hammer)
This approach may break (or improve, you decide!) the semantics of TXP and your website, as a category isn’t exactly the same as a section
Another approach is to use sections and… sections (user pieman, tamer of gbp_permanent_links, taught me this one).
In this case, you use gbp_permanent_links to craft URLs like this one:
/some-section/some-other-section/some-article-title (i.e. /products/for-nailing/a-hammer)
But, here is the trick: when you craft this “three level” URLs, the trick is to build it, in gbp_permanent_links, like this:
/plain-text/section/title
That is, you will be crafting a URL with this 3 components:
- Plain text: for the first level section. Example:
products - Section: for the second level section. Example:
for-something - Title: for the article title. Example:
some-product
You will understand what I’m talking about once you begin tinkering with gbp_permanent_links.
Also, for each rule you create with gbp_permanent_links, you could configure that rule to use a particular page template. I find that feature really helpful, as it “unties” you for the built-in limitation of TXP to tie one template to one section, and to use the default template for many views (home page, categories, searches, etc).
Hope you can find your way thru gbp_p_l. If not, ask here, or better yet, at plugin’s thread.
PS: duct tape? You may be the Duct Tape programmer
Offline
Re: [feedback] Quite hard Textpattern customizing
Hi Szorstki,
- Home
- Products
- For smth
- For smth else
- Contact
This simple 2-Level-Navigation could be done without a plugin or hack.
- Home -> section home -> fixed article
- Products -> section products -> fixed article
- For smth -> section products -> live article
- For smth else -> section products -> live article
- Contact -> section contact -> fixed article
If you need really more than a 2-Level-Navigation, so see maniqui’s post above.
Digital nomad, sailing the world on a sailboat: 32fthome.com
Offline
#5 2012-06-21 09:14:57
- Szorstki
- Member
- From: Poland
- Registered: 2012-05-27
- Posts: 20
Re: [feedback] Quite hard Textpattern customizing
As I see gbp_permanent_links can make the feeling of my site being made of duct tape less annoying :D
But don’t you think, all these plugins (there are a lot of them, helping to solve problem of needed “subsections”) are about dividing content into pages?
trenc – “For smth” nad “For smth else” I mean that are subsections with their own articles. Just “Products” need to display articles from subsections or something like that – solution made on many sites.
I made quickly that – there are missing some options needed, like “display article from subsections”, etc., but including subsections with some options to TXP core would solve many problems and some time ;) This is just my feedback, I think managing content in Textpattern could be better and more powerful.
Offline
Re: [feedback] Quite hard Textpattern customizing
Szorstki wrote:
This is just my feedback, I think managing content in Textpattern could be better and more powerful.
Send patch ;)
Offline
#7 2012-07-11 22:43:34
- Szorstki
- Member
- From: Poland
- Registered: 2012-05-27
- Posts: 20
Re: [feedback] Quite hard Textpattern customizing
It’s just a mockup ;) as I wrote to Stef already.
I’m still thinking about best solution, even started to discover MODx to have comparison (online demo shows, that TXP has much better admin side, in MODx adding content is a mess). I’m keeping WordPress away – too much mainstream :P I think it’s too popular and dangerous with 0-day bugs…
Anyway, maybe connecting categories with sections would do the job? Then we only have to set up sections, connect category/categories (and their subcategories automatically) and specify some behavior. It’s just an idea, I have to sleep with it :P but if you have any propositions in this matter – just post it here :) Or maybe managing content on sub-levels is confusing only for me? (try to put one article in two (sub)sections or more… impossibru ) ;D
Offline
Re: [feedback] Quite hard Textpattern customizing
I’ve had the good fortune to audit a site that was running crockery recently. Yes, in a production environment; the parties shall remain nameless to protect the guilty. It had subsections — of sorts — and a host of other lovelies like per-section URL schemes.
What I came away with was that subsections are really not all that.
Why do I come to that conclusion? And how? After all, subsections have been the biggest “why can’t Textpattern do…” after unlimited cats and one-click theme switching.
I can only surmise that people who have used systems with unlimited, nestable sections haven’t actually tried to deploy a large site. Because when you do, what you gain with admin-side organisational mojo and developer-centric grandeur, quickly — very quickly in the lifecycle of a site — deteriorates into an IA and UX disconnect for visitors as the site grows.
The root of the problem is that an article can still only be in one place, at one destination URL, whether that’s site.com/pizzas/stone-baked/meaty-goodness or site.com/design-your-own/non-vegetarian/thin-base/meaty-goodness. If you’ve started down one path and want to improve the UX, you have a tree of landing pages to refactor and redirect, which is not simple. Then you’ve got the hassle of creating the tree in the first place, and the whole “inheritance or not” debate.
Crockery got round this by half faking subsections. Although you could nest them to any level, you attached an article to a subsection path defined from branch start to leaf. The article was still in one “section” it’s just that the section name was design-your-own/non-vegetarian/thin-base. The sections between the “root” branch section and the article were just printed in the URL. Although you could delete parts of the URL to nav “back up” the tree and land at certain subsections (assuming you had a page template for it), or use a breadcrumb trail, you can’t take multiple routes to the same article so visitors have to “know” how you were thinking to find content. Search helps, but search doesn’t require subsections and can be equally realised in a flat structure like Textpattern currently employs.
Yes, URLs in a subsection-aware site are prettier, but you end up with related content being scattered across multiple URL branches because one person “categorizes” an article under one subsection tree, and another person 6 months later puts new content under a different branch.
The upshot is that if we’re not building the site around its content and how visitors find that content, then all the subsections in the world don’t help: you might as well just use /title permlink scheme and be done with it.
However, a structured taxonomy — unlimited categories if you will — that can optionally be tied to a section, allows you to create real-life searching behaviour and context-sensitive content retrieval. You can then classify your articles under any number of “things” that you can limit to a section if you wish (primarily for ease of administration as the category pool grows large). Thus if you find your customers are missing an article because they’re searching for a different keyword or there’s some other disconnect, you create a new category, lodge it against the relevant section and ‘tag’ your article with it. Bridge to content made; happier customers; bigger pat-on-the-back bonus from the CEO as sales soar. And more SEO juice for free instead of a sea of 301s.
An article still only resides in one place at one endpoint URL in a flat, easy to manage structure exactly as things stand today. It retains ease of content management without the laborious admin overhead of subsection management, and gives multiple paths to the same information based on both how you present the IA and how you respond to visitors’ search habits, Piwik feedback, or whatever.
[Per-section permlinks schemes, however, are quite handy as you can designate an archive section as year/month/day which makes a lot more sense than forcing the global permlink scheme on every section]
So at the moment — as Szorstki more succinctly presented — I’m leaning towards a hybrid section->unlimited category solution instead of a pure subsection solution. But that’s just my view and I haven’t really a) thought it through, or b) consulted anyone other than my synapses about it. It might be untenable, but I think it’s doable and may open up a(nother) world of possibility for sites created with Textpattern. And means I can retire smd_tags, which will be the biggest blessing ever bestowed upon our CMS.
Flames, support, patches, or downright “you’re mad it’ll never work because…” are welcome on the subject.
Last edited by Bloke (2012-07-13 19:30:41)
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
Re: [feedback] Quite hard Textpattern customizing
Bloke wrote:
you can’t take multiple routes to the same article so visitors have to “know” how you were thinking to find content.
Depends. While this may not be desirable for non-linear organized content (e.g. shop merchandise), a tree might be the only logical way for other content collections. Think strictly hierarchical organizations or the biological classification system.
Offline
Re: [feedback] Quite hard Textpattern customizing
wet wrote: Depends. While this may not be desirable for non-linear organized content (e.g. shop merchandise), a tree might be the only logical way for other content collections. Think strictly hierarchical organizations or the biological classification system.
Exactly. Which is why it makes sense to have no limitations on category organization or page/content organization and let the author decide what is best for a given site. This is the approach I decided to take in Escher. Complete flexibility in URL hierarchy, no distinction between “page” and “section,” and unlimited categories.
Offline
Re: [feedback] Quite hard Textpattern customizing
artagesw wrote:
Exactly. Which is why it makes sense to have no limitations on category organization or page/content organization
Ideally, yes. But the inherent flexibility it offers makes the conceptual model difficult for newcomers. Quoting Zem in his old interview on txpmag:
I think Textpattern’s greatest asset is its inflexibility. Programmers are trained to write code that is infinitely reusable and modular. They’re very good at that, at minimizing limitations and assumptions. Essentially what they do is delegate up: they defer decisions, passing them up the chain of command to the higher level modules of the software. Most of the time that’s a good thing. But it’s a terrible thing when that same philosophy is applied at the highest levels of an application, at the user interface and it’s associated structure (and often at other interfaces too, like APIs and network protocols).
At those interfaces, it’s critical to understand how and why an application is used, and to simplify and minimize the decisions required of the user. That’s the opposite of what programmers normally do: taking responsibility and making decisions, instead of passing them on to the user (and, of course, knowing which decisions to make and which to leave). Businesses try to distinguish between these using two roles, analyst and programmer, but usually both roles are handled by one person. Too often the programmer takes over and they just keep delegating up. That leads to the kind of mess common in the Linux world: software that is extremely flexible, but hopelessly hostile, with every conceivable decision made into a configuration option. That places a burden on the user to discover how the software works in order to use it effectively. It’s great for geeks and people for whom tinkering is an end in itself; but very unhelpful for those who merely want to use the software as a tool.
While those sentiments may not be entirely applicable today (and I believe it was Zem who championed subsections in crockery), sometimes convention over configuration does have its place in a user interface, imo. The trick is to make those conventions:
- as transparent as possible to the end user: it just “works” and is logical, and expected behaviour for the majority of cases
- breakable, so the interface and application can grow as a user becomes more comfortable with the system, essentially migrating from the 80% ‘masses’ to the 20% ‘power user’
I agree some things lend themselves very well to a rigid hierarchy. And for those situations, Textpattern should offer a “go nuts” paradigm. But if we do manage to realize subsections / taxonomy trees or whatever, and can build in some default conventions that are overridable, we’ll be onto a serious winner. For example, making all subsections take on the Page template and permlink scheme of its ancestor — after all, they’re in the same section so should be related by design, and in 97.384% of cases having the same template (and certainly permlink scheme) will be the expected and logical choice.
Perhaps one could override the template behaviour (like the Form Override option on the Write tab that I’ve used, what, twice in six years?) so you can branch to a different Page template at a specific point in the hierarchy. Of course, then you get into the whole “should all subsections below this one get this new template, or should it just be for this one section” inheritance debacle, which is potentially UI hell.
At this point I don’t know the right answer, which is why topics like this are important to gauge how people actually use Textpattern in as many cases as we can find. Then we can distil them into sensible defaults vs overridable options and hopefully come to some codable conclusions.
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
Re: [feedback] Quite hard Textpattern customizing
Perhaps the answer is neither subsections or categories but something that appears to be a bit of both but is something new. I’ll call it a navaid.
I have mysite/trees/ and would like mysite/trees/preston/ and also mysite/trees/bradford/ and others. The way I have got round this is to have mysite/preston-tree/ and mysite/bradford-tree/. I use mysite/trees/ to list Preston Tree and Bradford Tree etc. As I have /trees/ on every page in the site navigation, this works OK because the list of trees is only one click away. Listing on the /trees/ page is semi-manual. If I create a new london-tree section, I have to also update the trees page.
I also have mysite/ebooks/ and would like mysite/ebooks/lancashire-factory-folk/ and mysite/ebooks/churches-chapels/ but instead I use mysite/ebooks/lancashire-factory-folk-chapter-1, mysite/ebooks/lancashire-factory-folk-chapter-2 etc plus mysite/ebooks/churches-chapels-chapter-1, mysite/ebooks/churches-chapels-chapter-2 etc. With this setup I have to exclude all the chapters from the /ebooks/ listing page by using a category (so that only book titles that link to title/table of contents page are shown on ebooks page).
So those are two slightly different setups which would be easier with subsections but are manageable. The trees sections all use the same page template, as do the ebooks. Ebooks have limited number of articles (number of chapters) so using that title format is OK. Trees have hundreds of articles each, so using /trees/ as the section and then long titles is out of the question.
My not-very-thought-through idea is to have a navaid. When I am in the trees section writing a new article, I could select the navaid preston and this would do some clever stuff for me. In the URL it would insert preston- before the article title (or preston/ if that doesn’t blow everything up). It would also insert it in the breadcrumb trail if I was using one (I’m not). In the article listing it would insert preston somewhere convenient (I haven’t thought this out yet).
And that’s it. Having a navaid would help with both of my subsection scenarios. There would be no need to create a subsection. Ssection page and styling would be used. The navaid would be an aid to navigation, seo and organisation which I think is the main reason for subsections. Although hierarchical structures are necessary with botany, science etc, Textpattern CMS presents articles that look good, are easy to navigate and easy to write. The two are different and I think an unlimited hierarchy/section thing may hinder rather than aid txp navigation as Stef more clearly explained above.
I suppose there could be navaids like lancashire-preston and lancashire-preston-walton for those who want more subsections. These could be converted by you dev geniuses to lancashire/preston and lancashire/preston/walton in the breadcrumbs but use hyphens in the url. And there’d have to be checks that navaid names are not used in titles etc. Then there’s .htaccess redirects and other programmy stuff I haven’t got a clue about so I’d better shut up now and hope it’s not impossible :-)
Offline