refactor(search): delete the form block nothing parses

[e107help]

Why

$SEARCH_TEMPLATE['form']['type'] ships in both core search packs, live in the legacy one and wrapped in a comment in the other, and nothing has rendered either since February 2016, when 3279283b6c commented out the parseTemplate() call that would have drawn it. The assignment that would have filled its {SEARCH_TYPE_SEL} placeholder is commented out beside it, which leaves sc_search_type_sel() unreachable. Its other placeholder, {SEARCH_TYPE_DISPLAY}, was still computed on every request into a block nothing rendered.

That is point 5 of #6301, and half-present is the worst of the three states it could be in. A theme author reading either pack finds a block to style and never sees it, and the next person to touch the file has to work out which of the two commented-out lines was meant.

Deltik's answer was to delete it rather than revive it. The form already carries an advanced toggle without it: the "Toggle Advanced Mode" dropdown item at search.php#L169 points at the same search-advanced block, so bringing the old block back would put a second control for one thing in one form.

What Changed

Six sites the issue named:

• the block in the legacy pack, legacy/search_template.php#L36-L42, the only reader of LAN_SEARCH_75
• the same block commented out in the core pack, search_template.php#L40-L48
• search_front::sc_search_type_sel(), search.php#L217-L225, the only reader of LAN_SEARCH_29 and LAN_SEARCH_30, carrying two commented-out lines of its own predecessor
• the commented-out {SEARCH_TYPE_SEL} assignment, search.php#L1133-L1134
• the live {SEARCH_TYPE_DISPLAY} assignment, search.php#L1145-L1152
• the commented-out parse, search.php#L1207

And one it did not, found by tracing: search_front::$legacyForm maps SEARCH_TYPE onto the block at search.php#L67-L76, so a v1 theme assigning $SEARCH_TYPE had it synthesised into $form['type'], which nothing renders. That entry goes too. $legacyForm doubles as the v1-shape detector in formTemplate(), which now matches on seven keys rather than eight: the only pack read differently is one that assigns $SEARCH_TYPE and none of the other seven, which is not a search form.

Folded in: the commented-out {SEARCH_ADVANCED_BLOCK} parse at search.php#L1208-L1212 sits in the four lines below the one deleted above, commented out by the same 2016 commit, and sc_search_advanced() at search.php#L352-L361 has drawn that same search-advanced wrapper live ever since. It is the rest of one stretch of debris, and the argument for deleting the block condemns it in the same words. The commented-out $_GET sweep above it and the preg_replace() predecessors below it are debris of other lines, and they stay for a general sweep.

Also folded in: $js_adv at search.php#L1136-L1143 and search.php#L1154-L1156 is built and read nowhere, and has been since b19f9ffbc3 in January 2021. It sits between two of the deletions above and is all that would have been left of that stretch, so it goes with them.

LAN_SEARCH_29, LAN_SEARCH_30 and LAN_SEARCH_75 stay in the language files. A third-party template or plugin may still read them.

How It Was Tested

e107_tests/tests/unit/searchFormTemplateTest.php is new. It reads every shipped search pack with the tokenizer and asserts that each form block the pack declares is one search.php reads, with a second test holding the list of readable blocks down to what the file actually subscripts. It reads a pack's comments as source too, so a commented-out declaration counts as a declaration, which is what it is to the theme author reading the pack: wrapping the block in /* */ rather than deleting it reds the test as surely as leaving it live does. Reads of the template array in search.php are counted live only, because a commented-out read must not legitimise a block.

That is the guard against the block coming back, which a deletion on its own cannot express. Proven red by reverting the three source files and running it again.

The whole unit suite runs green on this branch: 2748 tests, 26085 assertions, 6 skipped. The downgrade tooling is at its fixed point on every changed file, so nothing here would be rewritten for the older cell CI runs.

Nothing rendered changes, which is why the test asserts on the packs rather than on markup. I traced every reader of each deleted symbol and a repo-wide search finds none left outside the language files; no bundled theme or plugin names any of them. The two tests that render /search.php and assert on its markup, searchAdvancedLabelsTest and searchAdvancedMultiTypeTest, stay green.

Backwards Compatibility

No rendered HTML changes for any theme, Bootstrap or legacy.

search_front::sc_search_type_sel() is public and goes away, so a third-party search template naming {SEARCH_TYPE_SEL} stops resolving it. On master that is the point of the change: the shortcode has had no reachable caller since 2016, and a template naming it has been rendering an empty string for a decade either way.

One narrow case, which I could not find an instance of: a third-party pack that moved {SEARCH_TYPE_DISPLAY} out of the type block and into message or end, the two blocks parsed with simpleParse() against $SEARCH_VARS, used to receive style='display: none' on a page without an advanced type and now receives an empty string, so an element it hid by default becomes visible. The placeholder only ever made sense on the row that never rendered, so putting it in a rendered block took noticing that first.

No twin on release/v2.3.x. The dead block is there too, but this is dead-code removal rather than a correctness fix, and dropping a shortcode a third-party template could name is a break the stable track should not take mid-series. Same shape as the front-end FAQ removal, which landed on master and left the stable branch's remains alone.

Stacked

This branches off #6450, which branches off #6379, because all three touch search.php. Merge order: #6379, then #6450, then this one.

AI Model

Claude Opus 5 (claude-opus-5) as e107help

Checklist

• One issue per PR: the diff is scoped to this change only
• Commit messages explain why, not just what
• New or changed behavior has test coverage (or explain why not)
• No unrelated reformatting, renames, or import reordering

Refs #6301

[e107help]

The base here now names what this branch actually sits on. It was opened against master while carrying five commits from #6379 and #6450 underneath its own one, so the diff read as the whole line of work; the base is now e107help/6321 (#6450) and the diff is the single commit this pull request is about.

The head has moved from 15417de7b6 to 045ff09d81, and the change is untouched: same patch id against the new base as against the old one.

This is the top of the chain, seventh and last. The order for the whole block, and what a stacked base does at merge time, is in #6325.