v0.9.3

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.

v0.9.2

WP Arabic Search 0.9.2

Two more test rounds since 0.9.1. The index now keeps one searchable column
instead of two, which closed two ways this plugin answered worse than the search
it replaces.

Fixed

• post_excerpt was never indexed, for any post type. Core searches title, excerpt
  and content, so a post whose manual excerpt carried a word found nowhere else
  was returned by plain WordPress and missed here.
• Attachments were indexed by title and description only. Captions and filenames
  are indexed now too. Core matches filenames through a filter that rewrites its
  own LIKE clause, and this plugin's rewrite left that clause absent, so filename
  search had stopped silently.
• reindex reported success having written nothing. Its count came from the number
  of posts selected, never the number written, so every write could fail and the
  command still announced the full total. It now counts rows after the run, and
  recovers on its own from a table that has been dropped.
• status reported a missing table as a raw SQL error rather than a clear message.

Added

• Alt text is searchable. WordPress does not search it at all.
• wpas_searchable_parts( array $parts, WP_Post $post ) makes any meta field,
  taxonomy or post type searchable with no schema change, because it all lands in
  the same indexed column.

Changed

• Schema 3: one matched column, search_text, with normalized_title kept only so
  the ranking boost still discriminates. A schema change now drops and rebuilds
  rather than migrating in place, so the index is briefly empty and the plugin
  falls back to core, instead of a half-migrated table answering every search
  with nothing.

Upgrading

• Run 'wp arabic-search reindex' after updating. The table is rebuilt empty by
  design; until you do, search falls back to core and status exits non-zero.

Measured on 50,000 posts

• Index size and reindex time unchanged (67 MB, 15 s). Query times flat or
  slightly better.

v0.9.1

WP Arabic Search 0.9.1

Four independent test rounds on a 50,000-post rig since 0.9.0. Every fix below
was found by testing, not by reading the code.

Fixed

• Two-letter Arabic words returned nothing at all. The token guard counted bytes
  rather than characters, so short Arabic tokens became required terms InnoDB had
  never indexed. Short tokens are now dropped, and a search left with none falls
  back to core's LIKE and matches it exactly.
• That fallback was then silently intersected with the index, so a post missing
  its index row vanished from a search core would have answered. All three query
  filters now gate on one shared decision instead of each deciding for itself.
• status could not see a stale index, only a missing one. It now compares
  updated_at against post_modified_gmt, reports a stale count and exits non-zero.
• Scheduled posts reported stale for ever, and a post published ahead of schedule
  reported stale once its original time passed. Both fixed.

Changed

• The search walks the index once instead of twice: a single INNER JOIN carrying
  both the match and the ranking, replacing an IN ( SELECT ... MATCH ... )
  subquery plus a separate join. Roughly 16% faster on heavy queries, with no
  regression in the query plan.

Measured on 50,000 posts

• A selective search goes from about 210 ms to 5 ms.
• The index stays ahead until roughly 70% of the archive matches. An earlier
  claim that it lost at high match counts was a term-position artefact, and is
  withdrawn.

v0.9.0

WP Arabic Search 0.9.0