Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Static Pages
Here’s a quick mockup…note that I intended the “hybrids” node to be a child of “cars”, not a parallel/sibling
+--------------+
| Node (cars) +----------------+
|--------------| |
| static content |
| | +-----+--------+
+-----+-----+--+ |Node (hybrids)|
| | |--------------|
+--+---+-+ ++--+-----+ | |
|article | | article | | static content
+--------+ +---------+ +-+-----+------+
| |
| |
+------+---+ |
|article | | +-------------+
+----------+ +---+Domestic hybrids
|-------------|
| |
| "They suck" |
| |
| |
+-------+-----+
|
+--++---------+
| article |
| |
+-------------+Using Destry’s idea, you could add different “types” of nodes and say which metadata would be associated with each. So some nodes would have a title and a description and an image, while others might have a description and a region and an ID# etc.
Not shown above are nodes that are not attached to a category. (Nodes that are not used as collections for articles, but more for simple static content)
I have a couple of thoughts as to the interface of this new “Nodes” tab
- The Nodes should not be separated by type (e.g. with separate tabs)
- The interface should accommodate creating and managing quite a lot of nodes
- The interface organize the nodes visually and even make clear when nodes have multiple parents (I realize this is really pushing it)
Another idea would be an option to pull node data and hierarchy from a directory structure of nested folders and files.
Last edited by jdueck (2011-12-16 04:22:22)
Offline
Re: Static Pages
jdueck wrote:
I’m also sensitive to the need to not upset the current UI framework too much. But long-range, I don’t know if it’s possible to avoid a reboot of some kind.
Textpattern CMS v5 is supposed to be a reboot of sorts, I think, so now would be a good time to talk about these things.
I’m afraid of making the current framework too baroque…a third level of tabs? Hmm
Third level already exists in at least one case. Admin > Preferences > Advanced (for example). And if one is using a theme providing smarter navigation, (for example), it’s even less of an issue from a usability (or baroque) standpoint.
It just occurs to me that Gille’s tutorial might be relevant to this stuff, though I haven’t looked at it closely:
Last edited by Destry (2011-12-16 13:44:20)
Offline
Re: Static Pages
My question is, Does the node concept seem like a sensible way to enhance Textpattern’s capabilities as a CMS? We wouldn’t have to call them “nodes,” it’s just the first/most obvious word that came to my mind.
Offline
Re: Static Pages
Do like: Easy way to get more depth.
Dont’ like: Adding different static content models. Too much complexity, especially thinking about extra tags. Generic feels better. I even like the idea of banishing the concept of a section and just using a tree of articles for everything.
But I’m a bit biased, since I started doing some sites with another CMS/F that works that way.
Edit: BTW, I’ll bet Sam W. has some ideas. He’s done a lot of thinking on this with Escher.
Last edited by maruchan (2011-12-17 04:01:47)
Offline
Re: Static Pages
Another proposal: Keep it simple
New feature: Relate category (metadata) and one (standard) article via article ID.
(The same works for sections or other content types)
In category context the content from the related article ID is fetched.
Standard article_custom tag fetches the related article ID and handles the output.
Advantage: You won’t need complex txp:if_category (or if_article_category?) if/else spaghetti code trees.
Advantage: Clients can handle the articles (and don’t have to mess with pages and forms).
Default: No related article ID = no output. The same for empty fields.
Optional: If the article should be handled in a special way admin stores it in a different section.
Get all online mentions of Textpattern via OPML subscription: TXP Info Sources: Textpattern RSS feeds as dynamic OPML
Offline
Re: Static Pages
I use today more and more sections like “content type”
To repeat the example of Destry, I created sections
- FAQs
- Book reviews,
- Quotes
- Blog posts
- White papers
- interviews
with rah_write_each_section I propose that the user can choose the content he wants to create and customize the write the with bot_wtc for each type of content.
The most common types of content and sections of the site are the same, but sometimes you have to find something other than the sections for cutting sections of the site. I then use directly the categories as sections and keywords as categories.
What I miss is good to immediately add custom_fields to categories and sections. I always look forward to the development of the plugin “eql_section_sort”. But I think it will never happen.
Offline