Building a Community Wiki Around a Privacy-First Search Engine

#privacy #php #opensource #webdev

The problem: a search engine needs more than a search box

findnix.eu is a EU-based, privacy-first search engine — "Find alles, speichere nix" (find everything, store nothing) is the tagline. Once real users started using it, the support questions started too: how does the spam filter work, why isn't my site indexed yet, what data do you actually store, how do I report a fake shop I found in the results?

Answering the same questions over email doesn't scale, and a single flat FAQ page doesn't either once you also want space for longer-form, kid-safe explainer articles and general knowledge entries contributed by the community. So instead of bolting a FAQ page onto the main site, we split it out into its own project: wiki.findnix.eu.

Three categories, one wiki

The wiki is organized into three top-level groups, each with its own short-link in the header:

FAQ findnix — how the search engine, the spam filter, the DNSBL cross-check, and the points/rewards system work
Kids findnix — safe, curated explainer content that doubles as background material for kids.findnix.eu
Wiki findnix — general knowledge entries submitted by the community, reviewed before they go live

Every entry goes through a submit.php form and lands in a moderation queue with status='approved' as the gate — nothing is public until someone actually looks at it. That single status column is doing a lot of quiet work: it's the difference between "anyone can publish anything" and "anyone can propose something."

Translation without an embedded widget

The wiki needs to serve an EU-wide audience, and hard-coding 20+ language files for community-submitted content isn't realistic for a small team. The pragmatic fix: a language dropdown that builds a one-time link to Google's translate.goog proxy for the current page, entirely client-side, on click:

function wikiGoTranslate(lang) {
  if (!lang) return;
  var host = location.hostname.replace(/\./g, '-');
  var path = location.pathname + location.search;
  var target = 'https://' + host + '.translate.goog' + path
    + (location.search ? '&' : '?')
    + '_x_tr_sl=de&_x_tr_tl=' + lang + '&_x_tr_hl=de';
  location.href = target;
}

No translation script is embedded or running in the background on the page itself — it's a single click handler that computes a URL and navigates. That turned out to matter more than expected: an earlier version embedded Google's live translation widget directly on the page, and it collided with the sticky header (the widget would inject its own top bar and push the layout around). Moving to a proxy-link model instead of an embedded widget removed an entire class of layout bugs, and it means one less third-party script running continuously against visitors' browsers.

Old links still have to work

Categories used to be addressed by numeric ID (?cat=12). Once the wiki grew nice slug-based URLs (?cat_slug=faq-findnix), old bookmarks and inbound links with the numeric form still needed to resolve — so the numeric path does a lookup and issues a real 301 redirect to the slug URL rather than silently rendering the same content on two different URLs:

if ($catId && !$catSlug) {
    $lookup = db()->prepare('SELECT slug FROM categories WHERE id=?');
    $lookup->bindValue(1, $catId, SQLITE3_INTEGER);
    $row = $lookup->execute()->fetchArray(SQLITE3_ASSOC);
    if ($row && $row['slug']) {
        header('Location: /k/' . $row['slug'], true, 301);
        exit;
    }
}

Small detail, but it's the difference between a wiki that quietly accumulates duplicate/dead URLs over years and one that doesn't.

What's next

The wiki is deliberately simple: SQLite-backed, PHP, no JS framework, no build step. That's a feature, not a limitation — it means the barrier to contributing an entry, or to reading the code and understanding exactly what happens to a submission, stays low. As findnix.eu grows, the plan is to keep leaning on the community to write the FAQ and knowledge entries rather than trying to centrally author everything — the people hitting an edge case are usually the best people to explain it to the next person who hits it.

If you want to see it in action (or contribute an entry), it's live at wiki.findnix.eu.

DEV Community