FullText Search for WP: A Community Plugin  🔗 **Source:** [FullText Search for WP: A Community Plugin](https://mattcromwell.com/fulltext-search-for-wp-community-plugin/) > [!note]+ Document Notes > tags: [wordpress, search, plugin] > author: Matt Cromwell > source: mattcromwell.com > reference: [https://mattcromwell.com/fulltext-search-for-wp-community-plugin/] > date created: 2026-03-17 10:00 > > # 🏷️ Title: FullText Search for WP: A Community Plugin > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - Include links cited in or relevant to the article. ## 📝 Summary - What happened: The author introduces “FullText Search for WP,” a community-driven WordPress plugin to significantly improve wp-admin search. - Why it matters: Core admin search is notoriously weak; better relevance across content, meta, and taxonomies improves productivity and UX. - Key stakeholders: WordPress site owners, editors, agencies, product builders, and plugin developers. - Risks and tradeoffs: Added database load, complexity of FULLTEXT indexing, and maintenance burden across diverse WordPress setups. - Bottom line: Treat admin search as a shared infrastructure problem and improve it collaboratively rather than via closed products. ## 📖 Main Content - Core idea: wp-admin’s default search is too limited (simple LIKE queries) and often fails real-world needs. FullText Search for WP aims to fix this with MySQL FULLTEXT, querying titles, content, meta, and taxonomy terms, plus better relevance scoring. - Community-first framing: It’s explicitly not a commercial launch but an open project: transparent code, open contribution, and shared ownership of a “good enough” baseline for admin search across the ecosystem. - Technical direction: The plugin adds FULLTEXT indexes to selected tables/columns and rewires the admin search queries to use them, trying to keep performance acceptable while improving results. It likely provides hooks/filters so other plugins can extend which fields are indexed and how results are weighted. - Strategic context: In an ecosystem with many front-end search solutions (Algolia, Elastic, etc.), admin search remains neglected. This plugin treats wp-admin search as infrastructure that should “just work” and be extensible rather than something each product reinvents in isolation. - Constraints & open questions: Compatibility with different hosts, database engines, large sites, and multisite; migration and rollback for indexes; and long-term governance and maintenance by the community. ### 🗒️ Notes - WordPress admin search has long been criticized as weak: it relies on basic SQL LIKE matches on a narrow set of fields, leading to missed or poorly ordered results. - FullText Search for WP is framed as an “attempt to close that gap as a community project,” emphasizing collaboration over commercialization. - The project lives in public on GitHub, inviting contributions, issue reports, and experimentation. - The aim is for wp-admin search to behave like a trustworthy, extensible tool—something developers can hook into and site owners can rely on. - Using FULLTEXT indexing enables ranked relevance, matching across larger text blobs, and better handling of typical editorial queries. - The plugin likely supports searching post content, titles, excerpts, custom fields (post meta), and taxonomy terms, making admin search more aligned with how content is actually modeled in WordPress. - Treating this as infrastructure implies stable APIs, careful performance considerations, and a long-term roadmap beyond one person’s needs. - The author also uses the post as a bridge to an email list focused on WordPress product businesses, signaling ongoing discussion around sustainable, community-driven tooling. ## 📚 References - Full article: FullText Search for WP: A Community Plugin – https://mattcromwell.com/fulltext-search-for-wp-community-plugin/ - Plugin repository & docs: FullText Search for WP – https://github.com/mathetos/fulltext-search-for-wp - WordPress Developer Resources (Search) – https://developer.wordpress.org/reference/hooks/posts_search/ - MySQL FULLTEXT documentation – https://dev.mysql.com/doc/refman/8.0/en/fulltext-search.html ## 🗣️ Paraphrase - Paragraph A: WordPress’s admin search has a reputation for being bad, and that criticism is often justified. Given modern tools, the author argues there’s no excuse not to fix it. - Paragraph B: The author is releasing FullText Search for WP as a community plugin, not as a commercial product, with the goal of making admin search reliable and extendable for everyone. - Paragraph C: The code and documentation are openly available on GitHub so others can inspect, improve, and build on the plugin. - Paragraph D: The author invites readers to subscribe to his newsletter focused on helping people succeed with WordPress product businesses and promises personal engagement. ## 📰 Newsletter WordPress admins have lived with “meh” search for far too long. Matt Cromwell just published a deep dive on FullText Search for WP, a community plugin that rewires wp-admin search to use MySQL FULLTEXT across posts, meta, and taxonomies. No SaaS lock-in, just better defaults we can all build on. Check out the code on GitHub (https://github.com/mathetos/fulltext-search-for-wp) and consider how your own plugins could hook into a shared search layer. ## ✅ Action Items #### DevRel - Highlight FullText Search for WP in developer newsletters and talks as a model for infrastructure-style plugins. - Create short tutorials showing how plugin authors can extend the search index and relevance weights. - Add code samples and quickstarts demonstrating integration with custom post types and meta. - Run a small campaign around “Fix wp-admin search week,” encouraging issue filing and contributions. - Gather developer feedback via GitHub issues and periodic surveys to refine DX. #### OSPO - Document contribution guidelines, review expectations, and governance for the plugin as a community asset. - Ensure license clarity (e.g., GPL compatibility) and scan for third-party dependencies. - Establish a simple security disclosure process and contact. - Track the plugin in internal inventories where WordPress is a strategic platform dependency. - Explore upstream collaboration with hosting partners or agencies who rely heavily on admin search. #### Community - Host contributor onboarding sessions to walk through the codebase and roadmap. - Curate “good first issues” and pairing sessions for new contributors. - Encourage agency and product teams using the plugin to sponsor maintenance time or testing. - Coordinate with sponsors interested in funding performance and scalability work. - Share case studies of large sites benefiting from improved admin search. #### WordPress - Core: Evaluate learnings from this plugin for potential future improvements to the built-in admin search APIs. - Core Performance: Profile the plugin on large datasets; publish metrics and recommended settings. - Core AI: Consider how structured, high-quality admin search can support AI-assisted workflows in wp-admin. - Core Program Team: Track this as an ecosystem initiative and surface it in relevant Make posts. - Mobile: Investigate whether similar search enhancements can be mirrored in mobile apps. - Playground: Provide a playground preset with the plugin preinstalled for experimentation. - Community: Include the plugin in WordCamp talks and meetup topics focused on content workflows. - Training: Build lesson plans on “Making wp-admin search actually useful” featuring this plugin. - Marketing: Position this as an example of community-led UX improvement in the WordPress ecosystem. - Support: Document common issues (indexing, performance, compatibility) for support teams. - Design: Explore admin UI affordances for “advanced search” powered by the plugin. - Documentation: Add DevHub/HelpHub articles on extending and troubleshooting admin search. - Photos / TV / Polyglots / Accessibility / Meta / CLI / Hosting / Tide / Openverse / Themes / Plugins: - Reference the project where relevant (e.g., plugin review guidance on FULLTEXT, hosting best practices for FULLTEXT indexes). #### The WPOCC - Consider microgrants or stipends for ongoing maintenance and performance testing. - Use the project as a pilot for governance clinics around infra-style community plugins. - Fund documentation and training sprints to make adoption safer and easier. ### FAIR - Promote technical independence by documenting how to run robust search locally without external SaaS. - Encourage transparent funding (if any) and clear stewardship to avoid capture. - Treat governance patterns from this project (charters, agreements) as reusable artifacts. ## 🧪 Hypotheses - H1: Sites using FullText Search for WP will see faster content discovery times for editors compared to default search. - H2: Developers are more likely to extend a community-maintained admin search plugin than build custom search logic from scratch. - H3: FULLTEXT-based admin search will remain performant on medium-sized sites without additional infrastructure. - H4: Clear extension points in the plugin will increase ecosystem integrations over time (CPTs, fields, taxonomies). ### 📊 Methodology - Run time-on-task studies where editors locate specific content using default vs. FullText Search for WP. - Analyze GitHub activity (stars, forks, PRs, issues) as a proxy for developer engagement and extension. - Benchmark query performance on representative datasets (small, medium, large) across common hosting environments. - Track adoption and integration patterns via opt-in telemetry or user surveys. ### ❓ Questions - How does the plugin behave on very large sites (100k+ posts) and multisite networks? - What indexing strategies are safest across shared hosting environments? - Should some of this functionality evolve toward WordPress core, or remain as a plugin? - How can plugin and theme authors standardize their extensions to the search index? ### 🔮 Future Research - Explore hybrid approaches combining FULLTEXT with external search engines where needed. - Investigate relevance tuning strategies for different content models (e.g., news vs. documentation). - Study long-term maintenance models for infra-style community plugins in the WordPress ecosystem. - Examine how improved admin search changes editorial workflows and governance. ### 💡 Implications - Practice: Agencies and product teams can standardize on a more powerful admin search baseline. - Policy: Hosts and organizations may need guidelines around enabling FULLTEXT and indexing policies. - Security: Broader search surfaces occasionally expose sensitive content; permissions and scoping must be correct. - Education: Training materials should cover both the “why” and “how” of improved admin search. - Funding: Community plugins that behave like infrastructure may warrant targeted funding or sponsorship. ### 🧠 Learning Styles Assessment - Reading level estimate: Likely around Grade 9–11 (Flesch–Kincaid), with moderate technical vocabulary. #### 👀 Visual learners - Present: Primarily text-based explanation. - Improve: Add architecture diagrams of query flow, database indexing, and before/after search result examples. #### 🔊 Aural learners - Present: No audio. - Improve: Provide a short audio or screencast explanation of why admin search is weak and how the plugin helps. #### 🗣️ Verbal learners - Present: Clear narrative and definitions in prose. - Improve: Add more analogies comparing naive vs. full-text search, plus a mini glossary. #### 🧩 Kinesthetic learners - Present: Implied “install and try” path. - Improve: Step-by-step tasks and small labs (e.g., “Optimize search for a CPT in 10 minutes”). #### 🧠 Logical learners - Present: Problem-solution framing around search limitations. - Improve: Tables comparing query types, decision trees for when to use FULLTEXT, and quantified benchmarks. #### 🧑‍🤝‍🧑 Social learners - Present: Community framing and invitation to collaborate. - Improve: Guided discussion prompts for meetups and contribution sprints. #### 🧘‍♀️ Solitary learners - Present: Article format that supports independent reading and reflection. - Improve: Add self-check questions and reflection prompts on current search pain points. #### 🌿 Naturalistic learners - Present: Minimal. - Improve: Use ecosystem analogies (search as “infrastructure habitat”) and lifecycle thinking for plugin maintenance. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Likely standard heading structure from WordPress blog theme. - Improve: Ensure clear heading hierarchy and descriptive link text. #### Keyboard navigation - Present: Standard theme likely supports basic tabbing. - Improve: Confirm focus states, skip links, and absence of keyboard traps. #### Contrast and readability - Present: Depends on site theme; likely acceptable. - Improve: Verify contrast ratios and comfortable line spacing on all devices. #### Text resizing and reflow - Present: Responsive site should handle basic zoom. - Improve: Test at 200%+ zoom; respect prefers-reduced-motion where animations exist. #### Media and captions - Present: Primarily text and links. - Improve: For any future videos or diagrams, provide captions, alt text, and transcripts. #### Forms and interactions - Present: Newsletter signup form. - Improve: Ensure clear labels, error messages, large click targets, and no placeholder-only labels. #### Standards reference - Map remaining issues to WCAG 2.2 AA (e.g., 1.4.x for contrast, 2.1.x for keyboard). ### 🌍 DEIB Assessment #### Cultural breadth - Present: WordPress-focused, globally relevant but not explicitly multi-regional. - Improve: Include examples from a variety of site types and regions; link to translations if available. #### Inclusive language - Present: Neutral, professional tone with minimal jargon. - Improve: Add more plain-language summaries of technical terms. #### Neurodiversity support - Present: Logical structure and headings. - Improve: Further chunk content, use consistent patterns, and ensure icon+text where visuals are added. #### Representation - Present: Text-only, no imagery of people. - Improve: When adding visuals, ensure diverse, thoughtfully described imagery. #### Psychological safety - Present: Collaborative, respectful framing. - Improve: Add explicit community guidelines and expectations for contributors on GitHub. ### ✅ Logical Validity #### Strong reasoning - Identifies a widely recognized pain point (weak admin search) and proposes a concrete, open solution (the plugin). - Uses causal reasoning: better indexing and relevance should improve search outcomes. #### Fallacies - No major fallacies evident in the available text; claims are modest and experience-based. - Future data (benchmarks, case studies) would further strengthen arguments. #### Tone of voice - Pragmatic, community-oriented, and non-salesy. - Emphasizes trust, extensibility, and shared ownership rather than product hype. ### 🛡️ DARVO Analysis - Deny: No denial or minimization; the author openly acknowledges that “WordPress search just sucks.” - Attack: No attacks on individuals or groups; criticism is directed at a technical limitation. - Reverse victim/offender: No attempt to claim victimhood; the focus is on collaborative problem solving. ## 🎯 Conclusion FullText Search for WP treats wp-admin search as shared infrastructure worth fixing together. By using FULLTEXT and inviting community contributions, it aims to turn a long-standing weakness into a reliable, extensible tool. Next steps for readers: review the GitHub repo, test the plugin on non-production sites, file issues, and consider how your own plugins could integrate with and benefit from a stronger admin search layer. ## 🧱 Refactor Appendix (append after 🎯 Conclusion) ### 📚 Literature Split Pad - Purpose: Stage Konik CEE units that become per-source Literature notes. - Split level: **H3**. - Include verbatim quotes under 25 words and a [view highlight] link. ### [H1] 5–10-word present-tense claim > [!quote] [FullText Search for WP: A Community Plugin](https://mattcromwell.com/fulltext-search-for-wp-community-plugin/) by [[Matt Cromwell]] via [[mattcromwell.com]]. Published 2026-03-17. > “FullText Search for WP is my attempt to close that gap as a community project.” Two lines: context and use. Cite data if relevant. [view highlight](https://mattcromwell.com/fulltext-search-for-wp-community-plugin/#H1) #xref #articleseed ID:rw_[MISSING] ### [H2] 5–10-word present-tense claim > [!quote] [FullText Search for WP: A Community Plugin](https://mattcromwell.com/fulltext-search-for-wp-community-plugin/) > “I want wp-admin search to behave like a tool we can trust and extend together.” Two lines: context and use. [view highlight](https://mattcromwell.com/fulltext-search-for-wp-community-plugin/#H2) #xref ID:rw_[MISSING] --- ### 🔖 Atomic Split Pad (Zettel Candidates) - Purpose: Promote reusable claims into Atomic notes. - Split level: **H4**. - Each item: one idea, present tense, specific, testable. #### [Z1] Community plugins can upgrade wp-admin search - Scope/condition in one line. - Pointer to page/time or dataset. - Links: [[WordPress-Search]] [[Community-Plugins]] #### [Z2] FULLTEXT indexing improves admin search relevance - Scope/condition in one line. - Pointer to page/time or dataset. - Links: [[WordPress-Search]] [[MySQL-Fulltext]] --- ### ✏️ Fleeting Queue (Extract by Selection) - Purpose: Capture quick actions or sparks for Fleeting notes. - Extraction: **Select one line** → “Refactor: Extract selection to new note (content only).” - Keep each line short and self-contained. - [F1] Test FullText Search for WP on a staging site — context/https://mattcromwell.com/fulltext-search-for-wp-community-plugin/ #fleeting #inbox - [F2] Explore how my plugins could register custom fields into a shared search index — context/https://mattcromwell.com/fulltext-search-for-wp-community-plugin/ #fleeting #inbox - [F3] Draft a meetup talk on “Fixing wp-admin search with community plugins” — context/https://mattcromwell.com/fulltext-search-for-wp-community-plugin/ #fleeting #inbox --- <!-- deep-read:sections end --> 📄 **Full text:** ![[Full Document Contents/Articles/FullText Search for WP A Community Plugin|FullText Search for WP: A Community Plugin, Matt Cromwell]] ## Highlights - FullText Search for WP uses a separate dedicated index table. It does not alter `wp_posts` or try to hang a massive FULLTEXT index directly off core tables. That isolates the search workload from the main content tables and makes the tradeoff much more practical for normal WordPress sites. If you are running an enormous media property with Elasticsearch infrastructure, WordPress VIP is right to point you there. But for the large middle of the WordPress ecosystem, there is a very reasonable space between “do nothing” and “stand up a separate search stack.” ([View Highlight](https://read.readwise.io/read/01kkz0njnbqr5ygmdv4x7dp3k1)) - Tags: 👻 ai highlighted - We have had FULLTEXT in MySQL for more than thirteen years. WordPress has the hooks, the APIs, and the community to use it well. FullText Search for WP is not revolutionary, it’s just the next right step in the right direction. ([View Highlight](https://read.readwise.io/read/01kkz0njpjn7vpzdvskbmnxwxc)) - Tags: 👻 ai highlighted