Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: About override form
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.
Offline
Re: About override form
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.
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline
#15 2020-09-17 18:23:37
- Myusername
- Member
- Registered: 2019-12-12
- Posts: 162
Re: About override form
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?
Offline
Re: About override form
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.
Offline
Re: About override form
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?
Offline
Re: About override form
Offline
Re: About override form
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)
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
Offline
Re: About override form
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.
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: About override form
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.
Offline
Re: About override form
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.
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