WP Arabic Search 0.9.3
First release verified against a real archive rather than a seeded one: about a
quarter of a million Arabic articles and half a million attachments.
Fixed
- status could report a healthy index while posts were unsearchable. It inferred
everything from rows < posts, which is not the same question as 'is any post
unindexed'. Orphaned rows inflate the row count, so an index missing fifteen
posts while carrying fifteen orphans had totals that matched exactly and
reported itself current. It now counts missing, stale and orphans separately. - The stopword list fell back to nothing when it could not be read. Reading the
server list needs the PROCESS privilege, which many managed hosts do not grant,
so the fix would have been present and doing nothing. It now falls back to
InnoDB's documented default, and says when it has.
Added
- FULLTEXT stopwords are dropped like unusably short tokens, falling back to core
if a search is left with none. Same failure as the two letter Arabic word fixed
in 0.9.1. - wp arabic-search explain, which answers 'why did this not match?': the folded
form, every token with whether it was used and why not, the fallback state, the
exact MATCH clause, and the live hit count. - wpas_indexed_post_types, to narrow what gets indexed.
- reindex flags: --batch, --after and --prune.
Changed
- reindex walks by primary key in batches instead of loading every post ID into
one array. Peak memory on 50,000 posts fell from 253 MB to 82 MB and stays flat
as the archive grows. --after resumes an interrupted run.
Measured on a real archive of about 250,000 Arabic articles
- A search for a name written with diacritics returned 1 result through
WordPress and 28,238 through this plugin, in 0.55s against 4.8s. - Searches the index cannot answer, such as a two letter word, fall back to core
and return identically in identical time. - The index came to about 1.1 GB, roughly 3 KB per article and 150 bytes per
attachment, of which the FULLTEXT index itself was 17 MB.