Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Offline
Re: Articles / snippets that have no URL + don't show in feeds
etc wrote #320837:
. . . that’s what we’d love to see in txp 5.
That sounds good. I should still be kicking.
Offline
Re: Articles / snippets that have no URL + don't show in feeds
Destry wrote #320830:
. . . having a Content > Components panel, which I think offers more utility for smaller site needs, without clogging up the Forms or Articles tables, or having to filter out articles with extra plugins. (And I’d suggest using components as the semantic for that since it is what the enterprise content management world calls such chunks.)
On second thought, I think the emphasis of a ‘components’ semantic should should go on the UCFs, since they will be the core essence of content in Txp; the elemental building blocks. Up to now, calling them ‘unlimited custom fields’ has largely been for lack of a better way to talk about them (or to describe the extended functionality), but I don’t think that’s a good final semantic. It’s a little loose and sloppy. All of those core content elements should be thought of as content components at that point, not UI controls.
In which case, what I was saying in line of Colak’s original idea, about a components panel (i.e. Content > Components) might feasibly be something different to make the distinction. But I’m not convinced ‘snippets’ is the best choice, though, which could mean code as much as text, and that’s kind of what forms are about, in my mind, and those are not what all writers should have access to since they play a big role in architecture too. Maybe ‘inserts’ (Content > Inserts), or maybe it’s a special kind of components, to keep focused on that notion of component content management (Content > Insert components). Then again, maybe that’s just implied if we adopt the ‘components’ model in general, thus ‘inserts’ could suffice.
Anyway, the point is, you might want to start getting away from the ‘unlimited custom fields’ reference early before it becomes another deep-rooted unfortunate based on obsolete history. Just a thought.
Offline
Re: Articles / snippets that have no URL + don't show in feeds
Maybe I do not understand the scope for this.
I can understand components/snippets/items/whatever as a front end page content building method whose users will be the writers and staff writers.
these components should in such cases have privileges. ie a design component could have a read only privilege by writers who will be able to insert them by using a new tag. A textual component could be that is editable by its author, staff writers etc.
The list can go on here but there is an issue that it was not discussed yet, and that is the issue of search results. My initial example for this was for author bios. If txp version X introduces this feature, I am not sure how the search results will look. Will txp be able to recognise which ‘urls’ (I am purposefully to calling them articles) the components are used in and return links to those urls? As such maybe another feature will be needed on a per/component basis to tick a box in order to make the component searchable.
Should these items be called using a basic self closing tag?
Should short-tags be moved here? Are they not already some kind of a component which can be partially edited by writers? (think yield)
Front end pages can be seen as a composition of various components anyway. Is the idea of this to give more control to staff writers, writers, etc as to not only what but also where it appears in a page? This is a very radical idea which might return many unexpected results unless those components are well sanitised by the designers.
And the final comment. What will happen with backward compatibility? Will there be a script to migrate the content of existing sites in their new environment?
Will these sites be upgraded relatively painlessly or will their content become totally inaccessible and their design a total mess?
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline
Re: Articles / snippets that have no URL + don't show in feeds
Further to what Destry says, the implementation of unlimited custom fields is actually referred to internally as the meta store because it stores metadata about your content, over and above the core components.
Not sure if that helps or hinders this discussion.
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: Articles / snippets that have no URL + don't show in feeds
I seem to have opened a can of worms here, and I should emphasise that my elaboration earlier about non-url section permlink schemes / non-theme sections was just what I had understood from earlier discussions and nothing “official”. While I began thinking of “items”* as a parallel mechanism to articles – and still like that idea – I do see that the method using a non-url permlink scheme or a non-theme section is easier to implement now/soon … maybe even already for txp 4.8?
Whether the future direction will be articles as now with more flexible custom/meta fields, or a parallel mechanism to articles with all the txp-tags opened up to work with them, or a universal content container with different field sets where articles, images, files, links (… and by extension other future/user-definable content types) are all variants of that will depend, I suspect, largely on the devs. The latter sounds attractive but also not like something that will happen anytime soon.
*I personally liked the terms ‘items’ for its non-technical name, because it can stand as a placeholder for all manner of things, e.g. other types of content. It’s not too technical and doesn’t have to refer to specific parts of a site structure or page design, it can be a thing (event, personal bio, contact block, book, film but also slider panel or ticker item …)
colak wrote #320849:
but there is an issue that it was not discussed yet, and that is the issue of search results.
That is a very good question, especially when such items/components/url-less articles appear on other “parent” pages. Hmm. Maybe to begin with they are not searchable because you can’t really “know” where they have been used (but see one option below).
In your example with authors: if you want there to be author pages reachable via an url, then I would imagine regular articles would be the way to go. If (for argument’s sake) you were using the hypothetical non-url permlink scheme outlined earlier, then a) you can decide in the section settings whether the author section should be searchable and b) in your search_results form, you could use if_section to output the links for that section differently, for example to /people#author-name.
What will happen with backward compatibility? Will there be a script to migrate the content of existing sites in their new environment? Will these sites be upgraded relatively painlessly or will their content become totally inaccessible and their design a total mess?
I’m not sure I’ve followed you there. My educated guess is that underlying changes to the model (for example to content fields or field types) would need update/migration scripts as has always been the case when upgrading to a new txp version. There might be some one-off special cases for non-core but commonly used plugins, for example an extra run-and-self-disable migration plugin to migrate glz_custom_fields to the new core custom fields.
If there are going to be new content types with new tags, older sites won’t have any idea about their usage, so they would, I guess, be unchanged. It’s just a new facility (like when you use a plugin). So, is your question about how updates will be in future when people have more varied site setups?
EDIT: My apologies: Scratch that last question: I’ve read the past posts again more closely and realise now you were referring, I guess, to the page-builder model out of a series of descending blocks/chunks/components and how one transfers from the article-based model we have now to that.. To be honest I think that’s a whole new discussion about a completely different page model. WP has been going through this with the gutenberg block project and some other CMSs were always built that way (typo3 for example, Twill is a newer CMS that does that really well). That’s a page construction method that Textpattern’s not so well suited to (at least when the regular user should be able to do that) though shortcode tags work well there if the user can trained in using them.
TXP Builders – finely-crafted code, design and txp
Offline
Re: Articles / snippets that have no URL + don't show in feeds
FWIW, I think the article convention we have is nice:
- A thing.
- In a section.
- With a given URL (that we may or may not permit to be optional to ‘hide’ it from the main flow and divert this list of content elsewhere to be managed).
- With a title.
- With an (optional, but likely-to-be-populated) block of body content.
- An optional excerpt.
- Some additional metadata fields, that are at the discretion of the site designer.
That, to me, is Textpattern’s strength. It doesn’t require you to build entire page structures before you can use any of this stuff because the content type is largely pre-defined. If you have to start defining content types, you get into all sorts of bother as jakob says, just like WP have with the guttenberg fiasco.
That’s not to say we can’t allow you in some future version to define your own content types or tweak the baked-in ones to taste, I’m just saying I don’t think we should get rid of the core types because they serve a very useful purpose: they allow you to Just Write.
The notion of what happens to included content in terms of search is an interesting one. I don’t have an answer to that. Will require some thought.
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