Outgrow links tab

colak · 2020-06-27 07:22:37

Destry’s thread may actually be a good one for radically rethinking txp. One of the issues we have is that Links are not searchable from the front end. They are also very limited regarding the number of custom fields. ~~Headless~~ Pageless sections can bring this content in the write pane, make it searchable, and all we will need to worry about improving is two things.

Unlimited custom fields (which I understand that they are currently under development)
Section specific custom fields that only appear when a section is selected. jquery in combination with display:none/block css, could be our friend for this one, and it will help with the decluttering of the write tab.
- Can be achieved by adding a back-end page where CFs can be allocated to sections

Disadvantages
- Backward compatibility
- javascript dependencies for decluttering the CFs in the write tab
- Links in categories
- ids of links v ids in articles.
  - ie: I’m not sure how <txp:link id="##" /> can be migrated automatically
- The articles may become too many. ie in the NeMe site we have about 1100 link entries
Advantages
- Fewer tags as all the link tags can be deleted from the code
  - hence smaller txp footprint
- we can use the existing article and CF ones
- Searchable from the front end
Possible solutions to problems
- Stage 1: A migration script which can create CFs on the fly and duplicate that info to the articles tab
  - Addition of a page where CFs can be allocated to sections
- Stage 2: After a ~~couple~~ few of decimal versions, which will allow people to change their tags, the link tags are deleted.

Note: This is just an idea for discussion. I’m sure that I inadvertently left things out.

Last edited by colak (2020-06-27 07:37:09)

Bloke · 2020-06-27 07:36:42

Interesting but I’m not intending to remove Links from Textpattern. I use them extensively for content that I pull into other articles that is linky in nature and I don’t want to be searchable, necessarily. e.g. lists of contributors to a site, or colophon information. Such lists may or may not have web endpoints, and having built in capability to take a URL (or not) without explicitly defining a custom field is handy. Convention over configuration.

In fact, I’m thinking of augmenting links (and files) to accept images so they can be more broadly useful. It’s not much hardship to add another field like the article image and seems useful.

Combined with unlimited custom fields on all content types (including Sections, yes), this should breathe new life into the Links panel for creative uses.

By all means, if you want to migrate Links to articles, just write a quick bit of SQL to copy them over, then you can empty out the Links at your leisure. But I don’t envision removing Links from core any time soon.

colak · 2020-06-27 07:44:41

Bloke wrote #324042:

Interesting but I’m not intending to remove Links from Textpattern. I use them extensively for content that I pull into other articles that is linky in nature and I don’t want to be searchable, necessarily. e.g. lists of contributors to a site, or colophon information. Such lists may or may not have web endpoints, and having built in capability to take a URL (or not) without explicitly defining a custom field is handy. Convention over configuration.

The beauty of pageless sections is that they can be searchable or not.

In fact, I’m thinking of augmenting links (and files) to accept images so they can be more broadly useful. It’s not much hardship to add another field like the article image and seems useful.

Combined with unlimited custom fields on all content types, this should breathe new life into the Links panel for creative uses.

That is an excellent idea! As I wrote, I started this thread for discussion purposes.

BTW what do you think of adding a “page where CFs can be allocated to sections”?

Bloke · 2020-06-27 08:19:58

colak wrote #324043:

The beauty of pageless sections is that they can be searchable or not.

True.

what do you think of adding a “page where CFs can be allocated to sections”?

See minor amendments to my post I made as you were writing your reply (sorry). Section custom fields are already possible, I just need to enable them in the CF branch. I’ve only enabled article CFs right now, since they’re the most complicated. The rest are super simple to add in comparison. Just a bit of UI in each panel we want to support them and a save routine. Job done.

EDIT: or do you mean a way to map sections to a set of article CFs? That’s already possible in a way because CFs support ‘grouping’ so you could use that however you wish. Core, however, does nothing with that information beyond permitting you to define groups and assign them. It’s up to you / plugins how you use that on, say, the Write panel to auto switch fields on and off when the Section dropdown is altered.

Last edited by Bloke (2020-06-27 08:22:16)

etc · 2020-06-27 08:46:14

I secretly hope that with articles cf extra flexibility all other content types (links, etc) will be de facto abandoned by users.

phiw13 · 2020-06-27 09:20:32

etc wrote #324045:

I secretly hope that with articles cf extra flexibility all other content types (links, etc) will be de facto abandoned by users.

Why would you want that? I want to have that separation in order to build chaos without being tied to the article concept.

–^–^–

The custom field branch is something I am patiently (not) waiting for in order to be able to add custom fields to images and make it actually useful for something other than vanity projects (same for files and links to a minor extend).

colak · 2020-06-27 10:43:39

Bloke wrote #324044:

True.

See minor amendments to my post I made as you were writing your reply (sorry). Section custom fields are already possible, I just need to enable them in the CF branch. I’ve only enabled article CFs right now, since they’re the most complicated. The rest are super simple to add in comparison. Just a bit of UI in each panel we want to support them and a save routine. Job done.

This is an example of how I am currently using CFs in the NeMe site

Custom fields

CF#	CF name	Sections used	how
1	Dates	Projects, and Blog	date of event or deadline
2	img2	Projects and Blog	random thumbnail on the top of individual projects or small image that appears in the blog articles
3	venue	Projects, Blog and Texts	In Projects and Blog contains the name of the venue, in Texts it contains link ids of authors
4	venues	Projects	This is a legacy CF as I wanted to have the plural of venue. Contains the names of other venues
5	pubs	Projects and Texts and About	In projects and About, it contains the image ids of NeMe publications. In Texts it contains an image id of a book by the author of the text
6	pubs_by_others	Projects and About	In projects it contains image ids of publications by others about the whole or part of the project. In about, it contains the aforementioned image ids plus publications by others who mention NeMe
7	img_main	Projects, Blog	In individual Projects it contains the image ids of the slide show on the top. In Blog it contains a banner image
8	multi_event_pubs	Projects	contains image ids of publications which span a number of events and articles
9	Type	Blog	Used to define if this is arts news or an arts call
10	C10	projects	used to help with the deep url structure

My CFs are admittedly a mess and there are two reasons for that

Legacy CF names from the early txp days
I’ve been trying to achieve functionality using native tags and avoiding plugins

Core, however, does nothing with that information beyond permitting you to define groups and assign them.

Hmmm Is this documented? In combination with unlimited CFs, it will save many of us some of the naming and section specific issues.

Bloke · 2020-06-27 12:07:38

colak wrote #324050:

Hmmm Is this [grouping] documented?

Not until the CF branch lands in core officially. It’s a feature of unlimited custom fields, not of today’s fields.

etc · 2020-06-27 12:36:23

phiw13 wrote #324046:

Why would you want that? I want to have that separation in order to build chaos without being tied to the article concept.

–^–^–

The custom field branch is something I am patiently (not) waiting for in order to be able to add custom fields to images and make it actually useful for something other than vanity projects (same for files and links to a minor extend).

I don’t see any conceptual difference between articles, links, images (not the physical ones) and other content entities. We can differentiate them on the surface, but internally I would turn everything into ‘articles’ with customizable fields collections. This would avoid much code duplication.

maverick · 2020-06-27 15:02:08

etc wrote #324054:

We can differentiate them on the surface, but internally I would turn everything into ‘articles’ with customizable fields collections. This would avoid much code duplication.

I’m trying to wrap my head around some of this. It’s been a while since I read up on the direction of CFs development. It sounds like one possible application for grouping of CFs would essentially be setting content types. Is the accurate or is there another plan for that?

Since colak posed this as a reimagining discussion:

If so, wouldn’t it be possible to separate the groups (content types) for management in their own tabs on the admin side? Likely by plugin? (Or – still dreaming LOL – my long held wish for a built-in admin side tab builder. smd_tabber on steriods :-) ).

Thinking along the plug-in line, it might then make sense to have developer maintained admin tab plugins for the original/core content types like images & links. If you never use them – no tab. If you do – no problem. One click installs. Perhaps even in theory the article tab could become a plugin for those who want to use Textpattern in creative ways other than publishing articles.

Bonus: if someone wants a custom interface on the tab for one of the legacy types – article/image/link – it becomes easy problem.

That said – CFs, whatever their form UX-wise – are going to be fun :D

Last edited by maverick (2020-06-27 15:03:33)

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)

Textpattern CMS

Textpattern CMS support forum

#1 2020-06-27 07:22:37