Loading today’s stories
Build1 distinct publisher3 min readPublished
Three support questions about multilingual sites, paid courses and a theme AJAX overlay reduce to one choice: own the render pipeline, or hand WordPress IDs and let the rest of the stack finish.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
The payoff of the ID-return shape is behaviour nobody wrote code for. TranslatePress keeps its strings in its own tables and applies them when the page renders, leaving the post itself in the original language [3]. A plugin that hands WordPress a list of IDs and stops there gets translated output on the way past, without knowing the translation layer is installed [5]. The author's phrasing is that the plugin "answers with IDs and gets out of the way" [5]. Ignorance is the compatibility.
The access-control case is where the arithmetic shows. Render your own results and you inherit somebody else's entitlement model: how it stores purchases, how it changes between releases, and the same exercise again for the next membership plugin your users install [6]. Return IDs and there is one filter on the array, and the site answers the question with the plugin that already knows the answer [7]. That converts a per-vendor integration list into a single extension point [13]. The evidence it is a real interface and not a diagram is that the developer who asked the question wrote the filter himself, sent it in, and it shipped [8].
The part worth copying is the failure guard. Replacing search normally means injecting results and stripping WordPress's native LIKE clause through `posts_search` so its keyword matching does not fight your ordering [9]. If the matcher then times out, exhausts its quota or loses a network path, you return nothing and WordPress has nothing left either, so the results page is empty rather than mediocre, and the site owner hears about it from a customer [10]. The fix is to strip the clause only when a query flag says matching already succeeded [11]. Note what that implies about ordering: the guard is only worth anything if the matcher has finished by the time the filter fires, so the flag cannot be set optimistically at the top of the request [15]. The author is straight about the fallback being worse than what the plugin offers, and better than blank [11].
The cost is admitted too. Owning the pipeline is the only way to guarantee the markup comes out exactly as intended, which is precisely why those plugins fight everything else on the page [12]. Anyone selling a specific results layout is paying for it with every other layer on the site.
One gap: the piece opens by saying all three questions turned out to be the same question, including why search behaves differently inside a premium theme's AJAX overlay [1], but the supplied text works through only the multilingual and membership cases [14]. The overlay is the one where a theme, not a plugin, owns the last mile, and it is the case a reader would most want spelled out.
Ranked by verification strength, evidence, and original report placement.
If the plugin returns IDs, a single filter (apply_filters( 'my_plugin_result_ids', $ids, $query )) lets the site decide; the membership plugin already knows who can see what, so the search plugin does not reimplement it and does not ship an integration per vendor.
The author was asked three apparently unrelated questions in the space of a month: whether search can work on a site translated with TranslatePress where a visitor types in one language and reads in another; whether search can hide course content the visitor has not bought; and why search behaves differently inside a premium theme's AJAX overlay. He states all three turned out to be the same question.
A plugin that replaces WordPress search takes one of two shapes: own the pipeline (build your own index, match, produce and render the result list), or answer with post IDs, handing WordPress a list of IDs in the chosen order and letting the rest of WordPress carry on.
TranslatePress stores translations in its own tables and applies them at render time; the post itself stays in the original language.
A search plugin maintaining its own index builds that index from the original content, because that is what is in the database, so a visitor browsing in Finnish who types a Finnish word gets nothing back, and the translation layer never gets a chance to help because the plugin never handed anything to WordPress.
In the ID-returning shape the flow is: content stored in language A, plugin matches and returns post IDs, WordPress builds the loop, translation layer renders in language C. The plugin does not need to know translations exist; per the author it 'answers with IDs and gets out of the way', and this is not a feature anyone built but what you get for not owning the last mile.
Follow any of these and your For You feed starts watching them — no settings page required.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
First-hand code walkthrough, single uncorroborated source
The mechanisms are specified precisely enough to be checked by any WordPress developer: named hooks (posts_search), a result-ID filter, the post__in/orderby pattern, and TranslatePress's render-time translation model. That raises evidence above pure opinion. But the cluster is one self-published post by the plugin's own author, with no second publisher, no named plugin or repository, no benchmarks, and no error or incident data behind the blank-search failure narrative.
No adoption data disclosed
The plugin is never named and the post discloses no installs, downloads, deployments, or user counts. The only uptake-like datum is one anecdote about a single user-written filter being merged, which is not a measurable adoption signal for either architectural shape.
Mild overreach in framing, honest in body
The prescriptive title ('should return post IDs and nothing else') generalizes a universal rule from three support conversations and one unnamed plugin, which is slightly ahead of the evidence. The body pulls most of that back: the author quantifies nothing, admits the pattern as implemented only hooks the main query, and concedes the fallback path yields worse relevance. Net overstatement is small.
Author advocates the architecture of his own plugin
The post is written by the maintainer of the plugin whose design it defends, and the argument doubles as a rationale for why that plugin composes well with translation and membership software while rivals allegedly conflict. Mitigating factors: no product name, price, link-out, or call to action appears, and the author volunteers a limitation section against his own thesis, so the promotional pressure is moderate rather than high.
Moderate: mechanisms credible, scope and uptake unmeasured
Confidence is held mid-range because the technical claims are internally consistent, specific, and verifiable against WordPress core APIs, yet everything rests on one self-interested source with no adoption evidence, no named artifact, and no independent replication of the blank-search failure mode.
build
Six MariaDB versions, one real difference: the only reason to leave 10.6 is the July 2026 clock1 distinct publisher
build
WooCommerce catalog mode: the price you hid is still sitting in eight places1 distinct publisher
build
An exact byte budget is a search problem, and 18 encodes is the wrong way to run it1 distinct publisher
build
A WordPress route is one function call; the contract around it is the actual work1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 25, 2026