I designed and built mikejayduran.com from end to end, my bilingual personal site, on WordPress with the Blocksy theme (responsive and lightweight). The visual design went through three complete iterations before it settled, all of them chasing the same thing: a careful interface that gets out of the way and hands the spotlight to the articles, which are the whole point of the site.
That minimalism is not just a facade, it governs the inside too. I keep plugins to a minimum and solve most functionality with my own PHP and JavaScript snippets, because every plugin is maintenance surface, performance surface and attack surface that has to earn its place. Those snippets cover Open Graph and Twitter Card generation, selective noindex, preloading of critical resources, converting Markdown into Gutenberg blocks (I write in Markdown and I would rather not wrestle with the editor on import), and a handful of security measures: the admin entrance lives behind alias routes and wp-login.php returns a 404 to anyone without a session, with XML-RPC and comments explicitly disabled. Running through all of it is a privacy criterion: self-hosted typefaces instead of Google Fonts, local avatars instead of Gravatar, and not a single third-party cookie.
The tag filter on the front page works through a query string, deliberately so, which lets tag combinations be cached server-side with WP Super Cache instead of running PHP on every visit. And since a cold cache only ever benefits the second visitor, whenever I publish an article a background process walks the most frequent combinations through WP-Cron and warms them, so that whoever arrives first already finds the page served from cache. The site ends up noticeably snappier.
The most interesting technical problem I solved was a redirect bug: the English version of the site (/en/) served the Spanish front page without raising a single error, not on screen and not in the console. Silent failures are the worst of their kind, because nobody reports them: an English-speaking visitor assumes the English version does not exist and leaves. And a 301 from /en/ also teaches Google that the URL does not deserve to be indexed in its own right, so the bug was actively working against the site’s own bilingualism.
The first question was whether this was a genuine server-side redirect or a client-side mirage. I ruled out browser cache, cookies and snippets one by one. Confirmation came from the browser’s Network panel: I exported the traffic to a HAR file and filtered by status code, and there it was, a 301 Moved Permanently from /en/ carrying a Location: /es/ header, followed by a second chained request that returned 200 OK in Spanish. Two requests where there should have been one, which is exactly what a server-side redirect produces and what no cookie or cache ever will.
What the HAR could not tell me was why. A request to WordPress is not an atomic step but a long, ordered sequence of hooks that any of the dozens of active pieces can attach itself to. So I instrumented the load cycle: I placed pll_current_language() checkpoints across the process, in execution order, and watched where the value went wrong. It stayed correct until late in the request and was only wrong by the time Polylang’s own canonical-check method (PLL_Canonical::check_canonical_url) read it. That pointed at Polylang, and my first conclusion was exactly that: a defect in the plugin. It was a plausible story, it fit a corner case others had documented, and the patch I wrote on the back of it worked. So I accepted it.
That was the mistake, and catching it is the part of this I am most glad about. Later, trying to document the bug properly, I checked the story against my own settings and it fell apart: English, not Spanish, was the site’s default language, which is the opposite of what my explanation required. The fix worked, but the reason attached to it was wrong. So I started over, and this time I ruled things out with tests instead of reasoning about them. Cookies and Accept-Language headers, checked one at a time with curl: the redirect fired no matter what. The language of the most recent post, tested by re-dating an English post to make it the newest on the site: no change. Then I read Polylang’s own source and found that its canonical check only ever reads the current language, it never writes it, which meant it was a witness to the corruption, not its cause. The value was already wrong before Polylang ever looked at it.
What settled it was turning everything off. With all of my own custom snippets disabled and Polylang left alone, the bug vanished. So it had never been Polylang. A binary search through my snippets, re-enabling them in halves and re-testing, landed on the one that powers the homepage’s featured-article cards, which I had added to the site two weeks after the original fix.
The real cause was in my own code. That snippet built the homepage query by matching both language categories at once, Spanish and English together, through a single ambiguous query. Polylang’s canonical check reads that query to decide what language the page is, and faced with two categories it takes whichever one comes first in the list, which happened to be Spanish, and concludes the page is Spanish every time, regardless of the URL. That is exactly why every test about cookies and headers had come back negative: none of those signals were ever being read. I confirmed it the most direct way I could, by reversing the order of the two categories, and the bug reversed with it: now Spanish redirected to English. Being able to flip a bug by swapping one line is as close to proof as this gets.
The fix was to query a single category, the one matching the language actually being viewed, which removes the ambiguity Polylang was resolving wrongly. My original patch, written when I still blamed the plugin, suppresses the redirect on the homepage and restores the language flag if it is ever corrupted. It is no longer load-bearing, but I keep it active as a cheap safety net, since it neutralises itself once the real cause is gone.
What I take from this is not the fix but the correction. The patch worked, so it would have been easy to leave the explanation as it was and move on. What was wrong was the story, a plausible one I had never tested against my own configuration, and the bug turned out to be mine, not the plugin’s. The only way to find that was to distrust an account that already worked and keep digging. That habit, far more than any single specific line of PHP, is what finding engineering solutions is really about.