Tilpasning av WordPress admin: Utviklerguiden 2026

Når du leverer en WordPress-side til en kunde, er standard kontrollpanel ofte overveldende. Det er fullt av oppsalgsvarsler, menyer kunden aldri skal bruke, og teknisk sjargong som skaper support-tickets i stedet for innholdsarbeid.

Et generisk dashbord sier at du installerte et tema. Et tilpasset dashbord sier at du bygde et arbeidsverktøy under rollene som faktisk logger inn.

Denne guiden er skrevet for utviklere som leverer til redaktører, shop managers og klientroller i Norge og EU. Vi går gjennom enqueue av admin-CSS og JS, opprydding av menyer, capability-sjekker, egne roller, innstillingssider, fargeskjema, innloggingssiden, isolering i must-use-plugin, og hvordan du unngår å ødelegge kjerne-skjermer. Offisiell referanse for enqueue og menybygging ligger på admin_enqueue_scripts og admin_menu.

#Hvorfor admin-tilpasning reduserer support

Etter overlevering av en WooCommerce-butikk med page builder ser klienten ofte førti menypunkter og bruker tre. Resten genererer spørsmål: «kan jeg klikke på Temaer?», «hva er ACF?», «hvorfor ser jeg WooCommerce > Status?».

På et redaksjonsoppsett med fire redaktører og én byråadministrator i Oslo falt «jeg har ødelagt noe»-mailene merkbart etter at Verktøy, Innstillinger og filredigerere ble fjernet for alle uten manage_options. Det handlet ikke om penere farger. Farlige stier forsvant fra synsfeltet til folk uten full tilgang.

Andre gevinst: onboarding. I stedet for en times «ikke klikk her» viser du én Support-side med dokumentasjon, kontakt og en kort publiseringsjekkliste. Det er white-label som produkt, ikke bare bytte av logo.

#Admin-tilpasning i must-use-plugin i stedet for functions.php

Ikke legg admin-tilpasning i functions.php på barne-temaet. Når kunden bytter skin, forsvinner menyregler, enqueue og capability-sjekker. Byråkode som skal overleve temabytte hører hjemme i en must-use-plugin under wp-content/mu-plugins/.

En typisk struktur:

wp-content/mu-plugins/
  wppoland-admin-ux.php          # bootstrap (laster katalog)
  wppoland-admin-ux/
    menu.php
    enqueue.php
    capabilities.php
    dashboard.php

Bootstrap-filen i rot av mu-plugins/ lastes automatisk. Den krever bare filene under mappen. Fordelen er at koden alltid kjører, uavhengig av aktive vanlige plugins, og at du kan versjonskontrollere hele mappen uten at noen kan deaktivere den i Plugins-skjermen.

<?php
/**
 * Plugin Name: WPPoland Admin UX
 * Description: Menyopprydding, enqueue og support-sider for klientroller.
 * Author: wppoland.com
 */

declare(strict_types=1);

if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

$dir = __DIR__ . '/wppoland-admin-ux';
require_once $dir . '/menu.php';
require_once $dir . '/enqueue.php';
require_once $dir . '/capabilities.php';
require_once $dir . '/dashboard.php';

Test alltid med en egen brukerkonto som har klientrollen (Editor, Shop Manager, eller en custom rolle). Innlogging som Super Admin på staging skjuler bugene du nettopp «fikset» for kunden.

Hvis prosjektet allerede har en byrå-plugin med Composer-autoloading, kan mu-plugin-bootstrap bare kalle inn den pakken. Poenget er det samme: admin-UX skal ikke dø når et Elementor-child-tema byttes ut under en redesign.

Hold filene små. Én fil for meny, én for enqueue, én for blokkering. Når en senere utvikler skal finne «hvorfor forsvant ACF-menyen», skal de ikke grave i en 800-linjers functions.php.

#Hva skiller en must-use-plugin fra en vanlig plugin

Håndboken for avansert administrasjon lister forskjellene, og flere av dem påvirker hvordan admin-koden skal skrives:

• Must-use-plugins er aktive på alle nettsteder i installasjonen og kan ikke deaktiveres fra wp-admin.
• PHP laster dem i alfabetisk rekkefølge, før vanlige plugins.
• Filer i undermapper lastes ikke automatisk. Derfor trenger strukturen over en bootstrap-fil i roten.
• De vises ikke i standardlisten på Plugins-skjermen, men i en egen Must-Use-liste som bare brukere med tilgang til Plugins ser.
• De dukker ikke opp i oppdateringsvarsler, så du må selv følge med på nye versjoner.
• Aktiveringshooks kjøres ikke for plugins i mu-plugins-mappen.

Det siste punktet er det som oftest overrasker. Kode som en vanlig plugin ville lagt i register_activation_hook, for eksempel opprettelse av roller, må i en must-use-plugin ligge bak en egen versjonssjekk. Neste seksjon viser mønsteret.

#Hvordan sjekke capabilities før du endrer admin-menyen

remove_menu_page og add_menu_page er synlighets-API-er. De erstatter ikke tilgangskontroll. En bruker som kjenner URL-en kan fortsatt åpne tools.php eller options-general.php hvis capability tillater det.

Regler som holder i produksjon:

1. Sjekk current_user_can( 'manage_options' ) (eller en mer spesifikk capability) før du skjuler menyer for klientroller.
2. Skjul aldri menyer for den som skal feilsøke. Administrator uten synlig meny koster mer tid enn den sparer.
3. Når du virkelig skal blokkere, bruk admin_init eller map_meta_cap og returner wp_die() eller en redirect med forklaring, ikke bare CSS display: none.

For redaksjoner som deler innlogging mellom frilansskribenter og faste redaktører, er det verd å lage en egen rolle med edit_posts og upload_files, uten install_plugins og edit_themes. Da blir menyoppryddingen en speiling av den rollen, ikke en lang liste med unntak på bruker-ID. get_role( 'editor' )->remove_cap( '...' ) hører hjemme i en engangs-migreringsrutine eller CLI-kommando, ikke i en request-hook som kjører på hver admin-side.

/**
 * Blokker direkte URL-tilgang til Verktøy for ikke-administratorer.
 */
function wppoland_block_tools_screen(): void {
	if ( ! is_admin() || wp_doing_ajax() ) {
		return;
	}

	if ( current_user_can( 'manage_options' ) ) {
		return;
	}

	$screen = function_exists( 'get_current_screen' ) ? get_current_screen() : null;
	if ( ! $screen || 'tools' !== $screen->id ) {
		return;
	}

	wp_die(
		esc_html__( 'Du har ikke tilgang til denne skjermen.', 'wppoland-admin-ux' ),
		esc_html__( 'Tilgang nektet', 'wppoland-admin-ux' ),
		[ 'response' => 403 ]
	);
}
add_action( 'current_screen', 'wppoland_block_tools_screen' );

Capability-navn er kontrakten. Brukerne endrer ID, men «Shop Manager» beholder manage_woocommerce. Bygg regler rundt capabilities, ikke rundt bruker-ID 12.

#Egen klientrolle med add_role og map_meta_cap

Roller lagres i databasen, ikke i koden. Referansen for add_role sier at funksjonen avslutter og returnerer null hvis rollen allerede finnes. En endring i capability-listen får derfor ingen effekt før rollen fjernes og legges til på nytt. Uten en versjonssjekk ville det skjedd på hver forespørsel, og siden must-use-plugins ikke har aktiveringshook, er en lagret versjonsverdi den enkleste vakten.

function wppoland_register_client_role(): void {
	if ( '2' === get_option( 'wppoland_roles_version' ) ) {
		return;
	}

	remove_role( 'client_manager' );
	add_role(
		'client_manager',
		'Klientredaktør',
		[
			'read'                 => true,
			'edit_posts'           => true,
			'edit_published_posts' => true,
			'publish_posts'        => true,
			'delete_posts'         => true,
			'edit_pages'           => true,
			'edit_published_pages' => true,
			'edit_others_pages'    => true,
			'publish_pages'        => true,
			'upload_files'         => true,
			'moderate_comments'    => true,
		]
	);

	update_option( 'wppoland_roles_version', '2' );
}
add_action( 'init', 'wppoland_register_client_role' );

Capabilities som ikke står i listen, har rollen ikke. Det er tryggere enn å sette manage_options => false eksplisitt, fordi en glemt nøkkel da ikke åpner noe. Når listen endres, øker du versjonsverdien.

Noen sider skal kunden ikke kunne redigere selv om rollen ellers har edit_others_pages, typisk forsiden. Filteret map_meta_cap oversetter meta-capabilities som edit_post til primitive capabilities, og der kan du legge til do_not_allow for én bestemt side:

function wppoland_protect_front_page( array $caps, string $cap, int $user_id, array $args ): array {
	if ( ! in_array( $cap, [ 'edit_post', 'delete_post' ], true ) || empty( $args[0] ) ) {
		return $caps;
	}

	$front_page = (int) get_option( 'page_on_front' );

	if ( $front_page && (int) $args[0] === $front_page && ! user_can( $user_id, 'manage_options' ) ) {
		$caps[] = 'do_not_allow';
	}

	return $caps;
}
add_filter( 'map_meta_cap', 'wppoland_protect_front_page', 10, 4 );

Fordelen fremfor å skjule Rediger-lenken er at regelen gjelder overalt: i listen over sider, i blokkeditoren, i REST API og i hurtigredigering.

#Hvordan rydde opp i WordPress admin-menyen for klienter

Første synlige steg er remove_menu_page på admin_menu med sen prioritet, slik at plugins har registrert sine menyer før du fjerner dem. Dokumentasjonen for hooken er admin_menu.

/**
 * Rydd opp i admin-menyen for ikke-administratorer.
 */
function wppoland_clean_admin_menu(): void {
	if ( current_user_can( 'manage_options' ) ) {
		return;
	}

	remove_menu_page( 'tools.php' );
	remove_menu_page( 'options-general.php' );
	remove_menu_page( 'edit-comments.php' );
	remove_menu_page( 'edit.php?post_type=acf-field-group' );

	remove_submenu_page( 'themes.php', 'theme-editor.php' );
	remove_submenu_page( 'plugins.php', 'plugin-editor.php' );
}
add_action( 'admin_menu', 'wppoland_clean_admin_menu', 999 );

Advarsel: remove_menu_page skjuler bare lenken. Kombiner alltid med capability-blokk der stien er farlig (filredigerere, ACF-feltgrupper, plugin-installasjon).

For WooCommerce-butikker er det vanlig å la Shop Manager beholde Produkter, Ordrer og Kuponger, men fjerne Status, Utvidelser og Systemstatus-undermenyer. Det reduserer «kan jeg oppdatere denne pluginen?»-spørsmål uten å ta bort det som trengs for daglig drift.

Prioritet 999 er bevisst. Mange plugins registrerer menyer på admin_menu med standard prioritet 10. Hvis du kjører cleanup for tidlig, finnes ikke sluggen ennå, og remove_menu_page blir en no-op. Logg $GLOBALS['menu'] midlertidig på staging hvis du er usikker på hvilken slug et plugin bruker. ACF, Yoast og WooCommerce har alle ikke-opplagte stier.

Ikke fjern «Mediebibliotek» for redaktører som faktisk laster opp bilder. Det er en klassisk over-cleanup: panelet ser ryddig ut, og neste dag kommer ticket om at «Last opp» mangler. Rydd tekniske verktøy først, innholdsstier sist.

#Legge til egne meny-sider

Unngå tunge options-frameworks hvis du bare trenger én supportside. Kjerne-API-et er raskt og forutsigbart.

function wppoland_register_support_page(): void {
	add_menu_page(
		'Kundesupport',
		'Support',
		'edit_posts',
		'wppoland-support',
		'wppoland_render_support',
		'dashicons-sos',
		90
	);
}
add_action( 'admin_menu', 'wppoland_register_support_page' );

function wppoland_render_support(): void {
	if ( ! current_user_can( 'edit_posts' ) ) {
		wp_die( esc_html__( 'Tilgang nektet', 'wppoland-admin-ux' ) );
	}
	?>
	<div class="wrap">
		<h1><?php echo esc_html__( 'Trenger du hjelp?', 'wppoland-admin-ux' ); ?></h1>
		<div class="card">
			<h2><?php echo esc_html__( 'Kontakt utvikleren din', 'wppoland-admin-ux' ); ?></h2>
			<p>
				<?php echo esc_html__( 'E-post:', 'wppoland-admin-ux' ); ?>
				<a href="mailto:[email protected]">dev@wppoland.com</a>
			</p>
		</div>
	</div>
	<?php
}

Hold callbacken enkel: dokumentasjonslenker, publiseringsjekkliste, status for sikkerhetskopi hvis du allerede har den dataen. Ikke bygg et mini-CMS inne i Support-siden.

Bruk add_submenu_page under eksisterende CPT-menyer når støtten gjelder én innholdstype (for eksempel «Arrangementer > Hjelp»). Toppnivå-menyer bør reserveres for ting kunden åpner ukentlig. For mange toppnivå-ikoner gir samme kaos som du nettopp ryddet bort.

#Innstillingsside for kunden med Settings API

Når kunden skal endre noen få verdier selv, som telefonnummer til support eller lenker til sosiale medier, trenger de ikke tilgang til Innstillinger. En egen side bygget med Settings API gir dem bare de feltene. Ifølge håndboken tar WordPress seg da av lagringen av skjemadataene, legger til nonces og sender innsendingen via wp-admin/options.php, som har streng capability-sjekk.

function wppoland_register_client_settings(): void {
	register_setting(
		'wppoland_client',
		'wppoland_support_phone',
		[
			'type'              => 'string',
			'sanitize_callback' => 'sanitize_text_field',
			'default'           => '',
		]
	);

	add_settings_section( 'wppoland_contact', 'Kontakt', '__return_false', 'wppoland-client-settings' );

	add_settings_field(
		'wppoland_support_phone',
		'Telefon til support',
		'wppoland_render_phone_field',
		'wppoland-client-settings',
		'wppoland_contact'
	);
}
add_action( 'admin_init', 'wppoland_register_client_settings' );

function wppoland_render_phone_field(): void {
	printf(
		'<input type="text" name="wppoland_support_phone" value="%s" class="regular-text">',
		esc_attr( (string) get_option( 'wppoland_support_phone', '' ) )
	);
}

function wppoland_add_client_settings_page(): void {
	add_menu_page(
		'Innstillinger for nettstedet',
		'Nettsted',
		'edit_pages',
		'wppoland-client-settings',
		'wppoland_render_client_settings',
		'dashicons-admin-generic',
		91
	);
}
add_action( 'admin_menu', 'wppoland_add_client_settings_page' );

function wppoland_render_client_settings(): void {
	?>
	<div class="wrap">
		<h1><?php echo esc_html( get_admin_page_title() ); ?></h1>
		<?php settings_errors(); ?>
		<form action="options.php" method="post">
			<?php
			settings_fields( 'wppoland_client' );
			do_settings_sections( 'wppoland-client-settings' );
			submit_button();
			?>
		</form>
	</div>
	<?php
}

add_filter( 'option_page_capability_wppoland_client', fn() => 'edit_pages' );

Den siste linjen er den som ofte mangler. I kjernefilen wp-admin/options.php står det at alle registrerte innstillingsgrupper krever manage_options som standard, og at filteret option_page_capability_{$option_page} endrer kravet for én gruppe. Uten filteret ser redaktøren siden, fyller ut feltet og får en feilmelding ved lagring. Filteret åpner bare gruppen wppoland_client, ikke resten av Innstillinger.

#Enqueue av admin-CSS og JS (ikke admin_head)

admin_head med inline <style> fungerer i demoer, men skalerer dårlig: ingen versjonering, vanskelig cache-busting, og du blander presentasjon med PHP. Bruk admin_enqueue_scripts, last egne filer, og begrens til skjermer der de trengs. Hook-referanse: admin_enqueue_scripts.

function wppoland_admin_assets( string $hook_suffix ): void {
	// Begrens til egne sider og dashbord, ikke last på alle kjerne-skjermer.
	$allowed = [
		'index.php',
		'toplevel_page_wppoland-support',
	];

	if ( ! in_array( $hook_suffix, $allowed, true ) ) {
		return;
	}

	$base = plugin_dir_url( __FILE__ );
	$ver  = '2026.09.21';

	wp_enqueue_style(
		'wppoland-admin-ux',
		$base . 'assets/admin.css',
		[],
		$ver
	);

	wp_enqueue_script(
		'wppoland-admin-ux',
		$base . 'assets/admin.js',
		[ 'jquery' ],
		$ver,
		true
	);

	wp_localize_script(
		'wppoland-admin-ux',
		'wppolandAdminUx',
		[
			'ajaxUrl' => admin_url( 'admin-ajax.php' ),
			'nonce'   => wp_create_nonce( 'wppoland_admin_ux' ),
		]
	);
}
add_action( 'admin_enqueue_scripts', 'wppoland_admin_assets' );

$hook_suffix er nøkkelen til å ikke bryte kjerne-skjermer. En global CSS som skjuler .notice på alle admin-sider fjerner også WordPress-kjernevarsler om kritiske sikkerhetsoppdateringer. Begrens selektorer til egne wrappers (.wppoland-support-wrap) eller egne hook-suffixer.

For merkevarefarger i admin-baren: overstyr få, dokumenterte selektorer, og test både classic og block editor. Gutenberg laster egen UI; bred #wpadminbar { background } er greit, mens !important på .components-button er en oppskrift på ødelagt editor.

/* assets/admin.css: hold omfanget smalt */
#wpadminbar {
	background: #1f2937;
}

#toplevel_page_wppoland-support .wp-menu-image::before {
	color: #059669;
}

.wppoland-support-wrap .card {
	max-width: 40rem;
}

Når du trenger script bare på én skjerm, er wp_enqueue_script inne i admin_enqueue_scripts med tidlig return den sikreste modellen. Unngå wp_print_scripts direkte i callbacken til add_menu_page. Det bryter rekkefølgen på avhengigheter og gjør det vanskeligere å deaktivere scriptet senere.

Hvis admin.js snakker med REST, bruk wp_create_nonce( 'wp_rest' ) og wpApiSettings der det allerede finnes, eller lokaliser din egen nonce som i eksempelet over. Aldri stol på at «bare innloggede brukere» er nok uten nonce-sjekk på serveren.

#Eget fargeskjema for WordPress-admin med wp_admin_css_color

Fargene i sidemenyen og verktøylinjen styres av fargeskjemaet hver bruker velger i profilen sin. I stedet for å overstyre dem med !important kan du registrere et eget skjema med wp_admin_css_color. Funksjonen tar en unik nøkkel, et navn, URL til CSS-filen med skjemaet, en liste med farger som vises som forhåndsvisning i profilen, og valgfrie farger for SVG-ikoner (base, focus og current).

function wppoland_register_admin_scheme(): void {
	wp_admin_css_color(
		'wppoland',
		'WPPoland',
		plugin_dir_url( __FILE__ ) . 'assets/admin-colors.css',
		[ '#1f2937', '#059669', '#d1fae5', '#ffffff' ],
		[
			'base'    => '#d1d5db',
			'focus'   => '#ffffff',
			'current' => '#ffffff',
		]
	);
}
add_action( 'admin_init', 'wppoland_register_admin_scheme' );

Kjernen registrerer sine egne skjemaer på samme hook: register_admin_color_schemes er koblet til admin_init med prioritet 1 i wp-admin/includes/admin-filters.php. Valget lagres som brukeropsjonen admin_color, og admin får body-klassen admin-color- pluss nøkkelen, så du kan målrette egne regler mot akkurat ditt skjema.

Du kan tvinge skjemaet for alle med filteret get_user_option_admin_color, men da tar du fra brukerne valget. Noen velger et skjema fordi kontrasten passer synet deres. Et eget skjema som ett av valgene er en tryggere standard enn å låse alle til det.

#Vanlige feil ved tilpasning av WordPress-admin

Tre feil som går igjen i produksjon:

1. Global notice-hiding. .notice { display: none } fjerner både plugin-spam og kritiske kjernevarsler. Filtrer per plugin-klasse eller bruk admin_notices-callbacks med remove_action på kjente callbacks i stedet for blank hiding.
2. Fjerning av Plugins eller Oppdateringer for alle. Klientroller skal ikke installere plugins. Administrator må. Hvis du skjuler Oppdateringer for manage_options, mister du synlighet på sikkerhetsreleaser.
3. Omskriving av Settings API-skjermer. Ikke erstatt options-general.php med en egen «forenklet» side med mindre du også speiler alle nødvendige options og validering. En mangelfull kopi bryter permalenker, siteurl og språk.

Når du tilpasser block editor, bruk enqueue_block_editor_assets separat fra admin_enqueue_scripts, og last bare det editoren trenger. Bland aldri store jQuery-UI-pakker inn på post.php uten behov.

Et praktisk regresjonstest-oppsett: åpne Listevisning for innlegg, Gutenberg for en side, Mediebiblioteket, WooCommerce > Ordrer, og din Support-side, med både Administrator og Editor. Hvis én av disse skjermene mister knapper, notices eller tastaturnavigasjon, rull tilbake CSS før du leverer. «White-label» som bryter kjerne-UI er ikke ferdig arbeid.

#Tilpasning av verktøylinjen (toolbar)

Verktøylinjen er synlig på frontend for innloggede brukere. Den egner seg til hurtighandlinger som «Tøm cache», med nonce og capability, ikke bare en åpen GET-URL.

function wppoland_customize_toolbar( WP_Admin_Bar $wp_admin_bar ): void {
	$wp_admin_bar->remove_node( 'wp-logo' );

	if ( ! current_user_can( 'manage_options' ) ) {
		return;
	}

	$wp_admin_bar->add_node(
		[
			'id'    => 'wppoland-clear-cache',
			'title' => 'Tøm cache',
			'href'  => wp_nonce_url(
				admin_url( 'admin-post.php?action=wppoland_clear_cache' ),
				'wppoland_clear_cache'
			),
			'meta'  => [ 'title' => 'Tøm object cache' ],
		]
	);
}
add_action( 'admin_bar_menu', 'wppoland_customize_toolbar', 999 );

Håndter admin_post_wppoland_clear_cache med check_admin_referer og redirect tilbake. Uten nonce blir hurtigknappen et CSRF-mål. Skal verktøylinjen bort for enkelte roller på frontend, finnes det en egen guide til å skjule admin-linjen for ikke-administratorer.

#Hvordan tilpasse dashbord-widgeter og velkomstskjermen

Når kunden logger inn, lander de på Dashbordet. Standardwidgeter som WordPress-arrangementer og Hurtigutkast er sjelden nyttige. Erstatt dem med status kunden faktisk spør om: backup, oppetid, «sist publisert».

function wppoland_dashboard_widgets(): void {
	remove_meta_box( 'dashboard_primary', 'dashboard', 'side' );
	remove_meta_box( 'dashboard_quick_press', 'dashboard', 'side' );

	wp_add_dashboard_widget(
		'wppoland_status_widget',
		'Nettstedstatus',
		'wppoland_render_status_widget'
	);
}
add_action( 'wp_dashboard_setup', 'wppoland_dashboard_widgets' );

function wppoland_render_status_widget(): void {
	echo '<p><strong>WordPress-kjerne</strong>: sjekk Oppdateringer for status</p>';
	echo '<p><strong>Sikkerhetskopier</strong>: bekreft siste jobb i backup-pluginen</p>';
	echo '<p><a href="' . esc_url( admin_url( 'admin.php?page=wppoland-support' ) ) . '">Åpne support</a></p>';
}

Unngå å hardkode «Oppdatert» med grønn hake hvis du ikke leser faktisk versjon. En løgnende statuswidget er verre enn ingen widget.

Widget-callbacks bør være billige. Ikke kall eksterne API-er synkront i wp_dashboard_setup-renderen. Hvis du trenger trafikk-tall, cache resultatet i en transient og vis «sist hentet»: ellers blir dashbordet tregt akkurat når kunden logger inn for å «bare sjekke raskt». Kjernen gjør det samme selv.

#Hva standardwidgetene i dashbordet faktisk gjør

En vanlig begrunnelse for å fjerne standardwidgetene er ytelse. Kildekoden til wp-admin/includes/dashboard.php viser at gevinsten er liten:

• WordPress-arrangementer og nyheter (dashboard_primary) henter nyhetsstrømmen gjennom en bufret widget. Ferdig HTML lagres i en transient per språk, og når bufferen er tom, viser widgeten en lasteindikator og henter innholdet via AJAX i stedet for å holde igjen siden.
• Hurtigutkast (dashboard_quick_press) gjenbruker ett autoutkast per bruker, og ID-en lagres i brukeropsjonen dashboard_quick_press_last_post_id. Autoutkast eldre enn sju dager slettes av wp_delete_auto_drafts, som kjører på den planlagte hendelsen wp_scheduled_auto_draft_delete.
• Status for nettstedshelse (dashboard_site_health) leser et lagret resultat fra transienten health-check-site-status-result i stedet for å kjøre alle testene ved hver visning.

Argumentet for å fjerne dem er derfor fokus, ikke hastighet. Nettstedshelse bør du vurdere å beholde for administratorer, fordi den viser varsler om PHP-versjon og manglende moduler som ellers lett blir oversett.

#Tilpasse WordPress-innloggingssiden med logo og lenke

Innloggingssiden er det første kunden ser hver dag. Tre hooks i wp-login.php dekker det meste:

• login_enqueue_scripts (siden versjon 3.1) er hooken for stilark og script på innloggingssiden, på samme måte som admin_enqueue_scripts i wp-admin.
• login_headerurl styrer hvor logoen lenker. Standardverdien er wordpress.org.
• login_headertext (siden versjon 5.2) styrer lenketeksten til logoen. Det eldre filteret login_headertitle er utfaset fra 5.2, med begrunnelsen at title-attributtet på logoen ikke anbefales av hensyn til tilgjengelighet.

function wppoland_login_assets(): void {
	wp_enqueue_style(
		'wppoland-login',
		plugin_dir_url( __FILE__ ) . 'assets/login.css',
		[],
		'2026.10.14'
	);
}
add_action( 'login_enqueue_scripts', 'wppoland_login_assets' );

add_filter( 'login_headerurl', fn() => home_url( '/' ) );
add_filter( 'login_headertext', fn() => get_bloginfo( 'name' ) );

/* assets/login.css */
.login h1 a {
	background-image: url("../img/kunde-logo.svg");
	background-size: contain;
	width: 100%;
	height: 80px;
}

Lenketeksten leses av skjermlesere, så navnet på nettstedet er et bedre valg enn en tom streng. Test siden med tofaktor- eller SSO-plugin aktiv, fordi slike plugins legger til egne felt som en for stram CSS kan skyve ut av skjermen. Flere teknikker for selve skjemaet finner du i guiden om å tilpasse WordPress-innloggingen.

#Hva sjekke før overlevering av tilpasset WordPress-admin

Kjør gjennom dette med en klientrolle-konto på staging:

1. Meny viser bare det som trengs for rollen; administrator ser fortsatt alt.
2. Direkte URL til Verktøy, Innstillinger eller filredigerer blokkeres der det er meningen.
3. Admin-CSS og JS lastes bare på tillatte $hook_suffix.
4. Block editor og Mediebiblioteket fungerer uten ødelagte knapper eller skjulte notices.
5. Toolbar-handlinger krever nonce og riktig capability.
6. Koden ligger i mu-plugin (eller dedikert byrå-plugin), ikke i temaet.
7. Innstillingssiden lagrer med klientrollen, ikke bare med administrator.
8. Innloggingslogoen lenker til nettstedet og har lesbar lenketekst.

Dokumenter i README for prosjektet hvilke menyer som er skjult per rolle, og hvilken mu-plugin som eier reglene. Neste utvikler (eller du om seks måneder) skal ikke måtte reverse-engineere admin_menu-callbacks for å finne ut hvorfor Innstillinger mangler for Shop Manager.

#Slik gjør du WordPress-admin til white-label på 90 dager

Denne tidsplanen ordner arbeidet med merkevare og sikring av administrasjonsområdet:

• Dag 1-30 (tilgangskontroll): registrer klientroller med minimale capabilities bak en versjonssjekk. Legg hooks for opprydding i menyen i en must-use-plugin, slik at ubrukte valg skjules for alle som ikke er administratorer. Bruk map_meta_cap for å hindre at begrensede roller redigerer eller sletter nøkkelsider (for eksempel forsiden eller kontaktsiden).
• Dag 31-60 (dashbord og innstillinger): bygg dashbordwidgeter som viser reell status og supportlenker. Bruk Settings API til en egen innstillingsside med validering, og åpne alternativgruppen for klientrollen med capability-filteret. Legg til snarveier i verktøylinjen beskyttet med nonce.
• Dag 61-90 (merkevare og innlogging): last admin-stiler via admin_enqueue_scripts, registrer et fargeskjema og brand innloggingssiden. Avslutt med overleveringssjekklisten over, testet med hver klientrolle.

#Hva er viktigst ved tilpasning av WordPress-admin

Tilpasning av admin-området er UX og tilgangskontroll, ikke kosmetikk. Enqueue via admin_enqueue_scripts, bygg og rydd menyer på admin_menu, sjekk capabilities før du skjuler eller blokkerer, isoler i must-use-plugin, og hold CSS og JS unna kjerne-skjermer du ikke eier.

Et ryddig adminområde avgjør hvor ofte kunden ringer for å spørre hvor noe ligger. Skal panelet tilpasses rollene som faktisk bruker det, se WordPress-utvikling og admin-tilpasning.