Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#1 2024-01-10 15:42:52

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

'Custom Fields' Plugins: A bibliography special case

Unlimited Custom Fields might be the most anticipated thing coming to txp in a long time. And from what I’ve seen mentioned around the boards, real power in handling them will come from specific plugins. In turn, this seems like a potential boost in plugin development like we haven’t really seen in a while (because txp core is already so versatile). Indeed, I prefer not to rely on too many plugins, but…

Is it too early to talk about CF plugins? :)

I will wait to see what people throw out for other content types, but one specific need I anticipate is for making robust bibliography entries, probably via the Links panel because I don’t want biblio sources clogging up my Articles panel table.

It shouldn’t be a terribly tall order in my use case. I already use jcr_custom_links (?) to reasonably good effect. But it could be better. Maybe that plugin is what gets modified, and that would be fine. Or maybe another one emerges specific for bibliographies.

Anyway, I fully expect a dev to hold a ransom for such work, to which I would contribute some ransom bucks. Anyone else need a bibliography plugin? :)

Basically, bibliographies are constructed of reference data types, and depending on what academic or style guide one needs to follow, those data types get assembled in one of a few ways. The arrangement shouldn’t be a problem, if I understand UCF’s correctly at this point; it’s just up to the site owner to put the fields in the order they want, or use tag magic, etc.

Fortunately, different source types (volumes, books, journal articles, news column, etc) are built from similar kinds of data, so knowing what data types are needed might be the kick-off for thinking. Here are some important ones in no particular order:

  • Author (one field for one or more authors is enough)
  • Editor (could probably use the Author field, but I suspect this should be different in case both are ever needed)
  • Date of publication
  • Article/Chapter title (this must be different from Book/Volume/Monograph/… field)
  • Book title
  • Journal/Magazine
  • Volume number
  • Issue number
  • City of publisher
  • Type (used to indicate type of medium: facsimile, video, audio, newsletter, poster, presentation, microfilm, …)
  • Date accessed
  • URI

I think that about covers data types I would need, give or take one or two I can’t think of off-hand.

The other important part of this, on the admin side, is being able to:

  1. show/hide columns for the fields above in bold in the default panel table (overriding core behaviour for Links panel)
  2. sort records by each showable column (as normal)
  3. choose what column must be key/required (understandably this may need chosen/locked in advance, in which case the ‘Book title’ field would probably be best in my case)

Note the URI is not bold. Because I’m creating biblio sources, not links, I don’t need that one to be showable in the Links panel table, which takes up too much lateral space anyway. I only need to see it in the individual item form.

And on the public side, list sources by author automatically. This is standard no matter what biblio style is followed. The implications of this is, no Sort Value field is needed in the Links panel. It can stay, if core requires it, but I’d want to hide it, or easily relabel it to purpose. Sorting output should always be done on the Author field.

Also the Date/Time stamp fields that are currently in the Links form would not be needed either. Or, as I’m currently doing now, they could be repurposed to create the ‘Date accessed’ info mentioned above, but it’s not really not functioning well for that thus it’s kind of a cludgy hack. I’d rather it was just a dedicated Date accessed field of the format: DD MMM YYYY (e.g. 3 August 1934). No hourly time. Again, the current/core time stamp fields could stay, but I’d want them hidden and obsolete in that case, if not repurposed more for the task.

Finally there might be some labeling customization included, too. I don’t know. For example, use of this plugin would effectively make the Links panel a ‘Sources’ panel, and it would make more sense for the panel to be labeled that way. Likewise the label in the form itself would change, and associated button labels.

Maybe some other small details to iron out, but I can’t think of them now.

Any learned thoughts on how this might be improved or technically possible are welcome.

Last edited by Destry (2024-01-10 16:12:57)

Offline

Board footer

Powered by FluxBB