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

Bloke · 2019-12-11 16:37:32

Haha, thanks. Completely forgot about that patch to the Filter() function. I’ll apply that now. Then all we need to do is figure out the checkIfNeighbour() thing and your admin side articles can be hacked out with a few lines of plugin code.

Bloke · 2019-12-11 17:01:46

Okay, try this.

You can now restrict your articles on the admin side thusly:

if (txpinterface == 'admin') {
    register_callback('abc_hide_section', 'admin_criteria', 'list_list');
    register_callback('abc_hide_section', 'txp.article', 'neighbour.criteria');
}

function abc_hide_section($evt, $stp) {
    return " AND Section != 'snippets'";
}

So the final piece of the puzzle is the public site.

colak · 2020-01-01 07:42:10

Wouldn’t it be much simpler if we had a new items tab under the Content menu and a tag like <txp:items id="1,14,5" sort="order" wraptag="" break="" class="" />? I understand that the above might have a problem with sorting but a new sort value could be added which sorts the items based on the order typed.

jakob · 2020-01-01 08:33:12

colak wrote #320777:

Wouldn’t it be much simpler if we had a new items tab under the Content menu and a tag like <txp:items id="1,14,5" sort="order" wraptag="" break="" class="" />? I understand that the above might have a problem with sorting but a new sort value could be added which sorts the items based on the order typed.

Good morning and a Happy New Year to you! Funnily enough, much of the above discussion was triggered by a suggestion I had for exactly that tag as a corresponding open ‘non-url’ content type to go alongside articles. I even looked at having a go at it as a plugin but you end up replicating a lot of the existing built-in tags that are currently hard-wired to the ‘textpattern’ table. That was my original motivation for looking at whether mck_snippets might get me there and the suggestion that Oleg and Stef came up with for using non-url or non-theme articles.

colak · 2020-01-01 08:57:04

jakob wrote #320778:

Good morning and a Happy New Year to you! Funnily enough, much of the above discussion was triggered by a suggestion I had for exactly that tag as a corresponding open ‘non-url’ content type to go alongside articles. I even looked at having a go at it as a plugin but you end up replicating a lot of the existing built-in tags that are currently hard-wired to the ‘textpattern’ table. That was my original motivation for looking at whether mck_snippets might get me there and the suggestion that Oleg and Stef came up with for using non-url or non-theme articles.

Happy new year! I followed the discussions on both threads and contributed to them. 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 would expect such items to grow to hundreds. Think of sites with many writers for example. This is where their bios could be stored unless of course another field is added in the users>authors panel… But you know what I mean:)

I would think that the items panel could be something that could be edited by people with limited permissions and it should have the same types of access as the write panel has. At the same time, these items could not be just textual. They could for example have divs (or other html or txp tags) containing images, texts, or even slight layout overrides.

jakob · 2020-01-01 09:00:03

“Great minds …” Yiannis :-) I’ve sent you a mail.

phiw13 · 2020-01-01 12:00:06

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 would expect such items to grow to hundreds. […]

I would think that the items panel could be something that could be edited by people with limited permissions and it should have the same types of access as the write panel has. At the same time, these items could not be just textual. They could for example have divs (or other html or txp tags) containing images, texts, or even slight layout overrides.

While reading this thread following a discussion with Stef in another thread the other day, I had similar thoughts. I had and still have serious trouble picturing all this as elements / articles in a zero-URL section container.

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. A form of include maybe ? Not sure yet how to describe it on a more abstract and general level.

Happy new year!

And a happy new year to you and all TXPers.

colak · 2020-01-01 12:49:28

A few more thoughts after reading Julian’s email:)

Starting with the obvious. For those designers who have clients, one thing that many people need is the address and telephone numbers of their business, many times appearing in the footer.

If those clients have no access to anything else but the Content tab, they have no way of changing that information when needed unless of course it resides in an article which is the wrong thing as it will appear in the search results.

I see items as little snippets of information which needs to be repeated in a number of pages, for my site at least for things like bios, and sponsor statements. If anything needs to change, we will only need to do it once and it will repeat itself in all articles hosting the tag.

Furthemore, these items could have different permissions. ie if somebody needs changes to the layout the item tag and editing permissions could go to the designer and above, if it is an address, it could be that all writers or the author of the item have/has editing rights. As such we could have a taxonomy for this. ie <txp:item type="design" />, <txp:item type="txt" />, and others which I can not think about just now. Having said that, the design type could be partially achieved with the override_form pulldown in the write pane, the issue remaining that the particular pulldown uses a pre-decided position in the html document where these changes will occur but the item tag could give the flexibility to have that anywhere in the text. Think of adverts appearing between paragraphs for example.

In any case, the idea of items to me could develop in the same way as the idea of forms. If we think of forms like snippets of code for our pages/sections, we can think of items as snippets of whatever for the write tab, but also for limited writer based permissions in the page design (ie footer info, adverts, etc).

jakob · 2020-01-01 21:42:56

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.

jakob · 2020-01-01 23:13:27

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…

phiw13 · 2020-01-02 08:47:16

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 -:)

Destry · 2020-01-04 19:32:23

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 ?

Textpattern CMS

Textpattern CMS support forum

#13 2019-12-11 16:37:32

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

#14 2019-12-11 17:01:46

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

#15 2020-01-01 07:42:10

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

#16 2020-01-01 08:33:12

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

colak wrote #320777:

#17 2020-01-01 08:57:04

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

jakob wrote #320778:

#18 2020-01-01 09:00:03

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

#19 2020-01-01 12:00:06

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

colak wrote #320779:

#20 2020-01-01 12:49:28

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

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

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

phiw13 wrote #320783:

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

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

colak wrote #320779:

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

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

jakob wrote #320788:

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

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

Board footer