Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
UCFs
Sorry, I’ve not been in the loop. Just curious… if/when UCFs land will it be possible for different Write panel layouts respective to content types? It seems like a silly question now that I write it down, but currently we have the fixed layout. I guess that will change, if/when?
Offline
Re: UCFs
Context always helps, so here is the scenario that got me thinking about it…
I’ve talked about the glossary I’m (still) aiming to get online. A bibliography and a dedicated journal will round that site out. While that has been creeping along in development at less than a sea star’s pace, I’ve been amassing and restoring vintage woodworking tools picked up from flea markets and such.
We’re still in house-hunting purgatory, so things also get shoved into mysterious cardboard boxes in half-states for better days, so I’ve been meaning to itemize the tools in some way to keep track of stock and what needs done to them; and later to record what I discover about them once the crud is removed because some tools I will keep and some I will resell, probably.
Then it occurred to me that some kind of structured inventory of my vintage tools could be a nice addition to the aforementioned site, at some point, especially as I expect to journal about some of the tools from time to time.
I wasn’t sure what the inventory could look like, though, until I recently came across eHive, which is a niche service for putting collections of all kind online. I won’t be using eHive, but the data types were useful to see and get ideas from, and it wasn’t a stretch to see Txp could easily handle the architecture if/when UCFs land.
The only thing I foresaw being a bugaboo is if we’ll still be limited to one layout, albeit a custom one. As it is, the current ‘blog’ layout is fine because journal entries and glossary articles fit the mold. But a content type for a collection item, for example, would benefit from a different panel layout than what the other types use.
Are there lights for that landing strip?
Offline
Re: UCFs
UCF is when, not if. But ‘when’ is subject to constant change :D
As far as layouts go, it’s difficult to predict how people will use the fields and I’m loathe to enforce something. But the ability to set an atbitrary “collection” (family or group, if you will) to each field is in place.
While core does not (currently) do anything with this field, if you typed “tools” into it and that matches the name of a section in your site, a plugin could take over and only display ones that match the currently selected section. Nothing to stop your plugin allowing comma separated collections so a field could appear in more than one section.
Since custom fields aren’t limited to articles any more, and there aren’t any notons of sections for other content types, enforcing this behaviour in core isn’t really viable. Plus it means anyone can use it for any purposes they desire.
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
Re: UCFs
Bloke wrote #335461:
UCF is when, not if. But ‘when’ is subject to constant change :D
Heard and understood.
it’s difficult to predict how people will use the fields and I’m loathe to enforce something…
Ok. I think I understand all that.
Just to be clear at my end, what I was imagining was something like a dynamic behaviour in the Write panel editor, where the specific fields for a given content type would show in the editor respective to whatever content type was in context. The context would be set according to, I guess, a new widget drop-down for, say, ‘Content type’.
In my example, that drop-down could be types like:
- Journal entry
- Glossary article
- Tool profile
- …
When ‘tool profile’ was selected, for example, the associated data fields would display in the main editor column in the order predetermined for that type.
How far off am I? ;)
Offline
Re: UCFs
So here’s the current, working implementation in the custom-fields branch.
Step one is to define your custom fields.
Here’s some data from the individual Edit panel for one of these fields.
Notice the ‘family’ field. That’s freeform text so you can group them however you like. In this case I’ve typed in tools and bibliography, comma-separated.
So, given these sections, it is fairly trivial to write a plugin that hooks into the section dropdown (onchange) and shows only the custom fields that match the family<->section.
Of course, this is all based on the assumption that your article ‘types’ are segregated by Section. It wouldn’t make sense for you to pick Bibliography here for a tool article, but this just demonstrates that the plugin flicks between the field sets, and that the sets can overlap if you wish, allowing you to use the same field (in this case, the ‘year’ field) for different flavours of article.
Combining your publishing workflow with something like rah_wrach, which forces you to pick the section first and can’t then change it during editing the document, a second plugin (similar to the one presented below) could render only the (in-scope) custom fields that match the chosen section.
Now, while you may want this behaviour, someone else might want to hook this into category(ies). Someone else might use the family to logically group the fields on the Write panel, or to render draggable borders around the groups so users can rearrange them. Sky’s the limit.
The point is, core provides the facility to subgroup your fields, but it will dutifully render them all (per content type: article, image file, section, etc) on the relevant panel. A plugin can come along and provide implementation glue that makes sense of the family info for your specific custom field application.
Does that answer your question?
btw, the plugin code is pretty simple:
if (txpinterface === 'admin') {
new djw_meta_fetch();
}
class djw_meta_fetch
{
function __construct()
{
register_callback(array($this, 'render_js'), 'article_ui', 'section');
register_callback(array($this, 'jumpoff'), 'article', '', 1);
}
/**
* Plugin jumpoff point.
*
* @param string $evt Textpattern event
* @param string $stp Textpattern step (action)
*/
public function jumpoff($evt, $stp)
{
$available_steps = array(
'djw_section_fetch' => true,
);
if (!$stp or !bouncer($stp, $available_steps)) {
return;
}
$this->$stp();
}
public function djw_section_fetch()
{
$sec = ps('section');
$matches = safe_column('txp_meta.id', 'txp_meta', "FIND_IN_SET('".doSlash($sec)."', family)");
echo json_encode(preg_filter('/^/', 'custom-', $matches));
exit;
}
public function render_js($evt, $stp, $html, $rs)
{
$js = script_js(<<<EOJS
jQuery(function() {
jQuery('#section').on('change', djw_rebuild_cfs).change();
});
function djw_rebuild_cfs() {
let sec = jQuery('#section').val();
sendAsyncEvent(
{
event: textpattern.event,
step: 'djw_section_fetch',
section: sec
}, function (data) {
$('#txp-custom-field-group-content .txp-form-field').hide();
jQuery.each(data, function(idx, obj) {
jQuery('#'+obj).closest('.txp-form-field').show();
});
},
'json');
}
EOJS
);
return $html.$js;
}
}Last edited by Bloke (2023-06-02 22:08:56)
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
Re: UCFs
If we adopt this ‘plugin’ approach, we should also tweak public tags/callbacks, to avoid trying to retrieve/filter/sort irrelevant fields. Currently, processing
<txp:artice_custom section="bibliography" year="2023" />txp will try to retrieve maker cf too, wasting memory/runtime.
Offline
Re: UCFs
Oooh I like it! It should already filter out ones that are not in scope (expired or not yet published) but if we can make it easier for plugins to filter out fields too, that’d be ace.
As long as we recognise that the family is totally flexible and in no way tied to section or anything else in core processing, that’s cool.
Last edited by Bloke (2023-06-04 07:38:15)
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
Re: UCFs
Thanks for taking the time to lay that out, Bloke. I appreciate it.
Offline
Re: UCFs
Something else crossed my noodle today as I was adding a couple of records to the Bibliography, er… Links panel.
Currently I use J’s jcr_links_custom to gain a few more fields for crafting biblio entries. The end result is pretty good. I’ve got well structured biblio sources with a little fudging here and there.
Where I’m limited is with the behavior of the default Links panel table in relation to the custom fields. It only gives me the option to hide/show the core fields, which is not really helpful in my special use-case of links. As a result I spend way too much time having to open and close individual records to see what is there and how several fields are actually filled.
I suppose when UCFs land, there will be more control of what columns I can display in the default table? Or does that also require a plugin (perhaps a modification to jcr_links_custom)?
Oh, another feature I would love to see in the Links panel is a duplicate link function similar to what is in the Write and Forms panels. It would save me so much time to add new records (editing a new one with existing data) by not having to relearn the purposes of the fields between each string of months I visit the form. Currently I have to have three tabs open to enter a record correctly (public side biblio list, existing record for example, new record to fill). A duplicate link would simplify that process.
Last edited by Destry (2023-12-21 14:12:26)
Offline
Re: UCFs
Oh, another feature I would love to see in the Links panel is a duplicate link function similar to what is in the Write and Forms panels.
That is something that would nice to have, particularly if you use some custom fields (as you and I do with that little plugin from jakob. Could even be added right now, I think.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline
Offline
Re: UCFs
Destry wrote #336198:
another feature I would love to see in the Links panel is a duplicate link function
A few things:
- If you duplicate the same link twice, the name will be the same for both (with
_copyappended each time). - There’s no multi-edit facility to do the same (yet?)
Only lightly tested. Feedback welcome.
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