WP Manifestindependent plugin directory
manifest / multisite / onesearch

OneSearch WP Registry grade D+. High-severity findings · 2 findingsWP RegistryHigh-severity findings · 2 findingsOpen the reportD+

OneSearch is a WordPress plugin that allows users to search content across multiple brand sites.

★ 9stars
61release downloads
v1.1.2latest · 1mo ago

Install

Download onesearch.zip From the v1.1.2 release on GitHub, Aug 26, 2026

Upload it under Plugins → Add New Plugin → Upload Plugin, then activate.

Install straight from GitHub with WP-CLI:

wp plugin install https://github.com/rtcamp/onesearch/releases/download/v1.1.2/onesearch.zip
No built-in updater. New versions won't appear under Dashboard → Updates. Install new releases yourself, or let Git Updater track the repository.

Banner

OneSearch Project Status: Active – The project has reached a stable, usable state and is being actively developed.

Contributors: rtcamp, shreya0204, danish17, vishalkakadiya, rishavjeet, vishal4669, up1512001, justlevine, aviral-mittal

Tags: OnePress, OneSearch, Cross-site search, Multi-brand network, WordPress multisite, Federated search, Algolia

License: GPL v2 or later

OneSearch is a OnePress ecosystem plugin that enables cross-site, brand-aware search across a multi-brand WordPress network. It powers unified discovery across sites, powered by Algolia.


🧠 What is OneSearch?

OneSearch is part of the OnePress ecosystem, designed to enable cross-site search across multi-brand WordPress networks. It centralizes the discovery process, allowing users to search and retrieve relevant content from multiple connected sites from whichever site(s) in your brand network you choose to make searchable.

This plugin acts as the backend engine that powers the indexing, querying, brand network management, and filtering logic needed for federated search.


💡 Why OneSearch?

Managing content across multiple brands, regions, or business units often results in disconnected search experiences. This can lead to broken user journeys and lost discovery opportunities.

OneSearch solves this by enabling a federated search layer that bridges multiple sites, powered by Algolia delivering a consistent and brand-respecting experience across the network.

Benefits

  • Unified Search Layer: Execute a single search query across multiple connected sites.
  • Brand Awareness: Show source brand site and redirect user to the respective site.
  • Governance & Control: Control visibility and indexing scope at the site or post-type level.
  • Developer Extensibility: Easily register post types, taxonomies, and metadata for indexing.
  • Performance Optimized: Lightweight REST architecture with cache-friendly responses.
  • Modular Design: Extend and customize indexing and search behavior without core overrides.

🪄 Key Features

  • Cross-Site (Federated) Search: Aggregate search results across multisite or standalone installations.
  • Configurable Indexing: Register which post types, taxonomies, or meta fields are searchable on a per-site basis.
  • Custom Blocks: Gutenberg-ready blocks for search interfaces.
  • Bring Your Own Key: Connect it with your Algolia instance for improved data sovereignty and reduced vendor lock-in.

🧾 Requirements

Requirement Version
WordPress >= 6.8
PHP >= 8.2

🧰 Installation

  1. Download the latest OneSearch plugin from the GitHub releases and install it on your WordPress sites.
  2. Activate the plugin. For multisite installations, make sure to Network Activate the plugin.
  3. Visit the Dashboard > OneSearch > Settings page to configure the Governing and Brand sites.

    Setting Up OneSearch

    Plugin Setup

  4. Install and activate the OneSearch plugin on the governing site and brand sites.
  5. From the Dashboard > OneSearch > Settings page or the plugin activation modal, set the Site Type to either 'Governing Site' or 'Brand Site'.
    • Governing Site: The central site that manages the brand network and search configurations. There should be only one governing site in the network.
    • Brand Site: The individual sites that will be connected to the governing site for cross-site search.
  6. On the brand site, navigate to Dashboard > OneSearch > Settings to get the API key.
  7. On the governing site, navigate to Dashboard > OneSearch > Settings, and add the brand site by entering the Site name, URL and the API Key obtained from the brand site.

Setting up Algolia

To connect your site with Algolia, follow these simple steps:

  1. Visit Algolia and create an account (if you don't already have one).
  2. Go to your API Keys dashboard.
  3. Copy the Application ID and Write API Key.
  4. Paste both keys into the Dashboard > OneSearch > Settings page under the 'Algolia Credentials' section.

Configuring Indices and Search Scope

Indices: The data (post types) stored to make site content searchable. Search Scope: Defines which sites can search or access other sites' indexed data.

Configuring Indices

  1. Head to OneSearch > Indices and Search.
  2. Against each connected site, choose the post types you wish to index.
  3. Click on 'Save' which will also index the data.

Configuring Search Scopes:

  1. Go to OneSearch > Indices and Search and scroll to 'Site Search Configuration' section.
  2. Turn on the toggle for the sites on which you want to enable OneSearch.
  3. In the 'Search from' section, configure which sites can be searched from.

Development & Contributing

OneSearch is under active development and maintained by rtCamp.

Contributions are welcome and encouraged! To learn more about contributing to OneSearch, please read the Contributing Guide.

For development guidelines, please refer to our Development Guide.

Frequently Asked Questions

Does OneSearch support CPTs (custom post types)?

Yes. For each brand site, you can select which built-in and custom post types to index from the Indices and Search settings.

Do I need to manually index a newly published post?

No. Posts are automatically indexed when they are published, and removed when they are deleted or otherwise unpublished (e.g. trashed, changed to draft, etc.).

Are updates to an already indexed post automatically handled?

Yes. Any updates made to a post are automatically synced with the Algolia index.

How are the search results ranked?

Search results are ranked by Algolia's relevance algorithm. However, OneSearch boosts results from the current site you're searching on, ensuring more relevant local content appears first. You can further customize ranking and relevance through Algolia's dashboard.

Get Involved

You can join the development and discussions on GitHub. Feel free to report issues, suggest features, or contribute code.

Releases

7 releases. Each count is every asset in that release; expand a row for the breakdown.

Tag
Published
Assets
Downloads
v1.1.2 latest
Aug 26, 2026 1mo ago
onesearch.zip
10
Aug 26, 2026 1mo ago
onesearch.zip
3
Jul 23, 2026 3mo ago
onesearch.zip
6
Mar 10, 2026 7mo ago
onesearch.zip +9 assets
28
onesearch.zip4
pr-146-d7325ddbfee9a771610c3ca7c90039ad79592e08.zip7
pr-146-f6384fae7d8a41ef9fefeaad1d924081afe1367a.zip3
pr-157-2849a4b3004120c9805169362e0e4cf3d7b49be8.zip2
pr-156-4ad5d648cfd58b93081a1dd12c7b42e0f8fabb9e.zip2
pr-151-42f09f8a9c6594ff257c4d69c26ec1fb86a7c168.zip2
pr-155-4f982bba2923c581172e61aac5acbaddc7ec6fac.zip2
pr-151-dfc57e8cd824e1fa10fc94cd533f51f2bee01975.zip2
pr-153-9066e985452261e035bd66abfae8edfaba3182f5.zip2
pr-153-f330ee3d894ddd5d6bea9db79d4b6e1950acaa33.zip2
Feb 20, 2026 8mo ago
tag only
—
Jan 28, 2026 8mo ago
onesearch.zip
3
Oct 13, 2025 1 year ago
onesearch.zip
11
D+ grade

Security

OneSearch 1.1.2 · audited by WP Registry

High-severity findings.

1 high 1 medium
Audited release
1.1.2
Findings
2
Worst severity
high
Content hash
4da899d23d6392b439393a0e…

Findings

  • high Brand-site API token can replace governing Algolia write credentials and trigger network reindex

    missing_capability

    On a governing site, POST /wp-json/onesearch/v1/algolia-credentials and POST /wp-json/onesearch/v1/re-index both use permission_callback check_api_permissions. After hash_equals of X-OneSearch-Token against the API key stored for the Origin / X-OneSearch-Site-URL brand, is_governing_site() returns true with no current_user_can('manage_options') and no method-level split. That is inconsistent with POST /indexable-entities, which correctly requires manage_options. Anyone who has a connected brand site's token (brand administrator via the settings screen, leaked key, compromised brand site) can, with no WordPress user on the governing site, POST a new Algolia app_id/write_key. update_algolia_credentials() validates the key has addObject+deleteObject then Search_Settings::set_algolia_credentials() overwrites option onesearch_algolia_credentials; purge_cache_on_update pushes the new keys to every brand. Frontend Search::get_algolia_results() then queries the attacker index and build_post_from_record() copies hit content/permalink into WP_Post objects rendered on public search pages (stored XSS / phishing). The same token can POST /re-index, which reindexes the governing site and fans out to every brand. GET of the write key via /brand-config is required for indexing and is not this bug; SET of the network credentials is.

    inc/Modules/Rest/Search_Controller.php:29-55,89-97,107-120

    Recommendation

    Gate POST /algolia-credentials and governing-site POST /re-index on current_user_can('manage_options') (same pattern as POST /indexable-entities). Keep check_api_permissions only on the brand-facing reads (GET /brand-config, GET /algolia-credentials, GET /all-post-types) and on brand-site POST /re-index that the governing site legitimately triggers. Consider issuing per-brand Algolia keys with index restrictions instead of distributing the network write key.

  • medium Health-check token auth rebinds an already-paired brand site's governing parent

    auth_bypass

    GET /wp-json/onesearch/v1/health-check is the pairing endpoint. On a consumer/brand site, check_api_permissions accepts X-OneSearch-Token matching onesearch_consumer_api_key and then, for this route only, skips the 'Origin must match the recorded governing site' check and unconditionally Settings::set_parent_site_url($request_origin). $request_origin comes from the attacker-controlled Origin header, or X-OneSearch-Site-URL when Origin is empty. The inline comment says this bootstraps the relationship 'since none is recorded yet', but the code never tests that onesearch_parent_site_url is empty, so a second caller with the same long-lived brand key (leaked key, former governing site, malicious second governing site) overwrites the parent even after a legitimate pair. Subsequent Governing_Data_Handler::get_brand_config() wp_safe_remote_get's {parent}/wp-json/onesearch/v1/brand-config and caches attacker-supplied algolia_credentials in transient onesearch_brand_config_cache (WEEK_IN_SECONDS). That brand then indexes published content to the attacker and renders attacker search hits. SiteModal.tsx troubleshooting copy even tells admins the health-check should fail when a governing site is already connected; the PHP never implements that.

    inc/Modules/Rest/Abstract_REST_Controller.php:107-120

    Recommendation

    Only call set_parent_site_url when get_parent_site_url() is empty; if a parent is already recorded, require Origin/X-OneSearch-Site-URL to match it (same is_url_from_host check as other consumer routes) and do not overwrite. Prefer a dedicated POST pairing route gated so an existing parent can be replaced only after DELETE /governing-site (manage_options) or an explicit re-pair nonce. Rotate the brand API key after pairing.

WP Registry hashes the installable build and reports on that exact bytes-for-bytes copy. Embargoed findings are withheld until they are disclosed, so a clean verdict means nothing public is outstanding. WP Manifest does not audit code itself.