Search page: findings from building a Bootstrap 5 front-end theme

[Jimmi08]

While building a Bootstrap 5 front-end theme I went through the search page end to
end — the form template, the shortcodes, the result rendering and the plugin
e_search.php handlers. Along the way I collected a number of issues. Some are
one-line fixes, some are design questions.

I am posting them here as a single write-up rather than opening separate issues,
so you can decide which are worth tracking and how to split them. Please treat
this as raw material: open issues for anything you find worth pursuing, in
whatever grouping suits you, and ignore the rest. No need to check back with me.

All file and line references are against master at the time of writing.

A note on authorship: this write-up was drafted by Claude (Anthropic) from a reading of the current master source. I deliberately gave it no context about template work that is already done or planned, so it reflects the code as it stands and nothing more. Please read it with that in mind — some of these may already be known or in progress.

1. There is no Bootstrap 5 core template for search

e107_core/templates/ has bootstrap4/ and bootstrap5/ subfolders, but neither
contains a search_template.php. coreTemplatePath() therefore falls through to
e107_core/templates/search_template.php for every theme.

That file is commented // Bootstrap, but it is written for Bootstrap 3:

• form-horizontal, form-group, control-label — all removed in Bootstrap 5
• col-sm-3 / col-sm-8 without a .row parent, so the columns never form a row
  and every label ends up on its own line
• input-group-btn and pull-right — Bootstrap 3 only
• <span class="caret"> — Bootstrap 5 draws the caret with .dropdown-toggle::after

The result is that any Bootstrap 5 theme gets a visibly broken search form until
it ships its own override. That is easy enough to do, but it means every BS5 theme
has to solve the same problem independently.

Adding e107_core/templates/bootstrap5/search_template.php would fix this for all
of them at once.

2. Missing spaces in the result detail line

e107_plugins/news/e_search.php:79

$res['detail'] = LAN_SEARCH_3.$tp->toDate($row['news_datestamp'], "long");

LAN_SEARCH_3 is "Posted on" with no trailing space
(e107_languages/English/lan_search.php:25), so the rendered output reads
Posted on29 Jan 2023 : 12:35.

The same pattern is in e107_plugins/page/e_search.php:119.

e107_plugins/forum/e_search.php:101 is worse — three joins, no separators:

$res['detail'] = LAN_SEARCH_7.$userlink.LAN_SEARCH_8.$datestamp;

For contrast, e107_plugins/download/e_search.php:109 builds the same kind of
string correctly, with explicit spaces.

The fix belongs in the concatenation rather than in the language files — trailing
spaces inside translatable strings tend to get lost by translators and by
translation tooling.

3. Path constants and bbcode content leak into result summaries

Searching for a term that appears in a news item containing an image produces
summaries like:

...s.  Those are examples: {e_MEDIA_IMAGE}2023-01/e107_dashboard_2_.png
{e_MEDIA_IMAGE}2023-01/e107_dashboard_3_.png And admin panel for admin wit...

The cause is in e107_handlers/search_class.php:363-371:

$t_search  = $tp->search;
$t_replace = $tp->replace;
$s_search  = array('<br />', '[', ']');
$s_replace = array(' ', '<', '>');
$search    = array_merge($t_search, $s_search);
$replace   = array_merge($t_replace, $s_replace);

$this->text = strip_tags(str_replace($search, $replace, $this->text));

Two things go wrong here.

First, rewriting [ and ] into < and > turns [img]path[/img] into
<img>path</img>. strip_tags() then removes the tags but keeps everything
between them, so the image path survives as visible text. The same applies to any
bbcode whose payload is an attribute-like value rather than prose.

Second, $tp->search and $tp->replace are not what the variable names suggest in
this context. In e107_handlers/e_parse_class.php:44-46 they are HTML entity
cleanup arrays:

public $search  = array(''', ''', ''', '"', 'onerror', '>', '"', ' & ');
public $replace = array("'", "'", "'", '"', 'one<i></i>rror', '>', '"', ' &amp; ');

They do not expand {e_MEDIA_IMAGE} or any other path constant, so those come
through untouched.

Running the summary through $tp->toText() — or at minimum replaceConstants()
plus proper bbcode stripping — would produce readable excerpts.

4. <label for="t"> in the advanced form points at a different control

e107_core/templates/search_template.php, the form.advanced key:

<label for="t" class="col-sm-3 control-label">{SEARCH_ADV_A}</label>

{SEARCH_ADV_B} renders the matching control at search.php:432:

$vars['SEARCH_ADV_B'] = "<select name='".$adv_key."' class='tbox form-control'>";

There is no id, so the label cannot be associated with it. Worse, id="t" does
exist on the page — it is the category selector built in selectElement() — so
every advanced label is programmatically bound to an unrelated control. A screen
reader user tabbing into an advanced dropdown hears the wrong label.

form.enhanced gets this right: for="{ENHANCED_DISPLAY_FIELDNAME}" matches the
id emitted by sc_search_enhanced(), so the fix is to follow the same approach
in {SEARCH_ADV_B}.

5. Zero results is rendered as an error

search.php:829 sets the fallback:

varset($this->search_info[$key]['no_results'], "<div class='alert alert-danger'>".LAN_198."</div>")

alert-danger means something went wrong. A search that legitimately returns no
matches is not an error, and rendering it in red reads as one. alert-info, a muted
note, or an empty state would fit better.

Plugins can override this through no_results in their e_search.php, but the
core default is what most installs will actually see.

6. <select> elements are hardcoded to form-control

Bootstrap 4 introduced form-select (custom-select in BS4, form-select in BS5)
for <select> elements. Without it the dropdown loses its chevron and its padding
is wrong.

Two places hardcode form-control on a <select>:

• search.php:269 — sc_search_dropdown() via selectElement()
• search.php:432 — the advanced dropdown

Themes can only patch this with CSS that duplicates the framework's own rules,
which is fragile.

e107_core/shortcodes/batch/search_shortcodes.php already shows the pattern that
would solve this — sc_search_input() and sc_search_button() both accept a
class parm and only fall back to a default when none is given. Extending the same
convention to these shortcodes would let themes pass the right class.

7. Result markup cannot be templated

The search form is fully templatable, but the results are not. Each row is built
as a fixed string in search_class.php:416 and :428:

$this->text = $this->bullet."<h4><a class='title visit' href='".$res['link']."'>"
            . $pre_title_output.$this->text."</a></h4>{DETAILS}<div>".$res['pre_summary'];
...
$output_array['text'][] = "<li>".str_replace('{DETAILS}', "<span class='text-muted'>"
            . $res['detail'].$display_rel."</span>", $output)
            . $tp->toText($res['post_summary'])."</div></li>\n\n";

with the list wrapper in search.php:845:

$text .= '<ul id="search-results-'.$idkey.'" class="list-unstyled search-block">';

A theme can restyle this with CSS, but it cannot change the element structure —
no way to use a definition list, a card per result, a different heading level, or
to surface the URL the way most search engines do.

A $SEARCH_TEMPLATE['result'] key with placeholders along the lines of
{SEARCH_TITLE}, {SEARCH_LINK}, {SEARCH_DETAIL} and {SEARCH_SUMMARY}, plus
result_start / result_end for the wrapper, would bring results in line with how
the rest of e107 handles output. Existing themes could keep the current markup as
the default so nothing breaks.

This is the largest item here and probably worth discussing before anyone writes
code.

8. Smaller things

Dead code in the bullet setup. search_class.php:46-57 picks a bullet from
GLYPH, BULLET or bullet2.gif across three branches, and then line 57
unconditionally discards all of it:

$this->bullet = ''; // Use CSS instead.

The three branches above it have no effect.

A template key that is never parsed. formTemplate() maps the legacy
SEARCH_TYPE key to type (search.php:71), and the core template defines
form.type — but the line that would parse it is commented out at search.php:1176.
Both the mapping and the template key are dead.

Double space in the results caption. search.php:894 builds the caption by
concatenation:

LAN_SEARCH_11." ".$res_display." ".LAN_SEARCH_13." ".$qtype

$res_display is set to an empty string when there are no results
(search.php:891), leaving Results in News with two spaces. HTML collapses it,
so it is only visible in the source, but it also means the caption reads oddly —
"Results in News" when there are none.

---

Thanks for reading through all of that. For what it is worth, item 1 has the widest
reach since it affects every Bootstrap 5 theme, and items 2 and 3 are the ones an
end user actually sees — but you are far better placed than I am to judge where this
sits against everything else on the list.

[Jimmi08]

Result with Aragorn

Template attached; no changes in core code

<img width="823" height="900" alt="image" src="https://github.com/user-attachments/assets/ba7cd2c0-15d8-468e-9ec2-d00e3d6d90dd" />

/* e107 emits size= on inputs; let the grid decide the width instead. */
.form-control[size] {
	width: 100%;
}

/* Inside an input-group, Bootstrap's flex sizing must win — otherwise the
   buttons wrap onto a second line. Specificity must beat .form-control[size]. */
.input-group>.form-control[size] {
	width: 1%;
	min-width: 0;
}

/* ---------------------------------------------------------------------------
   Search
   --------------------------------------------------------------------------- */

/* Search results
 * ---------------------------------------------------------------------------
 * search_class.php emits a fixed <li> structure that no template can change,
 * so styling is the only lever the theme has. Child selectors are deliberate:
 * they keep these rules off anything the result summary itself may contain.
 */

.search-block>li+li {
	margin-top: 1rem;
	padding-top: 1rem;
	border-top: var(--tblr-border-width) solid var(--tblr-border-color);
}

/* Tabler sizes h4 at 0.875rem for dashboard use; a search result title needs
 * to read as the primary element of its row. */
.search-block>li>h4 {
	margin-bottom: 0.25rem;
	font-size: 1rem;
	line-height: 1.4;
}

.search-block>li>h4>a.title {
	color: var(--tblr-primary);
	text-decoration: none;
}

.search-block>li>h4>a.title:hover,
.search-block>li>h4>a.title:focus-visible {
	text-decoration: underline;
}

/* Date and category. Upstream emits an inline <span>, so it has to be promoted
 * to its own line. */
.search-block>li>span.text-muted {
	display: block;
	margin-bottom: 0.25rem;
	font-size: 12px !important;
}

search_template.php

[Alex-e107nl]

ti ti-search is not a standard e107 icon? fa fa-magnifying-glass is..

[Jimmi08]

it is a tabler theme so it uses its icons. It was just example. Core template should use its own markup.

[e107help[bot]]

You flagged that the write-up was drafted without context on what is already done or planned. It holds up anyway. I traced all eight items against master at 7ca831e70, and four issues are now open:

Your item	Issue
2, plus the caption double space in 8	#6298
3, plus the dead bullet block in 8	#6299
4	#6300
1, 5, 6, plus the dead form.type in 8	#6301

Item 7 is not on the tracker, on purpose. More on that below.

What this means for Aragorn

The part of item 1 worth knowing before you refine that template: four pieces of the search form are out of any template's reach. They are printed from PHP in sc_search_main(), not from search_template.php:

• input-group-btn and a .btn-group nested inside the .input-group, at search.php#L156-L158
• <span class="caret"> at #L165-L168, gated on BOOTSTRAP !== 4, so Bootstrap 5 is the case that gets it
• pull-right at #L170, sitting on the same element as the Bootstrap 5 dropdown-menu-end
• the magnifying glass at #L159, where $tp->toGlyph('fa-search', false) fixes the glyph to FontAwesome

Which is to say your .input-group>.form-control[size] rule was not a workaround for a template you had not written yet. It was the only lever there is, and it stays the only lever until those four move. The Bootstrap 3 leftovers that are in the template, form-horizontal, form-group, control-label and col-sm-* with no .row parent, you can already override by shipping your own file. All four of the above are point 2 of #6301.

One smaller thing, and this is where the missing context shows: the bullet branches in item 8 are already commented out, at search_class.php#L44-L55. Nothing is being computed and thrown away at runtime; it is just dead code sitting there. #6299 asks for the block to go.

Item 7, templating the results

No issue for this one, because it is a decision rather than a defect, and @Deltik already has the decision in front of him. @fizi filed #6286 about submitnews.php hardcoding its form markup, and #6292 came out of it without making the call: whether core output a theme can currently only reach with CSS becomes a template key, and if it does, whether the shipped default is today's HTML byte for byte or a cleaner structure.

Your item 7 is the same class of question with a harder middle, and the difference is worth arguing rather than assuming away. A form is emitted once. A result row is built per iteration in search_class.php, where the cropping and the <mark> highlighting both operate on the same string the template would want to own, so {SEARCH_TITLE} and friends raise a question the form case never has to answer. It could land differently from submitnews.php for that reason.

The direction is @Deltik's own, published on #5909, and the forum statistics page went this way in #5888. Whether the search results follow, and when, is his to say.

Short version

@Jimmi08, no action needed from you. Eight items, all real, four issues open, one waiting on @Deltik. The one thing worth carrying away: four bits of the search form, the icon included, come out of PHP, so no template you write will reach them and CSS stays your only option there.

Thanks for the CSS in that follow-up. .search-block>li>span.text-muted needing display: block to get the date onto its own line is item 7 in miniature: the <span> is welded into the row at search_class.php#L428, so a theme cannot ask for a different element.

---

Ahoj Jimako, po slovensky a stručne: prešiel som všetkých osem bodov a overil som ich priamo v kóde na vetve master. Všetky sedia. Založil som štyri issues: #6298, #6299, #6300 a #6301. Bod 7 (šablónovanie výsledkov vyhľadávania) som nezakladal, pretože rovnakú otázku už rieši @Deltik na #6292 a rozhodnutie je na ňom. Ty nemusíš nič robiť. Jedna vec, ktorá sa ti zíde: štyri veci vo formulári vyhľadávania (input-group-btn, caret, pull-right a ikonka lupy) sa vypisujú priamo z PHP, takže sa k nim cez vlastnú šablónu nedostaneš. Preto ti zostáva len CSS.