Outgrow links tab

Bloke · 2020-06-27 15:29:50

The tricky thing with treating everything as an article with a bunch of fields, while noble, is that some types just don’t fit. Primarily, image, file, video, but there are others.

You can create a “person” content type fairly easily. It has name (text), email (text/email), role (text or link to another table of roles), maybe description, some other custom fields of your liking for social media profile-du-jour, and image as an avatar… uh-oh. That last one’s not a native ‘thing’.

Now take Image as a content type. Name (filename?), alt text, caption, date created/uploaded, camera metadata as custom fields, then the image itself… uh oh. That is a file we don’t want to store in the DB; it’s a reference to an external file. It has dimensions. It has pixel density. Sure these could be additional fields. It has thumbnails of varying sizes. Hmmm, that means creating multiple ‘image objects’ and linking them together with differing dimensions in each one – and do they share alt text or is each one potentially unique? – or extending the definition of this image type with a bunch of columns that represent the other fields. The latter limits your ability to customise the content type.

Same with files. They also have physical assets stored parallel to the metadata. Things like videos might have an image used as an overlay too, and these need handling differently.

And then there’s how to get at the metadata in meaningful ways. Sure we could make a single tag <txp:get type="file" field="name" /> but that’s going to make things reeeeeeally wordy in your templates.

It’s not impossible, but the storage requirements and edge cases – let alone the flexibility to define types in meaningful ways – means that the onus becomes less on “Just write” and more on “Just configure before you can write”.

Modularising core types? Sure. We’ve started going down that route in a few places – Help is one. We could do the same with comments, so all tags and functionality are effectively bundled into a single content suite. If you disable the comments module, everything gets switched off (that’s not to be confused with having comments available but switching them off on an article).

But storing everything as “article + CFs” and then abstracting that to other types sounds like we might end up with a tonne of ‘exceptions’ in the code to handle the nuances of each type that doesn’t quite fit into the article model. We’ve only got four types – well, three because, yeah, Links could be handled as a specialised form of articles easily.

In theory of course, a custom content type is nothing other than a collection of custom fields. Some are treated in special ways (e.g. an Image field or a Video field) but they’re just metadata. There are, however, more nuances than that. Whether a type is searchable, whether to syndicate it. Does changing the alt text of an image mean it’s “updated” in terms of syndication? What happens if you delete something? How does that cascade to any assets on disk vs database?

Lots to think about.

colak · 2020-06-27 16:56:04

Bloke wrote #324056:

The tricky thing with treating everything as an article with a bunch of fields, while noble, is that some types just don’t fit. Primarily, image, file, video, but there are others.

I agree with you! That is why I just mentioned the Links tab.

… Lots to think about.

Indeed! But links at the moment basically consist of textual data and insufficient custom fields. I know the later will be dealt with and I really liked the idea of the addition of an image field but again, this could be achieved by a custom field for image_ids content, set by the user.

Unlike media types links could be as simple as they were first intended or more complex. For example, further to the requests by Destry, we should also think of including local links to this equation. Unlike external ones, the local ones could be holding just the id of the article in order to allow for URL pattern changes in the site’s lifetime (ie. <txp:permlink id="##" />). Then there is the issue of linking to section and/or category landing pages and the renaming of those sections or the changes in the URL pattern. At the moment sections and categories are not tied with ids and we may have to start thinking about those too.

We may also need to think of the rel and target attributes and any other meta information not yet in the html specs.

~~One issue that I had in the latest restructuring of the NeMe site was with the breadcrumbs tag which does not recognise the URL pattern (yet). I have built those links manually.~~ Although links related, this is not related to this thread

I can think of many ways I can achieve the above using articles in pageless sections, and I’m looking forward to unlimited grouped CFs so that I can implement them. I’m very excited with this direction!¹

Some questions.

How do you guys envisage grouped CFs in the Writers’ interface?

Will they be part of the ~~separations~~ unity tabs² in the accordion?
Instead of only having one Custom fields unity tab, will we have as many unity tabs as the designers (Role) define?

¹ Although I expect that the revamped Links pane might be able to cope too.

² I’m not sure how to call the main menu in the accordion:)

Last edited by colak (2020-06-27 17:24:24)

etc · 2020-06-27 17:46:58

Bloke wrote #324056:

The tricky thing with treating everything as an article with a bunch of fields, while noble, is that some types just don’t fit. Primarily, image, file, video, but there are others.

Note that I’ve always made a distinction between ‘physical’ images and their ‘presentation’ enhanced with captions and other garniture. And they are not exception: who says a text can not be stored in a file and imported where appropriate?

I’ve got no clear idea how things should be done. One can imagine that ‘articles’ are composed of ‘atomic’ items (like textual fields) and references to other ‘articles’ (like annotated images).

Bloke · 2020-06-27 17:51:54

etc wrote #324060:

Note that I’ve always made a distinction between ‘physical’ images and their ‘presentation’ enhanced with captions and other garniture. And they are not exception: who says a text can not be stored in a file and imported where appropriate?

True.

One can imagine that ‘articles’ are composed of ‘atomic’ items (like textual fields) and references to other ‘articles’ (like annotated images).

Also true.

etc · 2020-06-27 17:52:40

maverick wrote #324055:

I’m trying to wrap my head around some of this.

You are not alone :-) Yes, I think custom content types would be great, but many questions are still open.

etc · 2020-06-27 18:08:22

Bloke wrote #324062:

Also true.

Then we have just ‘fields’ and ‘files’ as atomic data, and just ‘article’ as content type. Current ‘images’ become image-type ‘articles’ with customizable data set (physical image, caption and whatever you need). ‘Normal’ articles can include them via ‘article_image’ field. Actually, that’s already possible, but not flexible enough.

Pat64 · 2020-12-24 15:40:48

Thank you, Stef.
What good news! Custom fields with section sensitive display will reduce the amount of elements into the “Write” page and avoid affection errors by the final users (authors).

Textpattern CMS

Textpattern CMS support forum

#11 2020-06-27 15:29:50

Re: Outgrow links tab

#12 2020-06-27 16:56:04

Re: Outgrow links tab

Bloke wrote #324056:

#13 2020-06-27 17:46:58

Re: Outgrow links tab

Bloke wrote #324056:

#14 2020-06-27 17:51:54

Re: Outgrow links tab

etc wrote #324060:

#15 2020-06-27 17:52:40

Re: Outgrow links tab

maverick wrote #324055:

#16 2020-06-27 18:08:22

Re: Outgrow links tab

Bloke wrote #324062:

#17 2020-12-24 15:40:48

Re: Outgrow links tab

Board footer