Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#21 2020-01-01 21:42:56

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 3,892
Website

Re: Articles / snippets that have no URL + don't show in feeds

phiw13 wrote #320783:

One use case I had in mind was a message snippet (complete with HTML formatting) that occasionally appears on the site (Front page, and/or section listings page, …). It is not an article, multiple people should be able to eventually edit it and insert it.

That kind of situation is pretty much covered by mck_snippet. It provides you with an editable textarea and title which you can optionally run through textile or through a form that can be switched on and off and placed on a page. If you assign them to what marco called “zones” (a bit like freeform category names), you can output several at once. Ideal for front-side notices, ad blocks and the like but otherwise fairly limited as there are only two fields and no other output control logic. You can see the help file here. I resurrected the basic functionality but not the admin-side dragsort or the front-side edit-in-place facility.


TXP Builders – finely-crafted code, design and txp

Offline

#22 2020-01-01 23:13:27

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 3,892
Website

Re: Articles / snippets that have no URL + don't show in feeds

colak wrote #320779:

It is just that I do not feel that articles linked to a none section, as discussed by Stef would be the right one of this type of functionality. If these items are added via the write tab, how will they be added to articles?

I was also in favour of the txp:item concept but just to clarify: I don’t think the idea was to have a none section. Rather, the idea that Oleg/Stef proposed is to use the existing Textpattern structure, i.e. one can still use sections to structure such information but those sections are assigned a no permlink url-scheme (or alternatively no theme page template).

You could therefore have a “bios” section, or a “services” section with no url-scheme and the articles would still have all the fields (and custom fields) you assign just like a regular article (including an article_url_title) but they wouldn’t be routed to a “/section/article-url-title” reachable via an url in the browser.

By way of example, you might have the following in the page template for an organisation’s about page:

<main>
    <txp:article listform="static_content" />

    <txp:section_list sections="services, staff, clients, testimonials">
        <section class="panel  <txp:section />-panel">
            <h2 id="<txp:section />"><txp:section title="1" /></h2>
            <txp:article_custom section='<txp:section />' form='<txp_section />_card' … />
        </section>
    </txp:section_list>
</main>

with corresponding services_card, staff_card, client_card, testimonials_card forms for outputting each section in the desired format, e.g. a grid of staff members, a testimonials slider, a grid of client logos and so on. This is just an example, but you get the picture.

Your services, staff, clients, and testimonials sections would be no-permlink url schemes (or no-theme), so they would not be reachable via /services/design or /staff/staff-name. You could, however, use article_url_title to set html id attributes to create /about#staff-name scroll-to anchors.

That’s perhaps a trivial example: you could write a single long /about article, or your could write an article each for services, staff, clients, testimonials in the /about section and add your own HTML markup to div-up the respective entries.
But as soon as a site gets a bit more complex, it helps. Jonathan’s solborg.fhs.no site has a list of staff members of the whole school with contact details in one section and those profiles occur again elsewhere under each different course topic.
At Neme, you might have a pool of visitors/contributors/artists/speakers which feature again and again on your site in different places or in different constellations for various events.

This structure would lend itself well, for example, for all those one-page sites with a series of successive ribbon-like “slide panels” and a jump-to menu at the top or side of the page. Each “panel” would be its own section with own articles but we would no longer have to stop those pages being rss-ed or accessed individually in the browser.

I would expect such items to grow to hundreds. Think of sites with many writers for example.

I agree. That was why I asked about a way of excerpting certain sections to their own list panel. Stef has added a callback that allows you filter out items from the article list by using a small plugin. That’s part one of separating them out.

Part two is outputting that content in a different way in its own Content › Area, which would effectively make it possible to have separate Content › Staff and Content › Services admin panes, etc. That would require writing a plugin to do that, but only for the article_list filter and the new list panel: the article edit pane is the same.

I’ve not had the time to explore that yet but I’d love, for example, to separate out a calendar of forthcoming events – e.g. lesson dates, workshops or courses, book readings, cinema nights or band gigs – listed by date in the admin area. On the public side, past events automatically disappear from the list and appear in the “past events” list as time passes. Likewise, a Content › Slider item in which I can see the articles in the slider section listed along with their respective article_image … and there are many more such examples…


TXP Builders – finely-crafted code, design and txp

Offline

#23 2020-01-02 08:47:16

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 2,038
Website

Re: Articles / snippets that have no URL + don't show in feeds

jakob wrote #320788:

That kind of situation is pretty much covered by mck_snippet.

What I mentioned above is just an example (and a very basic one at that). In your subsequent answer you did clarify how the whole concept would eventually be and work. Much more than Stef explanation in the other thread. Thanks for that.

And I’ve never had any use yet for that in a Textpattern context, actually. But thanks for pointing out that that extension is still functional and would have me covered now in case of (a simple) need.

[…] but not the admin-side dragsort

That is a feature I think -:)


Where is that emoji for a solar powered submarine when you need it ?

Offline

#24 2020-01-04 19:32:23

Destry
Member
From: Haut-Rhin
Registered: 2004-08-04
Posts: 4,415
Website

Re: Articles / snippets that have no URL + don't show in feeds

I’m just kind of following all this. I think I get the idea of URL-less sections. The way Jakob described them just above makes sense. And that seems really useful for large-site needs like that.

But I also like Colak’s notion of 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.)

In a way, that’s what I see unlimited custom fields (UCFs) being, content components. But I get there might be a conflict with how things are tied together in core. So what I think I’m imagining here is a combination of UCFs and components.

For example, UCFs have landed and I’m on the Write panel with a custom content type, most of which is pieced together with custom fields as expected. But maybe I want to add a contextual call to action — e.g. a ‘See this related article’ — between parts of the content type, which is a very common thing publishers do these days online. I don’t want that call to action to be a part of the main content item, so it has to be a separate kind of field, I suppose, but still addable via the Write panel in the construction order of the chunked ‘article’:

  • Title
  • CF a
  • CF b
  • CF c
  • CTA
  • CF d
  • CF e
  • CF f
  • etc

So in that ‘CTA’ case you have a special box, and in that box might go a tag like <txp:component id="1" />, which is pulling from Content > Components and is treated entirely unrelated to the ‘article’ other than just being inserted between its pieces, like a benign tumor.

This kind of thing seems like it should be very doable in another version or two, no? The whole idea with UCFs being to get away from the age-old problem of dumping everything into the Body blob.

Speaking of which, and diverging here, but when UCFs do land, it would be really nice to get rid of the default ‘Body’ and ‘Excerpt’ fields, since they would just become parts of the component model. In fact, I think keeping the ‘Body’ field will only make it confusing in that case because people have been conditioned for so long to dump everything into the body ‘blob’ field. By removing that crutch you help people learn and adapt to the new model faster.

I’d even say you could do away with the separate ‘Article Image’ widget and make that part of the new component construction idea too. For example, maybe I have a long-form epub and want to use a cover, frontispiece, and chapter images…

  • Title
  • CF a (cover)
  • CF b (frontispiece)
  • CF c
  • CF d
  • CF e (chapter 1 image)
  • CF f
  • CF g
  • CF h
  • CF i (chapter 2 image)
  • etc

As it is now one might be inclined to assign article image as the cover image, but the point is, why have a single dedicated image when any custom field could be an image container?

UCFs make every content component custom at that point. Everything generic, like elemental building blocks, enabling any number of custom content types built from scratch.

Maybe this is Txp version 15.3 ?

Offline

#25 2020-01-04 21:00:31

etc
Developer
Registered: 2010-11-11
Posts: 3,768
Website

Re: Articles / snippets that have no URL + don't show in feeds

Destry wrote #320830:

Maybe this is Txp version 15.3 ?

I wouldn’t bet on 4.9 for bw-compatibility reasons, but that’s what we’d love to see in txp 5.

Offline

#26 2020-01-05 09:34:03

Destry
Member
From: Haut-Rhin
Registered: 2004-08-04
Posts: 4,415
Website

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

#27 2020-01-05 13:26:56

Destry
Member
From: Haut-Rhin
Registered: 2004-08-04
Posts: 4,415
Website

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

#28 2020-01-05 14:43:28

colak
Admin
From: Cyprus
Registered: 2004-11-20
Posts: 8,159
Website

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.org | hblack.net | LABS | State Machines | NeMe @ github | Covid-19; a resource
I do my best editing after I click on the submit button.

Offline

#29 2020-01-05 17:48:03

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 9,637
Website

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

#30 2020-01-05 19:20:15

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 3,892
Website

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

Board footer

Powered by FluxBB