Custom WordPress admin-dashboard

Hvad det var

Standard wp-admin er kraftfuldt men generisk. Til vedligehold—indholdstilstand, hurtige spring til tema-hooks, plugin-hygiejne og interne værktøjer—ville jeg have ét dashboard der afspejlede min stack, ikke alle mulige WordPress-installationer. Custom admin-projektet indkapslede det: stadig WordPress under motorhjelmen, men den første skærm du så var min.

Implementeringen holdt sig til understøttede udvidelsespunkter: admin-menuer, top- og under-sider, styles og scripts kun hvor nødvendigt, og capability-tjek så kunder eller samarbejdspartnere aldrig så værktøjer de ikke skulle. Intet byggede på redigerede core-filer eller skrøbelige omskrivninger af wp-admin-markup.

Skærmbillederne på siden hentes fra img/projects/wordpress/custom_admin_dashboard/—samme filer som galleriet nederst. Tilføj PNG eller WebP dér for at opdatere historien uden at ændre PHP.

Funktioner og UX

Dashboardet prioriterede signaler på ét øjekast: hvad der kræver handling, hvad næste klik er, og links til egne plugins (fx task manager) på samme installation. Widget-lignende blokke og tydelig typografi reducerede støj i forhold til standard “alt er en kasse”-oplevelse.

Rolle-adskillelse betød noget: administratorer så driftskontroller, redaktører så indholds-fokuserede genveje. Det spejlede senere capability-modellen i det selvstændige CMS—kun runtime skiftede.

• Egne topniveau-admin-sider og ordnede undermenuer
• Afsnit styret af roller og capabilities
• Indrammet CSS/JS så resten af wp-admin forbliver stabilt
• Dyk ned i plugins, værktøjer og tema-relaterede skærme
• Plads til status (opdateringer, køer, beskeder)

Teknisk tilgang

Det er klassisk WordPress-plugin-territorium: bootstrap på plugins_loaded eller admin_menu, add_menu_page / add_submenu_page, og wp_enqueue_style / wp_enqueue_script med versions-hash til cache. Data på dashboardet kom fra eksisterende tabeller—options, post-counts, transients—ikke et parallelt skema.

Hvor AJAX eller REST hjalp, blev endpoints navnerums-sikrede og nonce-beskyttede. Målet var altid “opgraderings-sikkert”: en WordPress-core-opdatering må ikke ødelægge dashboardet stille, fordi vi undgik private hooks og monkey-patching.

add_action('admin_menu', function () {
    add_menu_page(
        'Dashboard', 'Mit dashboard',
        'manage_options', 'my-dash-home',
        'my_admin_dashboard_render', 'dashicons-layout', 2
    );
});

Mod et selvstændigt CMS

WordPress var den rigtige vært i lang tid: modent økosystem, kendt UI og hurtig iteration. Over tid voksede produktvisionen ud af “alt i wp-content”: strammere styring af auth, migrationer, multi-app admin og tema-pakning motiverede et CMS fra bunden—denne side kører nu på den stack.

Custom admin-dashboardet tæller stadig som historie: det viser produkt-tænkning under begrænsninger, og mange mønstre—capabilities, adskillelse af admin-“hjem” og rå skærme, pragmatisk PHP—gik direkte videre. Kører du WordPress i dag, gælder samme tilgang stadig.

Vedligehold

Fordi koden respekterede offentlige API’er, var vedligehold mest “hold hooks aktuelle” og forny asset-versioner—ikke jagt på private WordPress-internals. Dokumentation i korte README-afsnit så man kunne vende tilbage uden arkæologi.

Hvis du bygger noget lignende, behandl dashboardet som et produkt: versionsstyring, test på staging mod beta-WordPress når du kan, og eksplicitte integrationer til tredjeparts-plugins så overraskelser er sjældne.