Resolve Form handling in themes

[Bloke]

Using <txp:output_form> in an error_* page/form doesn't render the form because it doesn't know which theme is in use. Under error conditions (e.g. wrong URL) there is no concept of a 'section' - the mechanism by which the theme pages and styles are determined.

Under normal conditions, the fetch_form() function tries to use the current URL theme (if it's known) but has no further logic than that. It will fail unceremoniously if it can't resolve the theme.

Possible revised workflow:

1. Look up the 'power user logged in' theme first and use that if it's in use, as an override to...
2. ... using the theme as determined by the URL section ($pretext) as it does now.
3. Failing that, if the form name is unique (i.e. only in use by one theme, not default or some name that features in more than one theme) then use that. Safe enough to do so.
4. Add a theme attribute to the tag, which overrides all the above and permits forms from other themes to be used at any time.

See here for background.

Does all of that sound reasonable? Any pitfalls? Better ideas?

[petecooper]

@Bloke - now that themes branch has landed, what's the status of this, please and thank you?

[Bloke]

Still todo. Will figure it out asap.

[petecooper]

Thanks @Bloke – merely asking, not cajoling.

[Bloke]

This may have (partially) been resolved with the improvements that @bloatware made to the txp_die routine. Is there anything more we need to consider here? Do we need to go as far as implementing point (4) in the OP or can we just get away with tweaking fetch_form() to take the theme into account? Is there a neat and backwards-compatible way of doing this? Introducing a theme attribute seems to have a knock-on effect right to the heart of the form loading mechanism.

[bloatware]

Not sure whether it's prudent to introduce a theme attribute now. Themes are linked with sections and 4.8 Custom fields will likely be too. Hence a form from Theme 1 might be completely irrelevant in Theme 2.

I'd say use the theme of the default section if nothing better is found in this case.

[Bloke]

I'm fine with that. Won't get a chance to look at it today, so if you're at a loose end... :-)

[bloatware]

I don't understand why this condition

    if (!$is_404) {
        $out['s'] = empty($out['s']) ? 'default' : $out['s'];
    }

but keep it, in doubt. Now the default section's theme is used on error pages, save for logged in users.

[Bloke]

Thanks for the patch.

Not entirely sure what that line you mentioned is for. I think there might be cases such as displaying a context other than "article" (e.g. an image, link, author, category, etc list) where there's no explicit section defined as the destination. For example, if a <txp:*_list> tag is used without 'thissection' or section attributes.

Under those conditions, it may reach that point and have no section defined so that test just makes sure that if we're not in a 404 situation, the default section is used as fallback.

Best guess.

[philwareham]

Bump! Is this issue done with now? :)