EmDash 1.0: twee sites omgezet in een dag

Vanochtend begon ik aan iets waarvan ik niet wist of het zou lukken. Vanavond draaien er twee complete websites op een CMS dat me maanden geleden nog binnen tien minuten buiten de deur zette.

Dit is het verhaal van die dag, plus een stappenplan voor wie het zelf wil proberen zonder een agent die het zware werk doet.

Het CMS dat me eruit gooide

Maanden terug probeerde ik de beta van EmDash. Ik kwam er niet in. De installatie ging via de terminal, en de veiligheidsvereisten waren zo streng opgezet dat ik mezelf vrijwel direct buitensloot. Passkeys die aan precies het juiste domein gebonden waren, een adminomgeving die niet wilde openen omdat de origin een tekentje afweek. Ik heb het toen weggelegd met het idee: mooi product, verkeerde timing.

Vandaag kreeg ik de mail van Cloudflare dat Birthday Week 2026 begint. En laat nu net in diezelfde week EmDash 1.0 uit zijn. Geen beta meer. Dat leek me een teken om het opnieuw te proberen, en deze keer met mijn agent ernaast.

Waar EmDash voor dient

EmDash is een CMS bovenop Astro. Je installeert het als onderdeel van je eigen website in plaats van als losstaand systeem waar je site in moet passen. Je krijgt een volledige beheeromgeving: collecties, velden, taxonomieën, media, zoeken, RSS, SEO, reacties, gebruikers.

Het verschil met WordPress zit in de opzet. WordPress is een applicatie waar jouw site een thema in is. EmDash is een bibliotheek in jouw site, waarbij de inhoud in een database zit en de weergave gewoon Astro-code is die jij bezit. Dat betekent: geen plugin-roulette, geen thema dat je opbouw dicteert, en pagina's die serverside gerenderd worden met de snelheid die daarbij hoort.

Twee dingen maakten het voor mij interessant. Het draait standaard op Cloudflare Workers, dus een site kost bijna niets om te hosten. En er zit een ingebouwde WordPress-migratie in die posts, pagina's, media en slugs overneemt.

Voor wie zit dit? Voor iedereen die schrijft en niet wil dat het publiceren zelf een project wordt. Voor ontwikkelaars die een echt CMS willen zonder de overhead van een headless dienst met abonnement. En voor mensen zoals ik, die hun eigen spullen willen bezitten.

Ronde een: jmvdpal.nl

Ik ben begonnen met mijn persoonlijke blog, want daar mag iets stuk. Dat bleek verstandig, want daar zat de hele leercurve.

Wat ik onderweg tegenkwam:

De passkey-koppeling die me in de beta al buitensloot, is nog steeds streng, en terecht. De adminomgeving hangt aan de exacte origin. Staat je site achter een reverse proxy die de header X-Forwarded-Proto niet doorgeeft, dan denkt de applicatie dat je op http zit, en dan werkt het inloggen niet. In Astro moet je bovendien je domeinen expliciet toestaan, als objecten met hostnaam en protocol, anders negeert hij die headers gewoon.

De mailrelay weigerde dienst omdat de hostnaam van de server geen punt bevatte. Nodemailer valt dan terug op een EHLO met een IP-adres, en veel relays antwoorden daarop met een 421. Hostnaam netjes gezet, en klaar.

De afbeeldingsverwerking wilde niet starten omdat de virtuele machine op een generiek CPU-profiel stond. De build slaagde wel, dus dat bleef eerst verborgen.

En de oude links. Dat was het echte werk. Een migratie verplaatst je inhoud, en laat elke bestaande link naar je oude site in het niets wijzen. Ik heb een generator gebouwd die de WordPress-export naast de nieuwe sitemap legt en daar een redirect-tabel van maakt, inclusief de mediabestanden en de oude niet-nette permalinks met een vraagteken erin. Met een dagelijkse controle erop, want zo'n tabel die stilletjes stukgaat is erger dan geen tabel.

Toen dat stond, viel me nog iets op: mijn medische disclaimer stond op elke pagina helemaal uitgeschreven in plaats van als uitklapbaar blok. De HTML-opschoner van EmDash stond details en summary niet toe, dus die werden er stilletjes uitgefilterd. Twee regels in de configuratie erbij, opnieuw bouwen, opgelost.

Ronde twee: deze site

Vanmiddag kwam blog.pcpal.nl aan de beurt, en dat ging in een fractie van de tijd. Dezelfde server, een tweede instantie ernaast op een eigen poort, met een eigen service en een eigen vhost.

De belangrijkste beslissing: ik heb het niet in één keer omgezet. Deze site stond live en kreeg bezoekers, dus die mocht niet omvallen voor een experiment. We hebben de nieuwe omgeving eerst op een tijdelijk domein gezet, daar de migratie gedaan, de redirects gebouwd en alles nagelopen. Pas toen alles groen was, ging het echte domein om.

Dat is de winst van de ochtend. Ronde een was uitzoeken. Ronde twee was uitvoeren.

Zelf proberen, zonder agent

Je hebt hier geen AI voor nodig. Dit is wat je doet als je het met de hand wilt testen.

1. Zet een project neer.

npm create emdash@latest mijn-site
cd mijn-site

Je kiest een sjabloon (blog, starter, marketing, portfolio) en een platform. Cloudflare is de standaard en de goedkoopste route. Kies node als je op je eigen server wilt draaien.

2. Start hem.

npm run dev

De beheeromgeving staat op http://localhost:4321/_emdash/admin. Op localhost mag je zonder token naar binnen, dus hier kun je vrij rondkijken. Maak je eerste account aan.

3. Kijk rond voor je iets belangrijks doet.

Klik de collecties door, maak een testpost, bekijk hoe die op de voorkant verschijnt. Het schema staat in seed/seed.json, de weergave in src/pages/. Dat zijn gewone bestanden die je zelf mag aanpassen.

4. Haal je WordPress binnen.

In het beheerpaneel zit een importoptie voor WordPress. Je plakt de URL van je oude site erin en hij loopt je door de stappen: welke berichttypes naar welke collectie, of hij de slugs moet behouden, en wat er met de media moet gebeuren. Werkt dat niet, exporteer dan een WXR-bestand uit WordPress (Gereedschap, Exporteren) en upload dat.

Doe dit op een testomgeving of een tijdelijk domein. Niet op je live site.

5. Zet je domein goed voor je publiceert.

Zet EMDASH_SITE_URL op het uiteindelijke domein en zet datzelfde domein in security.allowedDomains in astro.config.mjs, als object met hostname en protocol. Verander je dit later, dan vervallen je passkeys en moet je opnieuw inloggen via een magic link. Zet het tijdelijke en het definitieve domein er allebei alvast in, dan kost de overstap je niets.

6. Regel je oude links.

Je oude permalinks (/mijn-artikel/) komen niet overeen met de nieuwe (/posts/mijn-artikel). Zonder redirects verlies je je vindbaarheid en elke link die iemand ooit ergens heeft neergezet. Controleer dit met een simpele test: pak tien oude URL's uit Google, roep ze aan, en kijk of je een 301 krijgt naar een pagina die bestaat.

7. Pas daarna het domein omzetten.

Waar je over struikelt

Een paar dingen die me tijd kostten en die jou dat niet hoeven te kosten.

• Zet je een redirect-tabel in nginx, houd de map_hash-instellingen dan in een apart bestand dat eerder wordt ingelezen. Staan ze in het gegenereerde bestand, dan noemt nginx ze een duplicaat, faalt de test, en blijft je hele tabel buiten werking terwijl hij er compleet uitziet.
• Zet absolute_redirect off in je vhost, anders duwt nginx je bezoekers van https naar http.
• Draai je meerdere instanties op één machine, geef elk een eigen poort, een eigen service en eigen variabelenamen in je configuratie.
• Het zoeken werkte bij mij meteen na de import, zonder dat ik de index hoefde te herbouwen. Controleer het wel even, het scheelt je een verrassing.

Wat ik ervan vond

Er zit iets bevredigends in het omzetten van iets dat al jaren draait naar iets dat je zelf helemaal begrijpt. WordPress heeft me lang goed gediend en gaat nergens heen bij mijn klanten. Voor mijn eigen schrijfwerk wilde ik iets waar ik doorheen kan lezen.

Dat het product me maanden geleden nog buitensloot en nu in één dag twee sites draagt, zegt iets over hoe snel dit vakgebied beweegt. En over wat er mogelijk wordt wanneer je het uitzoekwerk kunt delegeren en zelf de beslissingen houdt.

Beide sites draaien. De links werken. Ik ben er blij mee.