fix(search): summarise a custom page from its meta description

[e107help]

Why

The release/v2.3.x twin of the master change for #6421.

The custom pages search addon summarises a result from the page's own meta description when there is one, falling back to the body:

$res['summary'] 	= (!empty($row['page_metadscr'])) ? $row['page_metadscr'] : $row['page_text'];

e107_plugins/page/e_search.php#L114

page_metadscr is a real column on the page table (e107_core/sql/core_sql.php#L391), but the addon's own config() never asks for it (e107_plugins/page/e_search.php#L68). A compile($row) is handed exactly the columns return_fields names, so that condition is false on every row and every custom pages result is summarised from raw page_text. empty() swallows the missing key, so nothing is logged and nothing looks broken.

Per #6421, the decision was to select the column rather than delete the read, on both branches.

What Changed

One array element. p.page_metadscr joins return_fields beside p.page_text, and compile() is untouched.

A cherry-pick from the master branch was not possible: e107_tests/tests/unit/e_searchTest.php is a different, shorter file here, carrying three fixture rows rather than eight. The production line is identical to the master one; the test work was written for this file's shape.

How It Was Tested

Two new cases in e107_tests/tests/unit/e_searchTest.php, each compiling a fixture row restricted to the columns the addon's own config() selects, so the test exercises the query and the read together rather than handing compile() a column the query would never have delivered:

• a page with a meta description is summarised from it, which fails with A page body before the change;
• a page that left the field empty is still summarised from its body, which covers the other half of the ternary.

The existing testEverySearchAddonFixtureUsesOnlyReturnedColumns() now covers this column too, because the page fixture row carries it. Two private helpers carry the restriction: searchAddonColumns(), which is the column-name loop that case already had, and compileQueriedRow(), which filters a fixture row down to those columns before compiling it.

The whole unit suite under PHP 5.6: 1540 tests, 19333 assertions, 5 skipped, green. The same suite on PHP 8.5: 1540 tests, 19335 assertions, 4 skipped, green. A clean archive of the whole tree parses under PHP 5.6.

Backwards Compatibility

No rendered HTML changes, so legacy themes are unaffected.

What does change is the text inside an existing search result, on any site whose authors filled the meta description in. page_metadscr is not one of the addon's search_fields (e107_plugins/page/e_search.php#L69), so a page matched on its body will now show a summary with no keyword in it, cropped from the head. Pages with the field empty are unaffected.

The value is a plain string on the way in ('data'=>'str', capped at 155 characters by the admin form, e107_admin/cpage.php#L458) and goes out through the same crop and highlight path as page_text (e107_handlers/search_class.php#L374), so nothing new reaches the results page unescaped.

Selecting one more column from the table the query already reads adds no join and no extra query.

Merge order

This branch is based on #6419, not on release/v2.3.x, because #6419 edits both files this touches. It is eighth in the order for the whole stable search queue, which is kept in one place: #6462 (comment)

A stacked pull request does not retarget itself. GitHub only moves the base up when the base branch is deleted after its own merge, so either delete #6419's branch straight after merging it, or point this one at release/v2.3.x by hand first.

The master pull request for #6421 merges before this one, and the pair goes in back to back.

What this deliberately leaves alone

The same two things the master pull request leaves alone, for the same reasons: the !empty() guard on the read, which lets a whitespace-only meta description render as a blank summary, and the weighted search_fields this addon never selects, filed as #6439.

AI Model

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

Checklist

• The change is covered by a test that fails without it
• The unit suite passes under PHP 5.6
• No rendered HTML changes
• British spelling in prose and commit messages
• Every citation pinned to a commit

Refs #6421

[e107help]

Rebased as well, @Deltik, to follow #6419. Head is now 9385f6805dec90158e119b288f2e9c9229ee5007, up from 5bc75b5a9777bd424c77aa41e243208740096f35. The base branch is unchanged, still e107help/6326-v2.3.x, so there was nothing to retarget here.

No conflict on this one. The single commit replayed with identical content and only its hunk offsets moved, because the block it edits in e107_tests/tests/unit/e_searchTest.php moved to the end of the class when #6419 was replayed. p.page_metadscr joins return_fields in the same place it always did.

Checks, on 9385f6805d. The unit suite is green on both legs, 1577 tests on PHP 8.2 and 1577 under real PHP 5.6, and the whole tree parses under 5.6. Reverting e107_plugins/page/e_search.php to the commit below fails two of e_searchTest's forty-two cases; restoring it turns them green.

Eighth in the merge order for the stable search queue: #6462 (comment). It waits on its master half #6440, which sits on #6418 and #6325 in turn.