Every WordPress migration hits the same wall: the plugin list. Twenty-odd plugins, each doing something someone once needed. None of them will run on EmDash, because EmDash doesn't run PHP.
That's less scary than it sounds. Go through the list and most plugins fall into one of three buckets.
Bucket 1: you don't need it anymore
Caching, minification, security hardening, image optimization, staging. A lot of WordPress plugins exist to patch the platform. An Astro site on Cloudflare Workers already handles much of this, so cross these off first.
Bucket 2: it's just your site
Custom post types, field groups, a contact form, a related-posts box. On EmDash, these are collections, fields and Astro components. You build them into the site instead of installing them.
Bucket 3: it's a real plugin
For behavior that really is a plugin, EmDash has a plugin system. Plugins can react to content and media events, and add settings, API routes, admin pages, dashboard widgets and editor controls.
There are two formats, with different trust boundaries:
- Native plugins run inside your application with full access. Use these for your own code.
- Standard-format plugins can run in an isolated sandbox, granted only the capabilities they declare. On Cloudflare that sandbox needs Worker Loader, which is on Workers paid plans.
Pick the format based on trust, not convenience. Code you didn't write should run sandboxed.
Porting one
When you port a WordPress plugin, map its hooks first. A plugin that runs on save_post maps to an EmDash content hook. An admin options page becomes plugin settings. A REST endpoint becomes a plugin API route. Write the list of WordPress hooks the plugin uses, and you've basically written the port plan.
We'll walk through a real port, hook by hook, in an upcoming post.
