Project

Custom WordPress admin dashboard

Before the current custom CMS, this site’s operational brain lived inside WordPress: a curated admin layer on top of core wp-admin - custom landing pages, shortcuts, and role-aware surfaces that matched how I actually worked. It was a deliberate middle ground between stock WordPress and a full rewrite.

← Back to projects Contact about WordPress or CMS work

What it was

Stock wp-admin is powerful but generic. For day-to-day maintenance - content health, quick jumps to theme hooks, plugin hygiene, and internal utilities - I wanted a single dashboard that reflected my stack, not every possible WordPress install. The custom admin project wrapped that intent: still WordPress under the hood, but the first screen you saw was mine.

The landing experience replaces scattered menu hunting with a purpose-built overview.

The implementation stayed within supported extension points: admin menus, top-level and submenu pages, enqueued styles and scripts only where needed, and capability checks so clients or collaborators never saw tools they should not touch. Nothing relied on editing core files or fragile rewrites of wp-admin markup.

Screenshots on this page load from img/projects/wordpress/custom_admin_dashboard/ - the same images fill the gallery below. Drop PNG or WebP files there to refresh the story without touching PHP.

Features and UX

The dashboard prioritised at-a-glance signals: what needs attention, where to click next, and links to the custom plugins (like the task manager) that extended the same installation. Widget-style blocks and clear typography reduced noise compared with the default “everything is a box” feel of some admin themes.

Structured blocks keep frequent actions one click away from the home admin screen.

Role separation mattered: administrators saw operational controls; editors saw content-centric shortcuts. That mirrored the later capability model in the standalone CMS - only the hosting runtime changed.

  • Custom top-level admin pages and ordered submenus
  • Role- and capability-gated sections
  • Scoped CSS/JS so the rest of wp-admin stays stable
  • Deep links into plugins, tools, and theme-related screens
  • Room to embed status snippets (updates, queues, notices)

Technical approach

Technically this is classic WordPress plugin territory: bootstrap on plugins_loaded or admin_menu, add_menu_page / add_submenu_page, and wp_enqueue_style / wp_enqueue_script with version hashes for cache busting. Data shown on the dashboard came from existing tables - options, post counts, transients - not a parallel schema.

Where AJAX or REST helped, endpoints stayed namespaced and nonce-protected. The goal was always “upgrade-safe”: a WordPress core update should not silently break the dashboard because we avoided monkey-patching private hooks.

add_action('admin_menu', function () {
    add_menu_page(
        'Dashboard', 'My Dashboard',
        'manage_options', 'my-dash-home',
        'my_admin_dashboard_render', 'dashicons-layout', 2
    );
});
Registration through the public admin API keeps behaviour predictable across updates.

Toward a standalone CMS

WordPress was the right host for a long time: mature ecosystem, familiar UI, and fast iteration. Over time, the product vision outgrew “everything in wp-content”: tighter control over auth flows, migrations, multi-app admin, and theme packaging motivated a from-scratch CMS - this site now runs on that stack.

Visual lineage: bespoke admin inside WordPress before the dedicated CMS project.

The custom admin dashboard still matters as history: it proves product thinking in constraints, and many patterns - capability checks, separation of admin “home” vs raw screens, pragmatic PHP - carried straight into the new system. If you run WordPress today, the same approach still applies.

Maintainability

Because the code respected public APIs, maintenance was mostly “keep hooks current” and refresh asset versions - not chasing private WordPress internals. Documentation lived in short README sections so returning after months away did not require archaeology.

Keeping scope API-driven pays off every core update cycle.

If you adopt something similar, treat the dashboard as a product: version it, test on staging against beta WordPress when you can, and keep third-party plugin interactions explicit so surprises are rare.

Screenshots