Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#11 2020-09-17 14:50:18

etc
Developer
Registered: 2010-11-11
Posts: 3,940
Website

Re: About override form

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.

Offline

#12 2020-09-17 15:07:52

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 9,789
Website

Re: About override form

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 :)


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

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

etc
Developer
Registered: 2010-11-11
Posts: 3,940
Website

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

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

colak
Admin
From: Cyprus
Registered: 2004-11-20
Posts: 8,297
Website

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.org | hblack.net | LABS | State Machines | NeMe @ github | Covid-19; a resource
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: 73

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

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

etc
Developer
Registered: 2010-11-11
Posts: 3,940
Website

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

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

etc
Developer
Registered: 2010-11-11
Posts: 3,940
Website

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

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

etc
Developer
Registered: 2010-11-11
Posts: 3,940
Website

Re: About override form

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.

Offline

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

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 9,789
Website

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

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

etc
Developer
Registered: 2010-11-11
Posts: 3,940
Website

Re: About override form

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…

Offline

Board footer

Powered by FluxBB