About override form

etc · 2020-09-17 15:36:33

I think the explanation is purely technical: the default value of form is default, so thing must supersede form (since form="" its ugly) to be processed. But it’s easy to fix.

colak · 2020-09-17 18:07:41

etc wrote #325925:

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.

I had an issue with missing override forms when I was merging dbs back in 2018. At the time I felt that an error should have been generated in order to help detect the source of the malfunction. Although having fallback will be handy, it will also help the prolongation of the error which may, in some cases remain undetected.

Myusername · 2020-09-17 18:23:37

Perhaps you have already considered this and I did not realize it. In addition to not having so much knowledge, sometimes English makes things more difficult to understand. But anyway, a suggestion:

When we are going to delete a user in the user panel, it is necessary to assign that user’s articles to another. With articles form it could work the same way. When submitted to exclusion, the user could be asked which form he wants to use in those articles after the exclusion.

In this way, in addition to transparency – since the person will know that all the articles in this form will be changed – it will also give the user the possibility to choose which of the existing forms is best adapted to the content of the form that will be deleted.

Did you discuss this possibility? Is that a bad idea?

etc · 2020-09-17 19:34:19

colak wrote #325939:

I felt that an error should have been generated in order to help detect the source of the malfunction. Although having fallback will be handy, it will also help the prolongation of the error which may, in some cases remain undetected.

It is detected in debug mode, but your point is valid security/privacy wise, imo. You may want to hide some information in ‘form-overridden’ articles, so falling back to form could be risky.

Myusername wrote #325940:

Did you discuss this possibility? Is that a bad idea?

Not at all, thanks for the idea, that should be doable and is certainly helpful. But it does not totally solve the OP problem when, say, you mass-change the section of concerned articles. The new section can use another theme without the necessary ‘overriding’ forms.

etc · 2020-09-18 11:02:42

There are few other related questions to answer. When an article is listed on the homepage, where (override) forms should be fetched from: the theme assigned to default section as currently, or this of article’s own section? If the former, what should happen if default section theme lacks ‘overriding’ forms? And for articles listed via <txp:article_custom /> on another section page?

etc · 2020-10-12 14:34:24

Myusername wrote #325940:

When submitted to exclusion, the user could be asked which form he wants to use in those articles after the exclusion.

Well, it’s done in 4.8.4, but looks a bit overkill. I’d rather simply unset override forms of all concerned articles. Please test and share your ideas.

Bloke · 2020-10-12 14:51:32

Not a massive fan, though I see the usefulness if we can get the UX right – especially if you have a lot of override forms in play. I’m not sure if a simple ‘change override form’ multi-edit option might be more beneficial (though there’s no indication on that panel of what’s assigned so maybe that’s of limited use).

The weird thing with this is that if you’re deleting a bunch of forms, you might not want to reassign them all. So you’re forced to do it in a few stages (assuming you know which forms are assigned where). And if you leave the override dropdown empty, does that mean “clear all matching assigned override forms”, i.e. unset them?

One slight niggle: as it stands, you can delete a form and reassign the one you’re deleting from the Override list, which leaves it ‘set’ in the article. If you then go and recreate the same form name, the override assignment in the article is still there and the form assignment re-establishes itself.

With user deletion, if you try to reassign assets to the same account you’re deleting, you’re told it’s not possible. To do that here for forms, however, requires a new language string.

Last edited by Bloke (2020-10-12 15:17:37)

etc · 2020-10-12 16:37:19

Bloke wrote #326336:

One slight niggle: as it stands …

Yep, I know, there are few details to nail, but this ‘reassign’ feature as it stands looked dead-born anyway, so…

Bloke · 2020-10-12 16:39:52

It’s not a bad idea, per se. We just need to think about use cases and choose the best UX to support it.

I think maybe what is slightly incongruous is that you get the ‘override’ (a.k.a. reassign) whether you’ve assigned the selected assets to articles or not. Nothing we can do about that, since multi-edit options are built before selections are made.

etc · 2020-10-12 16:52:17

There are other ways to render override forms invalid: change the article’s section theme to one with missing forms, etc. We are not users nurse, a ‘form in use’ pill is probably enough here.

Bloke · 2020-10-12 17:04:46

etc wrote #326340:

There are other ways to render override forms invalid: change the article’s section theme to one with missing forms, etc.

Absolutely.

We are not users nurse

Absolutely again. But if we’re putting in a feature that appears as if we’re nursing them, we need to make sure it actually does :)

a ‘form in use’ pill is probably enough here.

Yep, I like that.

Textpattern CMS

Textpattern CMS support forum

#13 2020-09-17 15:36:33

Re: About override form

#14 2020-09-17 18:07:41

Re: About override form

etc wrote #325925:

#15 2020-09-17 18:23:37

Re: About override form

#16 2020-09-17 19:34:19

Re: About override form

colak wrote #325939:

Myusername wrote #325940:

#17 2020-09-18 11:02:42

Re: About override form

#18 2020-10-12 14:34:24

Re: About override form

Myusername wrote #325940:

#19 2020-10-12 14:51:32

Re: About override form

#20 2020-10-12 16:37:19

Re: About override form

Bloke wrote #326336:

#21 2020-10-12 16:39:52

Re: About override form

#22 2020-10-12 16:52:17

Re: About override form

#23 2020-10-12 17:04:46

Re: About override form

etc wrote #326340:

Board footer