Coming from WordPress: where is everything in EmDash?

Your EmDash site is up and running, set up as in Kevin's getting-started article. Now you open /_emdash/admin, and your eyes go straight to the sidebar looking for "Appearance" or "Tools". Neither is there. So where is everything?

That's what this article is about. I'm putting the WordPress admin and the EmDash admin side by side, menu by menu, from the point of view of the people who look after content and run the site, not the developers. After that comes a short glossary of the terms WordPress didn't teach you. What everyday work in the editor looks like in detail is in my article The EmDash admin day to day, and I'd rather point you there than repeat it. I looked up every menu entry in the EmDash 1.1.0 source code.

The sidebar in four groups

Before we compare entry by entry, it's worth looking at how the sidebar is built. Dashboard and Calendar sit at the top. Below that, EmDash sorts everything into groups. Content has one entry per content type plus Media. Manage collects comments, menus, redirects, widgets, sections, taxonomies and bylines. And Admin holds whatever affects the whole site, such as content types, users, plugins, import and settings. If a plugin brings pages of its own, they get a fourth group called Plugins.

Just like in WordPress, what you see depends on your role. The Manage group shows up from the Editor role, while Redirects and the whole Admin group are for admins only. So if an entry seems to be missing, your role is often the reason.

The names under Content and the taxonomy names come from your template, not from EmDash. With the blog template you'll see Posts, Pages, Categories and Tags, but your site may well use others. You can rename them at any time, and the day-to-day article covers what to watch out for when you do.

The map: from WordPress to EmDash

With that layout in mind, the actual map is short. WordPress is on the left, the way to the same thing in EmDash 1.1.0 in the middle.

Most rows explain themselves. A few deserve a second look, so let's go through those.

Posts and pages are content types

In WordPress, posts and pages are two built-in things, and everything else gets added as a custom post type. In EmDash, both are ordinary content types that your template created. A type of your own for case studies or events sits right next to them on equal terms, and Kevin's getting-started article shows how to create one.

Each content type has its own list with its own Trash. Under Admin → Content Types you'll also find two things that live globally under Settings in WordPress. The URL pattern replaces permalinks there, and whether comments are allowed and how strictly they're moderated is set per content type too.

There's one difference worth knowing on day one. In WordPress, clicking Update on a published post puts the change live straight away. In EmDash it goes into a draft first, and your readers keep seeing the old version until you choose Publish changes. By the way, the Calendar shows you what goes out when. WordPress doesn't ship an overview like that.

Where the Appearance menu went

So content is easy to find your way around. The Appearance menu is the bigger shift, because there's no theme you switch in the admin. What the site looks like is Astro files in the project, and changing it means changing code and deploying again.

What you touched under Appearance as an editor is still there, just spread over four places.

• Menus live under Manage, nested the way you're used to.
• Widgets are still called widgets. The template decides which widget areas exist; the blog template has a sidebar and a footer. You can drag in your own text, a menu, or ready-made components such as recent posts, categories or a search box.
• Sections are what you know from WordPress as patterns or reusable blocks. In the editor, type /section (or /pattern) to insert one. EmDash copies it into the post, so later edits to the original don't reach the copies.
• Title, tagline, logo and favicon, the things you set under Appearance → Customize in WordPress, are under Settings → General.

One thing applies to all four. A menu or a widget area only shows up on the site if the template renders it. Create a new widget area and nothing changes publicly until someone adds it to the template.

Plugins, users and tools

That brings us to the part that only admins usually see in WordPress.

Plugins lists the installed plugins, which you can disable and configure there. New ones come from the Registry. That menu entry only exists on sites with the plugin sandbox, though, and on Cloudflare the sandbox needs the paid Workers plan. There's no button for uploading a ZIP file. Plugins with full access come into the project through code and need a deployment, so that's a job for whoever looks after the site's code. Kevin tested what the sandbox protects and what it doesn't in his plugin sandbox article.

You'll recognise the roles under Users straight away: Subscriber, Contributor, Author, Editor and Admin. You bring new people in with Invite User, and they sign in with a passkey afterwards, because there are no passwords. What's new is that the name above a post isn't tied to the user account. That's what bylines are for, more on those in the glossary.

WordPress's Tools split into two places in EmDash. Import opens "Import from WordPress", where you upload the WordPress export file or connect through the EmDash Exporter plugin, which brings over more. Kevin tried out what arrives and what doesn't in his ACF import article. The counterpart to Export is Settings → Transfer. It packs the whole site, media included, into a package you can load into an empty EmDash installation. User accounts and credentials aren't in it, but author and commenter email addresses are, so treat the file like a database backup. For backups as such, there's Backups right next to it.

What isn't there

So far nearly every WordPress menu has found its counterpart. Three things you'll look for in vain, though. Pages can't be placed under other pages, so there's no page tree like in WordPress; you can only express a page structure through nested menus. There's no page builder like Elementor either, and that's deliberate. With a blocks field, developers can let you assemble pages from fixed building blocks, but you can't design freely the way Elementor lets you. And there's no counterpart to WooCommerce. Kevin's guide for agencies covers what that means for client projects in detail. Read it before you move a site with lots of subpages.

A short glossary

To finish, here are the terms you'll trip over in the admin and in the docs.

• Content type (collection): A kind of content with its own fields, such as Posts, Pages or case studies. In WordPress terms, a post type with ACF fields, minus the plugin. More in the collections docs.
• Portable Text: How EmDash stores rich text, as structured JSON rather than HTML. The template turns it into HTML; Kevin explains it in his getting-started article.
• Byline vs. user: A user is an account with a role and a login. A byline is the public profile shown on the post, and it can belong to a guest author without an account. How the two fit together is in the day-to-day article.
• Taxonomy: The umbrella term for categories and tags. Unlike in WordPress, you create your own taxonomies without code, using New Taxonomy on the categories page. More in the taxonomy docs.
• Section: A reusable block of content that the editor copies when you insert it. Reusable blocks imported from WordPress end up here. See the sections docs.
• Widget area: A named spot in the template, the sidebar for example, whose content you control from the admin. Change a widget and it changes everywhere the area appears. See the widget area docs.
• Seed: A file in the project that describes the starting state, meaning content types, menus and sample content. EmDash applies it exactly once, to an empty database. Why that matters is in the day-to-day article.
• Sandboxed vs. native plugin: A sandboxed plugin runs isolated, with only the permissions it declares up front, and you can install it from the admin. A native plugin runs with full access and comes in through code and a deployment.
• Registry: The catalogue of sandboxed plugins. You can also browse it without signing in at plugins.emdashcms.com.
• MCP: A built-in interface that lets AI assistants such as Claude or ChatGPT read and edit content with their user's permissions. According to the AI tools docs, you connect it with a token from Settings → API Tokens or through OAuth.
• Draft and revision: A draft is the not-yet-public version of an entry, even for a post that's already published. Revisions are saved states you can go back to with Restore without losing anything.

Conclusion

Back to the question from the start. Almost everything you used in the WordPress admin is in EmDash too, often under the same name. The differences lie less in the menus than in the ideas behind them. Design is code, not a menu entry. Posts and pages are content types like any other. Permalinks and comments are set per content type. And a change to a published post stays a draft until you publish it. Keep those four things in mind and you won't need the map for long. For what isn't there at all, Kevin's guide is worth a read before your next client project.