Kody Search adds a fast dropdown search to your site. A visitor starts typing and matching\nposts and pages appear straight away, with the query terms highlighted and no page reload.<\/p>\n\n
Fast, and light on your server.<\/strong> The search index loads in a single request the first\ntime a visitor uses the search box. Every keystroke after that is matched in their browser,\nso your server sees one request per visit, not one per keystroke, and results stay instant\nno matter how many people are searching at once.<\/p>\n\n Looks like part of your site.<\/strong> The search box picks up your active theme's fonts and\nform styling. There is nothing to skin and no CSS to write.<\/p>\n\n Nothing to tune.<\/strong> No relevance weights, no ranking rules, no settings you have to get\nright before results are good. Add the block and it works.<\/p>\n\n Accessible.<\/strong> Full keyboard navigation, correct combobox semantics, and screen reader\nannouncements for results.<\/p>\n\n Stays out of the way.<\/strong> Scripts and styles load only on pages that actually have a search\nbox, and the public search endpoint is rate limited against abuse.<\/p>\n\n Full page results too.<\/strong> A dedicated results page with pagination and a running count,\nlinked from the dropdown as \"View all results\".<\/p>\n\n Post titles, Search Tags, and categories. Search Tags is a field Kody Search adds to the\neditor, kept separate from your site's regular Tags so tagging something for search does not\nalso change your navigation. Kody Search does not search the body text of articles.<\/p>\n\n Sites up to roughly 15,000 posts and pages. If you need full text search across article\nbodies, or you run a larger site, a search plugin backed by a server index is the better\nchoice, and Kody Search will tell you on its settings screen once you cross that size.<\/p>\n\n This plugin ships its complete source. Nothing is obfuscated. Only the two block\neditor scripts are compiled; all PHP, all CSS, and the front-end JavaScript in\n assets\/ run exactly as shipped, with no build step.<\/p>\n\n The only generated files in the plugin are:<\/p>\n\n They are the webpack build of the block editor UI. Each blocks-src\/kody-search-page\/block.json -> build\/kody-search-page\/block.json (copied unchanged)<\/p>\n\n edit.js is ordinary JSX built on the Dependencies (see package.json):<\/p>\n\n Developed and built with Node.js 20 and npm 10.<\/p>\n\n From the plugin directory:<\/p>\n\n This rebuilds the four generated files above from rebuild the editor picks up the change with no other edits.<\/p>\n\n All PHP is PSR-4 autoloaded ( Post titles, Search Tags, and categories. Not the body text of articles, and not your\nsite's regular Tags. If a word matters for finding a post, add it to that post's Search\nTags panel.<\/p><\/dd>\n Published posts and pages only, of the types ticked under \"Content to search\". Drafts,\npending and scheduled posts, private posts, and password-protected posts are all left out.\nA scheduled post is added by itself the moment it goes live, and a published post that\nlater becomes a draft, gets a password, or is trashed is removed from the index on save.<\/p>\n\n This matters because the index is downloaded by the visitor's browser: everything in it is\ncontent any visitor could already reach on your site.<\/p><\/dd>\n The index builds the first time you open the Kody Search screen, then updates on its own\nwhenever a post is published, edited, trashed, or deleted. For bulk changes that skip the\neditor, such as an import, a migration, or renaming a category, there is a Rebuild Index\nbutton that refreshes everything.<\/p><\/dd>\n No. Kody Search covers posts and pages and has no WooCommerce dependency.<\/p><\/dd>\n The settings screen offers posts and pages. Other post types can be added by a developer\nwith the Yes. Matching happens in the visitor's browser, which is what makes results instant and\nkeeps the load off your server. With JavaScript disabled the search box renders but does\nnot return results. Your theme's own search form is unaffected and keeps working.<\/p><\/dd>\n No. Kody Search adds its own box and its own optional results page, and leaves the\nbuilt-in search, your theme's search template, and No. There are no external requests of any kind, no analytics, no telemetry and no\naccounts. Everything runs on your own site, and the search index is stored in your own\ndatabase.<\/p><\/dd>\n Partly, and it does no language filtering of its own.<\/p>\n\n On Polylang, a rebuild covers every language. On WPML, a rebuild covers only the language\nyou are viewing the admin in, so use the Rebuild Index button once per language, or expect\nthe other languages to drop out.<\/p>\n\n Either way, results are not filtered by language: a visitor may see matches from every\nlanguage you have indexed. If language-aware search matters to your site, a plugin built\nfor multilingual search is the better fit.<\/p><\/dd>\n Yes. The Design tab has spacing and sizing controls. Past that the box follows your theme,\nso it matches without any CSS.<\/p><\/dd>\n Yes. The block has a \"Limit this search box\" panel, and the shortcode takes a Yes, as many inline search boxes as you like, each working independently. The full\nresults view (the Kody Search Page<\/strong> block or Up to roughly 15,000 posts and pages. Beyond that, results would only cover part of your\ncontent, and the plugin says so on its settings screen. A search plugin backed by a server\nindex is the better fit at that size.<\/p><\/dd>\n Yes, it is rate limited per visitor. Sites behind a CDN or proxy can adjust how visitors\nare identified with the Yes. If a cached page carries an expired security token, the search box refreshes it\nautomatically instead of failing.<\/p><\/dd>\n Yes. Network-activate it and every site gets its own search index; sites you add later\nare set up automatically. You can also activate it on individual sites instead. Each\nsite's index and settings are its own, and settings live on that site's Kody Search\nscreen, not a network screen.<\/p><\/dd>\n Deleting it from the Plugins screen removes its database table and every option it\ncreated, so nothing is left behind. Deactivating changes nothing, so you can safely turn\nit off and on again. Your posts and pages are never touched either way.<\/p><\/dd>\n\n<\/dl>\n\n\nWhat it searches<\/h4>\n\n
Where it fits<\/h4>\n\n
Development<\/h3>\n\n
What is compiled, and from what<\/h4>\n\n
\n
build\/<\/code> directory has one\nmatching source directory shipped alongside it:<\/p>\n\n\n
@wordpress\/*<\/code> packages (@wordpress\/blocks<\/code>,\n@wordpress\/block-editor, @wordpress\/components<\/code>, @wordpress\/data<\/code>,\n@wordpress\/core-data, @wordpress\/i18n<\/code>, @wordpress\/element<\/code>). index.asset.php<\/code> is generated by\n@wordpress\/scripts: it lists the wp-*<\/code> script handles the compiled file depends on\nand a content hash used for cache busting.<\/p><\/li>\n<\/ul>\n\nBuild tooling (all included in the plugin)<\/h4>\n\n
\n
createElement<\/code>,\n resolved through import { createElement, Fragment } from\n '@wordpress\/element'<\/code> at the top of each edit.js) instead of the\n automatic runtime. The automatic runtime would add a dependency\n on the react-jsx-runtime<\/code> script handle, registered in WordPress\n core only since 6.6; the classic runtime keeps the compiled\n output dependent only on handles present since WP 5.0, so the\n \"Requires at least: 6.3\" header stays accurate. The pragma names\n an imported identifier rather than the wp.element.*<\/code> global so\n that build-time dependency extraction can see it and list\n wp-element in index.asset.php.<\/li>\n<\/ul>\n\n\n
Reproduce the block build<\/h4>\n\n
npm install\nnpm run build\n<\/code><\/pre>\n\nblocks-src\/<\/code> and re-copies the two\n block.json files. npm run start<\/code> runs the same build in watch mode. Building against\nan unchanged blocks-src\/<\/code> reproduces the same build\/<\/code> output (the hash in\n index.asset.php is derived from the compiled bytes, so it only changes when the\nsource does).<\/p>\n\nBlockModule (src\/Modules\/BlockModule.php) registers both blocks from `build\/` via\nregister_block_type(), reading each `block.json` + `index.asset.php` - so after a\n<\/code><\/pre>\n\nPHP<\/h4>\n\n
Kody\\Search\\<\/code> -> src\/<\/code>) through Composer; composer.json<\/code>\nis included. There are no runtime Composer dependencies - the only thing shipped under\n vendor\/ is the generated autoloader. Regenerate it with:<\/p>\n\ncomposer install --no-dev --optimize-autoloader\n<\/code><\/pre>\n\nTranslations<\/h4>\n\n
languages\/kody-search.pot is generated with WP-CLI:\n\nwp i18n make-pot . languages\/kody-search.pot --slug=kody-search --domain=kody-search\n<\/code><\/pre>\n\n\n\n
[kody_search]<\/code> shortcode, wherever you want the\nsearch box, for example your header or sidebar.<\/li>\n[kody_search_page]<\/code> shortcode to a page\nand select that page under Kody Search, so the dropdown's \"View all results\" link has\nsomewhere to go.<\/li>\n<\/ol>\n\n\n\n
What does it search?<\/h3><\/dt>\n
What content ends up in the index?<\/h3><\/dt>\n
How does indexing work?<\/h3><\/dt>\n
Does it need WooCommerce?<\/h3><\/dt>\n
Does it work with custom post types?<\/h3><\/dt>\n
kody_search_post_types<\/code> filter, and they are then indexed and searchable like\nany other content.<\/p><\/dd>\nDoes it need JavaScript?<\/h3><\/dt>\n
Does it replace the WordPress search page?<\/h3><\/dt>\n
?s=<\/code> URLs exactly as they were.<\/p><\/dd>\nDoes it send anything to an external service?<\/h3><\/dt>\n
Does it work with WPML or Polylang?<\/h3><\/dt>\n
Can I change how the search box looks?<\/h3><\/dt>\n
Can one search box cover only certain content?<\/h3><\/dt>\n
post_types<\/code>\nattribute. Leave it unset to search everything.<\/p><\/dd>\nCan I put more than one search box on a page?<\/h3><\/dt>\n
[kody_search_page]<\/code> shortcode) is\ndifferent: use one per page. It is meant to be the main content of a dedicated results\npage, and a second one on the same page will not run.<\/p><\/dd>\nHow large a site does it handle?<\/h3><\/dt>\n
Is the search endpoint protected against abuse?<\/h3><\/dt>\n
kody_search_rate_limit_identifier<\/code> filter.<\/p><\/dd>\nDoes it work with page caching?<\/h3><\/dt>\n
Does it work on WordPress Multisite?<\/h3><\/dt>\n
What happens when I delete the plugin?<\/h3><\/dt>\n
1.0<\/h4>\n\n
\n