New Experiment: Semantic search in wp admin

[jeffpaul]

What problem does this address?

The built-in admin search matches exact words, so if you remember writing "that post about pricing changes" but the post was titled "Updates to our plans" then searching for "pricing" in the posts list finds nothing. On sites with hundreds of posts, users can end up scrolling through pages of results or guessing at old titles which as a small friction that can compound daily for anyone actively managing content.

The in-progress native vector search experiment in #683 solves this for site visitors on the frontend search page, but the people managing the site face the same problem in wp-admin and aren't covered by it.

NOTE: This is blocked until the underpinning embeddings work is available, specifically the PHP AI Client's embedding generation API (WordPress/php-ai-client#244) and the native vector search experiment that builds the content index on top of it (#683). This issue is intended as a follow-on to that foundation, not a parallel implementation.

What is your proposed solution?

Extend semantic search to the admin side, reusing the same content index that #683 builds:

• Posts list search: searching from the post/page list tables returns results based on what content means, not just exact word matches, falling back gracefully to default search when no AI provider is configured (matching our existing no-provider degradation pattern)
• Command palette: the editor's command palette (Cmd/Ctrl+K) gains a "search content semantically" path, so authors can jump to the post they're thinking of without leaving the editor

Ideally the retrieval piece is exposed as an ability so other features (and potentially third-party plugins following our lead) can reuse it.

Why is this important to you?

Editors, admins, and multi-author teams hit this constantly and it's arguably a more frequent touchpoint than frontend search, since content managers search their own back catalog far more often than any single visitor does. It also extends the value of the vector-search investment to a second audience at relatively low incremental cost, since indexing, storage, and embedding generation are already handled by #683.

I have searched existing issues and this is not a duplicate.

• Yes

[priyanshuhaldar007]

I've been following this issue, along with the two blockers (#php-ai-client#244 and #683), and I'd love to contribute. I'm particularly interested in working on the posts list search and/or the command palette integration.

I'm adding a quick summary for anyone catching up:

php-ai-client#244 ("Add embedding generation APIs") introduces provider-agnostic embedding support to the PHP AI Client. It adds an Embedding value object, an EmbeddingResult DTO, new withInputs(), generateEmbedding(), and generateEmbeddings() methods, along with dedicated before/after embedding lifecycle events. These events are intentionally separate from the existing generative-result events to avoid breaking changes.

The PR is still under active review. Recent discussion has leaned toward introducing a dedicated EmbeddingBuilder instead of reusing PromptBuilder, with both sharing a common ModelResolver. That direction makes sense, since embeddings don't naturally fit the conversation/message model used for generative prompts. The PR hasn't been merged yet and is currently targeted for the 1.4.0 milestone.

#683 ("Add native vector search") is still in draft. It introduces an opt-in RAG search experiment with two storage backends: native MariaDB VECTOR(1536) support with cosine vector indexing for MariaDB 11.8+ installations, and a postmeta-based in-memory fallback for environments without native vector support.

The PR also includes indexing lifecycle hooks, hourly indexing of modified posts via cron, and wp ai rag ... WP-CLI commands. At the moment, it calls the OpenAI embeddings API directly as a temporary solution, with a clear TODO to switch over to the PHP AI Client once #244 is merged. Because of that dependency, it makes sense for this work to wait until the embedding APIs are available. Based on the author's testing notes, the user-facing features, including search page integration and related posts, are already working.

---

In the meantime, I'm putting together a mock implementation of the wp-admin experience described in this issue, specifically the posts list search and the "Search content semantically" command palette entry. I'm building it against stubbed data so the UI work can move forward independently of the backend.

To make the transition straightforward, the mock data is isolated behind a single interface, so it should be a simple drop-in replacement once the real index from #683 and the embedding APIs from #244 are available.

Happy to share progress or discuss the interface early if that would be helpful.