One name for the game

Two abandoned websites, 1,104 redirects, and a launch day with numbers

M.A.G.U.S. Kártya is a Hungarian collectible card game that has been played since 1997. Until this August it had two websites, and neither was maintained: the first had been abandoned for years, the second had been losing images for a while and did not work on phones. This post is about the decisions that turned them into one site, not about the migration scripts. The community those sites serve is the same one that plays on my side project, maguskartya.app: a virtual tabletop, an online table where players meet each other with their own decks, plus a machine opponent for newcomers that plays by heuristics on a reduced card pool. The two sites are connected at the end.

What was there

The publisher’s portal went online in 2004 and published its last article in 2021. It holds 1,984 articles, 1.49 million words by 36 authors. Its catalogue of expansions stops years before the current ones. It also serves every article page cut off after its title, because the theme’s comment counter queries a database that no longer exists. I had admin access, and the other admins confirmed what the pages showed: nobody was maintaining it.

The fan team’s WordPress site took over in 2021. It had the current content: 73 pages, 470 posts, 523 tournament dates, 2.7 GB of images. It also had a domain named after the team rather than the game; forty expansions buried three menu levels deep, with a whole decade of releases missing from the list; not one card image with alt text, the description a screen reader or a search engine uses instead of the picture; and 4,307 images hotlinked, embedded straight from other people’s servers, about half of them from servers that had since disappeared. At some point the hosting quota ran out, a cleanup nobody could reconstruct afterwards deleted a large share of the uploaded images, and pages loaded with holes.

An article page on the 2004 portal: below the title, a PHP warning and WordPress's database-connection error stand where the article body should be.
An article page on the publisher’s portal, a post from October 2018. The body is gone; in its place, the database error. Hungarian UI: “Hiba az adatbázis-kapcsolat létrehozása során” means “Error establishing a database connection”. Database user and server path redacted.

None of that is unusual for a volunteer-run site of a small community. The unusual part was treating it as one product to build instead of two sites to repair.

Four decisions before any code

The name is the product. The new domain is maguskartya.hu, the game’s name. The team’s name, Fekete Határ Szindikátusa, is one paragraph on the About page. A search for the game should land on the game, and a newcomer should not have to learn who the syndicate is before finding the rules. The site also uses the same colour palette as the online table, so the two read as one family.

Keep everything, edit nothing written by people. Both sites’ content moved: every article back to 2004, every tournament date, 6,862 card records, and 69 product pages, one for every release since 1997, including the decade that neither old site listed. The 2004 portal’s articles came through its RSS feed, because its API was closed. Article text lost its formatting debris and nothing else. Factual errors on the rules pages were corrected, and each correction was written down. Every image now lives on the site’s own host, converted to WebP, a compact image format: 2.7 GB became 516 MB with no loss of resolution.

The catalogue is data; WordPress only renders it. A release has cards. A card has a record with its printed number, its name, its rarity and a few flags. A tournament format lists the releases it allows, plus its bans and restrictions. An ultra card belongs to a release like any other card. All of it lives as JSON files in a git repository, one folder per release, one record per card next to its image. No product page or format page is edited by hand: a script reads the repository and regenerates all 69 product pages, the format pages and the media library, and a format’s legal card pool is computed on every run instead of being stored anywhere. Hiding a card is one flag. Moving a release out of a format is one line. Either is followed by one run and one check. A page with three hundred images is not something a volunteer should edit in a browser. Two things came free with this: every product page lists its card names as text, which is what a search engine reads, and if the community ever outgrows WordPress, the data is already in the shape a purpose-built site would need. It cost a set of scripts, not custom software.

The files follow the same rule. On the old site one card sat in the media library as cc_phet_lehelet, cc_phet_lehelete and cc_phet_lehellete, next to files called image_234 or named after a print-sheet page number. An author who could not find a card uploaded it again, so duplicates piled up and ate storage. The same card is now one file, 3545-phet_lehelete-400x561.webp: catalogue number, printed name, pixel size. It carries the card’s name as alt text, is served in several sizes at a higher resolution than before, and sits in a media-library collection named after its release, Ősök ébredése, so an author finds it by number or by a fragment of the name. The untouched scans stay in the repository; the site itself never needs them.

Two entrances and a calendar. The old site served the active player well and nobody else. The new one opens with two pages, one for “I am new” and one for “I played years ago”, and both end at the tournament calendar, because the question a newcomer actually has is where they can play. The calendar answers it from data: about two events a week over the last twelve months, half of them in Budapest.

The redirect I refused, then measured

A 301 is a permanent redirect: the old address answers “this moved here”, and browsers and search engines follow. On August 9 I decided not to build one. The reasoning was that this was a new site, not a moved one. The old site would stay on its own domain, so old links would keep working there, and a deep link would have no matching page on the new site anyway.

On August 27 I compared the two sitemaps, the URL lists each site publishes for search engines. 466 of the 475 old article addresses mapped onto a new one with a single rule, a /cikkek/ prefix. The premise held for the pages and failed for 98% of the content. The decision reversed the same day. One number was enough, and the argument before it had rested on an assumption nobody had checked.

The audit that found 247 hidden 404s

The redirect rules were tested first on a spare subdomain against the old sitemap: 550 URLs, 550 landed on a live page, 511 on the exact target. That looked finished.

The day before the switch I simulated every URL I could find on the old site, not only the ones in the sitemap: 1,104 addresses, run through the rules in order and checked against both sites’ live data. 822 landed on target, 35 on the home page, and 247 would have ended in a 404. The cause was the events plugin’s sitemap, which lists only future events, so 244 of the 528 past tournament pages had been invisible to the first audit. After a second pass: 1,102 on target, two intentional home-page fallbacks, zero 404s, 339 rules.

One rule sits above all the others and does nothing visible. It exempts the certificate renewal path. A redirect is sent after the encrypted connection is set up, so the old domain needs a valid certificate for as long as the redirect exists. Without the exception, renewal would fail silently, and every old link would turn into a browser warning some months later.

Launch day

The new site had been live on its own domain for four days. The switch itself was one setting on the hosting panel, on a Sunday: the old domain now points at a folder that holds nothing but the redirect rules. A Facebook post in the community group announced it the same day.

The site measures with PostHog, a product-analytics tool, in cookieless mode: nothing is stored on the visitor’s device, so there is no consent banner. The same PostHog project measures the online table, split by host, and the links between the two carry source tags in both directions.

Launch day: 1,889 page views, 405 visitors. The next three days: 262, 157 and 146 visitors.
Where they came from on day one: Facebook 166, direct 175, Google 22. Seventeen arrived with the old domain as referrer: tabs still open on the old site, clicking through the 301.
42% of page views so far came from phones. The old site was not built for them. The new card grid is three columns on a phone and nine on a wide screen, and the calendar turns into a list.
The two entrance pages were read by 86 and 56 people in four days.

The maguskartya.hu home page on a phone: the site title, a box asking whether the visitor is new to the game with two buttons, the banner of the newest release, and the latest article.
The home page on a phone. Hungarian UI: “Most ismerkedsz a játékkal?” asks whether the visitor is new to the game; the two buttons are “I would play for the first time” and “I played years ago”. Below them, the newest release and the latest article.

The loop to the online table ran in one direction. 65 visitors went from the portal to the table in the first four days, 36 of them straight to the machine opponent. Bot matches started per day had been between one and five for three weeks; on launch day there were 30, and 23 of them were started by people who had come from the portal. Two registrations in the first 48 hours carried the portal’s tag. The other direction was quiet: nine clicks from the table back to the portal in a week. That number is small, and it stays in the post.

What it cost, and what stays reversible

Five weeks from the first inventory to the switch. The hosting is the shared plan the old site already ran on, paid a year ahead at about the price of a managed WordPress plan, with room for both sites. The old WordPress stays there, 10.6 GB of it, with no domain pointing at it: an inert archive, one panel setting away from being served again on its own domain. Google Search Console has the change of address. Nothing in the sequence was irreversible, and that was the condition for doing the switch on a Sunday.

Three things I would keep for any migration of this shape: measure the premise before deciding, because the “no redirect” decision had a number hiding behind it; treat a sitemap as a sample, not an inventory; and leave the old system in place until the new one has earned its traffic.

PeerJS public TURN relay

Finding, fixing, and verifying a relay I never chose

A follow-up to The follow-up file, where I argued that shipping a fix isn’t done until you’ve verified it moved a number. Here’s a case where I did.

The symptom

One Sentry error: negotiation-failed, one user, Safari/Mac, about 19 events in 25 minutes, then it recovered on its own. The kind of thing you write off as a bad network. I checked instead.

The numbers

My app (maguskartya.app) is a peer-to-peer card game over WebRTC, built on PeerJS – a small library that opens the browser-to-browser connections. I queried 90 days of production traffic – 20 players, 64 game sessions:

58% of sessions hit a connection error, a blocking reconnect overlay, or repeated join attempts.
41% showed the overlay; 75% of players were affected.
May looked the same. Not new, not rare.

The cause

I never set iceServers, so PeerJS used its default config. That default already includes a TURN relay – a free, shared, rate-limited public one (turn:eu-0.turn.peerjs.com:3478, credentials peerjs/peerjsp, port 3478, no TLS). When a direct connection failed, players relayed through that shared box. Anyone behind a firewall that blocks 3478 had no fallback at all.

So I wasn’t missing a TURN server. I was unknowingly depending on a bad one.

The fix

A dedicated relay – Cloudflare Realtime TURN. A small Vercel function (turn-credentials.ts) verifies the Clerk session, checks an allowlist claim, and mints a 24h credential. The client fetches it, caches it 23h, and uses it for every peer connection it opens.

The one trap worth knowing: PeerJS’s config replaces the defaults, it doesn’t merge. Pass your own iceServers and you silently lose the default STUN. Re-add it:

			
const turn = Array.isArray(data.iceServers) ? data.iceServers : [data.iceServers];
// peerjs's config REPLACES the defaults - re-add STUN or you lose it.
const servers = [{ urls: 'stun:stun.l.google.com:19302' }, ...turn];

This is a deliberate fallback: if my credential endpoint is ever down, fetching a credential fails, and instead of erroring out, the client just creates the peer with no custom config – so PeerJS uses its old default, the public relay. Players stay connected on a worse relay rather than not connecting at all.

Did it work

Two matched 23-day windows, before and after the deploy, normalized per game so a drop means each game got smoother, not just that fewer people played:

Connection errors per game: 1.38 → 0.36 (-74%).
Reconnect overlays per game: 0.72 → 0.39 (-47%).
Games actually went up over the same period (130 → 161).

Direct check: 24% of established connections now relay through my own TURN – a quarter of connections genuinely need a relay, and now it’s mine, not the public one. Credential fetches succeed 100% of the time (202 fetches, 32 people).

Lessons

No iceServers in PeerJS doesn’t mean no relay – it means PeerJS’s shared public one. Find out how much of your traffic depends on it.
“Mostly works” isn’t a number. P2P failures self-heal, so a common problem looks like an edge case until you count it.
A meaningful fraction of users can’t connect directly and need a relay. If you didn’t set one up, you’re borrowing someone else’s.

The follow-up file

Closing the loop between an anomaly and a verified fix

It has been a few years since the last post. The reason is the most ordinary one I could give: a small human moved into the house, evenings stopped being my own, and writing took a back seat. The nights are getting easier now, and a little of the old energy is back.

I have been working on a small side project – an online tabletop platform for an old Hungarian card game called M.A.G.U.S. (maguskartya.app). A few lessons have come out of it that I want to write down before they fade. This is the first: the gap between “I shipped a fix” and “I know the fix worked”.

Sentry tells you that something crashed. PostHog does not. PostHog tells you that something happened, and lets you look at the pattern – how often, in what context, and to whom. So when a rare-by-design guard suddenly fires 171 times across 13 users, you notice. Then you fix the cause. Then comes the part nobody talks about: verifying that the fix actually worked. Sentry closes that loop for you. PostHog doesn’t. This is the file I keep to close it manually. I call it FOLLOWUPS.md.

The two tools, drawn cleanly

A quick line on the split, because the rest of this post leans on it. Sentry is an error-monitoring product: it catches crashes – uncaught exceptions, broken promises, things the user sees as “something went wrong”. When you ship a fix, the resolved error stays resolved; if it comes back, Sentry tells you. PostHog is a product-analytics tool (similar in role to Mixpanel or Amplitude): it tracks behaviour – the events you chose to instrument, the patterns you chose to watch. A signal in PostHog is almost always a rate: a thing that should be rare is happening more than rare, and the job is to find what changed. Fixing the cause is half the work. Going back days later to confirm the rate actually dropped is the other half, and PostHog will not raise its hand for you.

A concrete example

The same project has a netaction_anomaly event – a tracker I added to log any time the receiver’s authority check on an incoming action fails. The game is peer-to-peer, so each client validates the actions it receives from peers; if a guest sends an action that should only come from the host, the check trips and the event fires. It is the kind of guard I expect to fire once a year, on a real attack or a real bug.

I wired it as a PostHog event rather than a Sentry warning. Both would work – Sentry can capture warnings without crashes – but PostHog gives me the rate and shape of any anomaly across users, not just an issue page.

PostHog showed me it had fired 171 times across 13 distinct users over the past six weeks. The problem was not that the guard fired – a single fire on a real attack or real bug would have been normal. The problem was the volume: a once-a-year guard does not fire 171 times in six weeks. The breakdown was clean: same action type, same reason: "host_only", same sender_role: "spectator". Every guest joining a game was tripping the guard. Nothing was broken from the user’s point of view – the game played fine – but the anomaly stream was now drowning in false positives, and any real anomaly would be lost in the noise.

A single <code>netaction_anomaly</code> event in PostHog. The property breakdown is the diagnosis in one screen: <code>action_type: PARTICIPANT_UPDATE</code>, <code>reason: host_only</code>, <code>sender_role: spectator</code>. Every guest join produced the same shape.
One of the 171 events. Person column redacted.

The diagnosis took an evening. The host broadcasts a “participants updated” message to everyone in the room (including the brand-new guest who just joined), and then immediately starts a per-peer sync to bring that new guest up to speed. The order was wrong: when the guest received the broadcast, its local model of who is in this room was still empty, so the sender (the host) looked like a spectator to the receiver’s authority check. The guard fired. The payload was applied anyway – I run guards in track-only mode, but that is a different post – so gameplay was unaffected. The data stream was the only thing that knew.

The fix was a one-line swap: do the per-peer sync first, then broadcast. PeerJS – a thin WebRTC-data-channel library this project uses for peer connections – preserves per-connection message order, so the joining guest now receives sync → broadcast in the correct sequence, and the guard does not fire.

I committed the fix. And then I almost moved on.

The entry

Instead, I wrote one paragraph in a file called FOLLOWUPS.md. It looked like this (redacted):

			
## 1 - netaction_anomaly (PARTICIPANT_UPDATE / host_only / sender=spectator)
- Found via: PostHog query on <date>. 171 events across 13 users since the
  project started tracking. Fires on essentially every game session with
  a guest joining.
- Hypothesis: host-side join-message ordering race. <details>
- Fix applied: swapped call order in PeerService at <file:line>. Commit <hash>.
- Fix date: <date>
- Deploy date: <date>  (cutoff for verification, set conservatively to land
  after build + CDN propagation)
- Verify by: <date + 7 days>
- Verification query:
    SELECT count(), count(DISTINCT person_id)
    FROM events
    WHERE timestamp >= <deploy>
      AND event = 'netaction_anomaly'
      AND properties.action_type = 'PARTICIPANT_UPDATE'
      AND properties.reason = 'host_only'
      AND properties.sender_role = 'spectator';
- Expected outcome: 0 anomalies AND at least one fresh guest join in the
  window. If anomalies > 0, the ordering race is not the sole source.
- Resolution: pending

		

The same template, as a standalone file, is in the repo for this post.

The entry takes about ten minutes to write. The cost is small. The value is that on the verify-by date – which is on my calendar – I run the query and I know.

The sanity check – the part nobody tells you

Look at the “expected outcome” line. It has two clauses: zero anomalies AND at least one fresh guest join in the window. The second clause is the easy one to leave out.

If I run the query a week later and see zero anomalies, I might be looking at a working fix. Or I might be looking at a week where nobody used the affected feature. The data does not distinguish between “the fix worked” and “the bug had no opportunity to fire”. Without a paired traffic query, “zero” is meaningless.

Every entry in the file now has the sanity check baked in. If the success metric is “X dropped to zero”, there is always a second query asking “did the flow that produces X actually happen?” If both queries answer yes, the fix is verified. If only one does, I have a problem and a clue.

Why structured beats “I’ll remember”

Three weeks later, the original investigation is gone from my head. The PostHog dashboard looks slightly different – different time range, different aggregation, slightly different filters. I cannot re-derive what I was looking at on the day I shipped the fix. The entry is the only artifact that survives. It does not have to be smart; it has to be specific enough that future-me, opening the file cold, can run the verification query and know which answer means “fixed”.

This sounds obvious. It is. Yet it is easy to skip, because the cost of writing the entry is paid the day you ship – when you are tired and the change works on your machine and you want to move on – and the value is paid weeks later. You do not notice the value until the first time you open an entry from a month ago and save yourself an hour.

What it isn’t

This is not a test suite. It does not run on every commit. It does not prevent the bug from coming back; it just catches it if it does.

It is not alerting. Nothing pages me when an entry’s verify-by date passes. The discipline is mine: every Monday I look at the file and run anything that’s due.

It is not a runbook. The entry assumes I wrote it; another engineer reading it cold would be missing context. For a team of one, that is fine. For a team of more, the entry would need to be slightly longer.

It is paperwork. Ten minutes per fix. The win is the small but consistent number of times I open an entry, run the query, and find that what I shipped did not actually move the metric. Without the file, I would have called those fixes done.