Bug: txp:article listform attribute overrides form attribute in individual article view on current 4.9.0-dev. about textpattern

[bloatware]

Oops, shame on me. A drawback of some code unification between the individual/list modes it is. Will fix, thanks @jools-r for the hint.

[jools-r]

Thanks for the super prompt reply. One reason why we haven't really noticed it – aside from the fact that few people are using the dev version – is that the four-point-nine theme avoids the issue because it differentiates between article_list and individual_article views and consequently uses separate txp:article tags.

[bloatware]

While we are here, appending q parameter to an individual article URL seems to trigger 'is search' mode of some tags, see e.g. https://release-demo.textpattern.co/index.php?id=1&q=wel. Should it be fixed somehow?

[jools-r]

Hmm, that looks strange, I agree, and makes page logic handling more difficult when if_searchis used for determining page design but returns true on an individual article page.
Is there a use case where a search parameter could be useful on an individual article page? How it's written at present with explicitly excluding sticky pages seems to suggest there might be / have been one.

If not, one could restrict this line to just $is_article_list && $q. Presumably, !issticky is then irrelevant.

If there is a use case in individual articles, maybe if_search needs to be handled more carefully in the design of page logic by placing it within if_article_list or if_individual_article tags to determine how it responds. But that could break some sites' existing page templates.

[phiw13]

While we are here, appending q parameter to an individual article URL seems to trigger 'is search' mode of some tags, see e.g. https://release-demo.textpattern.co/index.php?id=1&q=wel. Should it be fixed somehow?

Is that only in ?messy url mode? On my set up (localhost / TXP-dev) I use section/title and appending &q=delete results in a 404 page (default template, default article from TXP 4.8).

scratch all that domain.tld/section/article-title?q=delete does indeed trigger a search… :-(

[bloatware]

Is there a use case where a search parameter could be useful on an individual article page?

That is the question. Otherwise we could unset $pretext['q'] even earlier, as soon as $is_individual_article is set.

[Bloke]

Is there a use case where a search parameter could be useful on an individual article page?

There may be a case, but I can't think of one. If you're searching, you search the entire database of articles, or those in one (or more?) section(s), or one (or more?) category. If you search for a term and it only returns one article, then great but there's no need to trigger a search from article granularity, imo. CTRL-F on the page, ftw.

[jools-r]

May I bump this? While it's easy to work around, it's crucial for backwards compatibility.

[bloatware]

Done, sorry for the delay. I'd keep this issue open, since we yet have to decide on the search parameter behaviour.

[jools-r]

Thank you! As ever, a little more eloquent than my syntax :-)

That resolves the functional issue outlined at the top, and I feel we should close this issue as it is a fundamental aspect of how Textpattern works. Should I re-open the question about unsetting $pretext['q'] earlier, or is that something that could perhaps be resolved swiftly so as not to add new things to the list.

[Bloke]

I still can't envisage a use case for ?q within an individual article context. So I'm fine with unsetting it earlier if that limits it and doesn't have any unintended consequences now that doArticles() is more closely aligned for article(_custom) and list behaviour.

[bloatware]

Core does not need it, but some plugins (etc_search?) can output search results on individual pages too, à la <txp:article_custom />.

[Bloke]

If it's useful for plugins then I'm happy to keep the behaviour. Doesn't hurt anyone, does it?

[bloatware]

Too error-prone at the moment.