UCFs

Destry · 2023-06-01 14:50:30

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?

Destry · 2023-06-01 15:09:51

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?

Bloke · 2023-06-01 19:11:48

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.

Destry · 2023-06-02 11:29:32

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? ;)

Bloke · 2023-06-02 21:47:22

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)

etc · 2023-06-03 09:26:33

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.

Bloke · 2023-06-03 11:30:32

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)

Destry · 2023-06-04 07:25:11

Thanks for taking the time to lay that out, Bloke. I appreciate it.

Textpattern CMS

Textpattern CMS support forum

#1 2023-06-01 14:50:30

UCFs

#2 2023-06-01 15:09:51

Re: UCFs

#3 2023-06-01 19:11:48

Re: UCFs

#4 2023-06-02 11:29:32

Re: UCFs

Bloke wrote #335461:

#5 2023-06-02 21:47:22

Re: UCFs

#6 2023-06-03 09:26:33

Re: UCFs

#7 2023-06-03 11:30:32

Re: UCFs

#8 2023-06-04 07:25:11

Re: UCFs

Board footer