About override form

Myusername · 2020-09-17 08:13:19

I have a question about the override form.

I created an article form called “video” and used it in some articles. However, after a few minutes I didn’t want to use this form anymore, so I deleted it.

It turns out that all articles using this form are missing from the loop. But not only did they disappear, they also broke the limit attribute, since if I had a limit="3" and among those articles there is one of those “hidden articles”, would return 2 articles.

The only thing that caused the publication to be displayed again, and then the loop again to obey the limit attribute, was when I accessed the article and saved it to the default form.

I don’t want to say that it isn’t working properly, because I don’t know exactly how it was designed to work, but isn’t that a little strange? Wouldn’t it be better if used the default form if can’t find what was initially selected?

If there are many articles defined in a deleted form, it would be impossible to update them. In an ideal scenario the person should not delete an article form, but I believe that it can happen in some cases.

Is that right or am I doing something wrong?

Bloke · 2020-09-17 08:45:02

Excellent observation. That’s not a great developer experience. We should do something about this.

My inclination is to forbid deletion of in-use override forms but I’ve had some thoughts about extending their usage recently so that might not be best. I’ll have to revisit my notes and see if it still makes sense to do that, especially given that a theme import can trash pages/forms/styles if sync is switched on.

Maybe the best thing is to fall back on the ‘default’ as you say. But again, we were rather hoping to move away from this notion of “essential” templates – or at least reduce their number – so again, we’ll need to check the best approach here.

But yes, thanks for bringing this up because it’s an important issue that we need to address.

Myusername · 2020-09-17 09:48:26

Bloke wrote #325922:

My inclination is to forbid deletion of in-use override forms but I’ve had some thoughts about extending their usage recently so that might not be best.

I would say that not allowing exclusion would not be ideal.

If there are many articles with this form, how would it be possible to locate them and then assign them to another form? As far as I know, it is not possible to filter articles by the form in the article panel, right? Then you would have an impossible form to be deleted.

Bloke · 2020-09-17 10:15:19

Myusername wrote #325923:

If there are many articles with this form, how would it be possible to locate them and then assign them to another form?

Quite true. That’s not easily possible right now without using SQL. Ideas:

Add override_form to the options in the Articles panel search, and a Change override form option to the multi-edit tool.
Add a link on the Forms panel alongside each ‘Article’ type form (or all/most form types if we somehow open this up for custom types too) that will jump to the Articles panel and select all articles using that form.
In indicator on the Forms panel that shows how many assets the form is used by. Not sure if this is possible. It’ll be fine for Articles. Not so easy for other types, nor for forms in use by pages or other forms, so we’d have to ignore those.

I think the first option is still good, with perhaps the link in the Forms panel for Article types would be good:

imgur.com/a/JoiYLwo

Open to ideas on how to handle this.

etc · 2020-09-17 11:10:02

I think, whatever admin-side option, we should not expect that necessary assets exist and provide a fallback. For missing override forms I wouldn’t switch to default but rather ignore it and process the article normally, as defined by <txp:article /> attributes.

Bloke · 2020-09-17 11:45:15

etc wrote #325925:

For missing override forms I wouldn’t switch to default but rather ignore it and process the article normally, as defined by <txp:article /> attributes.

I agree. This is definitely the best option as it’s more transparent for the user. I presume we already issue a warning in debugging/testing mode if the form doesn’t exist? If so, it’s simply a case of falling back on the one set in the article(_custom) tag after triggering the warning.

Right?

etc · 2020-09-17 12:04:42

Bloke wrote #325927:

Right?

Looks right. And while we are at it, should we alter the precedence chain? Currently it is

override_form -> thing -> form

But

override_form -> form -> thing

looks more logical.

Bloke · 2020-09-17 12:44:19

etc wrote #325928:

override_form -> form -> thing... looks more logical.

Yes, but I think (I may be wrong) that the reason container comes first is for consistency with all (most?) other tags that do it that way.

Always a tricky one. Does the existence of container content mean the form attribute is ignored? Or does adding a form attribute mean that contained content is ignored?

I think the reasoning behind using container as top priority is because it can also override other attributes (e.g. active_class) so, from a usability perspective, we’re saying: “if you use container content, the form attribute (and maybe other attributes depending on context) will be ignored”.

That’s kinda more logical (to me) than saying: “if you use container content, some attributes may be ignored, but using form will override your container and then your other attributes that might have otherwise been ignored will be processed via the form” (!)

So I’d be tempted in this case to go with convention and make the order for article_(custom):

thing > override_form > form (and as fallback form if override is missing)

Not sure on the backwards-compatibility angle, but if people are using override_forms they’re unlikely to be using contained content anyway so I expect fallout will be minor.

I haven’t played rock-paper-scissors with all other tags, so I’m not sure if thing beats form every time. But if it doesn’t, it probably should for the reason stated above.

Does that make sense? Or is there something I’m missing?

Last edited by Bloke (2020-09-17 12:45:37)

etc · 2020-09-17 13:01:22

Hmm, using thing as fallback looks more flexible for me. Consider

<txp:article form="potentially_missing">
    <!-- fallback -->
    <txp:title />
</txp:article>

We test override_form (if set), switch to form as fallback, then to thing if form is missing. The order thing > override_form > form would unconditionally use thing, even for articles with override_form set.

Bloke · 2020-09-17 13:46:51

etc wrote #325932:

Hmm, using thing as fallback looks more flexible for me.

True. That is a compelling argument.

Using that logic, it’s almost a good argument to do that form > thing ordering for all tags. But, I dunno. Backwards-compatibility versus consistency. Tricky.

Open to suggestions on whether we make an exception here or do it for all tags.

etc · 2020-09-17 14:50:18

Can’t see why someone would use form jointly with thing if the form is ignored anyway. Moreover, unlike form, listform takes precedence over thing. But I can miss something, more eyes welcome.

Bloke · 2020-09-17 15:07:52

etc wrote #325936:

Can’t see why someone would use form jointly with thing if the form is ignored anyway.

I concur. Having thought about it more, I’m tempted to swap it around for all tags based on your notion above. Then people can supply a default fallback container if the nominated form is unavailable for whatever reason (with the usual caveat that other attributes may be ignored too, in a context-dependent way). But they can also purposefully omit the form and use the container as normal. Can’t see a downside to that.

As long as we ensure to throw a warning if the nominated form (or override_form) is missing, we can then go on to render the container if present, or nothing if not. That does mean that if you specify a missing override_form AND the form is also missing that you get two warnings spat back in testing/debugging modes. But that’s good, as it tells you the chain of what has happened, which is a helpful diagnostic aid.

I think that’s probably better. Thanks for the u-turn :)

Textpattern CMS

Textpattern CMS support forum

#1 2020-09-17 08:13:19