WordPress tips og triks: tilpass admin og dashbordet

Å tilpasse WordPress handler ofte om små kodesnutter som gjør administrasjonen ryddigere – både for deg selv og for kundene du bygger nettsider for. Denne guiden samler fire klassiske triks: å gi menyvalget «Innlegg» et nytt navn, å styre hvor feil innlogging havner, å rydde i admin-menyen og å bytte ut standard-feeden i dashbordet. Alle snuttene er oppdatert til slik de bør skrives i dagens WordPress, og hvert begrep forklares første gang det dukker opp.

Før du begynner: versjon, backup og child-tema

Det viktigste før du rører kode er å kjøre nyeste WordPress og ha en fersk backup. Da unngår du at en skrivefeil i én linje slår ut hele siden. Den opprinnelige versjonen av disse tipsene ble skrevet for WordPress 3.3 i 2011 – i dag er WordPress 7.1.3 (oktober 2026) nyeste utgave, og prosjektet har gått tilbake til omtrent tre større utgivelser i året. Prinsippene bak snuttene er de samme, men flere detaljer har endret seg, og det er de vi retter opp her.

Hva er functions.php? Det er temaets «motorrom»: en PHP-fil i temamappen der du legger funksjoner som endrer hvordan WordPress oppfører seg. Koden under hører hjemme nettopp her – men ikke i hovedtemaets fil direkte. Oppdaterer temaet seg, overskrives filen, og tilpasningene dine forsvinner.

Bruk et child-tema eller en snippets-plugin. Et child-tema (undertema) er et lite tema som arver alt fra hovedtemaet, men lar deg legge egne endringer i en egen functions.php som overlever oppdateringer. Alternativet er en plugin som Code Snippets eller WPCode, der du limer inn kode i et trygt grensesnitt og kan slå hver snutt av og på som en bryter – uten FTP eller filredigering. Vil du heller finne et solid utgangstema, har vi samlet råd i guiden om WordPress-design for norske bloggere.

Ta backup først. Før du redigerer noen fil bør du sikre både databasen og filene. Går noe galt, er det forskjellen mellom en liten retting og en lang kveld. Se den egne gjennomgangen av hvordan du tar backup av innholdet i WordPress hvis du er usikker på fremgangsmåten.

Slik gir du «Innlegg» nytt navn i admin

Du kan gi WordPress-menyen «Innlegg» et annet navn – for eksempel «Artikler» – uten å endre selve funksjonaliteten. WordPress er født som et bloggverktøy, så ordet «Innlegg» passer ikke alltid på en firmaside eller en nyhetsportal. Løsningen er å fange opp WordPress sine egne tekstoversettelser gjennom filteret gettext og bytte ut akkurat de ordene du vil.

add_filter( 'gettext', 'dn_innlegg_til_artikler', 20, 3 );

function dn_innlegg_til_artikler( $oversatt, $tekst, $domene ) {
    // Rør bare WordPress sine egne kjernetekster
    if ( 'default' !== $domene ) {
        return $oversatt;
    }

    $erstatt = array(
        'Innlegg'               => 'Artikler',
        'Nytt innlegg'          => 'Ny artikkel',
        'Legg til nytt innlegg' => 'Legg til ny artikkel',
    );

    return $erstatt[ $oversatt ] ?? $oversatt;
}

Koden legges i functions.php i child-temaet ditt. Legg merke til tre ting som skiller denne versjonen fra den gamle oppskriften:

• Vi sjekker tekstdomenet. Testen 'default' !== $domene sørger for at vi bare rører WordPress sine kjernetekster, ikke tekster fra plugins eller temaer. Uten denne sjekken risikerer du å endre ord helt andre steder.
• Vi matcher hele strenger, ikke delstrenger. Den gamle oppskriften brukte str_ireplace på hver eneste tekst WordPress oversetter. Det er både tungt og farlig: ordet «Innlegg» finnes inni mange andre setninger, og du kan ende opp med rar tekst flere steder. Her bytter vi bare ut eksakte treff.
• Du kan legge til flere varianter. Admin bruker både «Innlegg», «Nytt innlegg» og lengre fraser, så listen gjør det enkelt å dekke alle.

Trenger du en helt egen innholdstype i stedet for bare et nytt navn, er en «custom post type» riktig vei – men for ren språkpuss er gettext-filteret raskest. Flere praktiske snutter i samme ånd finner du i artikkelen med flere tips og triks til deg som lager WordPress-design.

Slik sender du feil innlogging til din egen side

Med et par kodelinjer kan du både legge innloggingsskjemaet der du vil og bestemme hvor brukeren havner ved feil passord. Funksjonen wp_login_form() skriver ut et ferdig innloggingsskjema omtrent hvor som helst i temaet. Som standard logger den deg inn og sender deg tilbake dit du var. Vil du styre hvor en vellykket innlogging ender, legger du til en redirect-verdi – den må være en absolutt URL:

wp_login_form( array(
    'redirect' => home_url(), // absolutt URL - sender vellykket innlogging til forsiden
) );

Problemet er hva som skjer når noen skriver feil brukernavn eller passord: da kaster WordPress brukeren til sin egen standardside wp-login.php, og det tilpassede skjemaet ditt forsvinner. Kroken wp_login_failed lar deg i stedet sende brukeren tilbake til din egen side med en beskjed om at innloggingen mislyktes:

add_action( 'wp_login_failed', 'dn_feil_innlogging' );

function dn_feil_innlogging( $brukernavn ) {
    $referer = isset( $_SERVER['HTTP_REFERER'] )
        ? esc_url_raw( wp_unslash( $_SERVER['HTTP_REFERER'] ) )
        : '';

    // Bruk referer bare når den finnes og ikke peker på standard innloggingsside
    if ( $referer && ! strstr( $referer, 'wp-login' ) && ! strstr( $referer, 'wp-admin' ) ) {
        wp_safe_redirect( add_query_arg( 'login', 'failed', $referer ) );
        exit;
    }
}

Her er sikkerheten vesentlig forbedret i forhold til den opprinnelige oppskriften. Den gamle koden leste $_SERVER['HTTP_REFERER'] rått og brukte wp_redirect() uten å sjekke hvor adressen pekte. Det åpner for en såkalt «åpen redirect», der en angriper kan lure brukere videre til en fremmed side. I versjonen over gjør vi tre grep:

• wp_unslash() og esc_url_raw() rydder og renser adressen før vi bruker den.
• wp_safe_redirect() tillater bare omdirigering til ditt eget domene, slik at en manipulert referer ikke sender brukeren ut av siden.
• add_query_arg() legger på parameteren login=failed på en trygg måte, så temaet ditt kan lese den og vise en feilmelding.

Et viktig forbehold: HTTP_REFERER kan mangle helt (noen nettlesere og personverninnstillinger fjerner den), så ha alltid en reserveløsning. Vil du vise en pen feilmelding, kan du i tillegg bruke filteret login_errors og unngå å røpe om det var brukernavnet eller passordet som var feil.

Hva skjedde med «Lenker»-menyen – og hvordan du rydder admin-menyen

Menyvalget «Lenker» finnes ikke lenger som standard i WordPress, så den gamle snutten for å skjule det er stort sett overflødig. Lenkebehandleren (Link Manager) var en innebygd funksjon for å styre en «blogroll» – en liste med lenker til andre nettsteder. I WordPress 3.5, som kom i desember 2012, ble funksjonen skjult som standard: nye installasjoner uten lagrede lenker ser den ikke lenger. Selve koden ble liggende i kjernen en stund for ikke å ødelegge eldre sider, og de som vil ha funksjonen tilbake, kan installere plugin-en «Link Manager».

Det betyr at du sjelden trenger å skjule «Lenker» lenger – men prinsippet om å rydde i admin-menyen er fortsatt nyttig, særlig når du leverer en side til en kunde som ikke skal snuble i valg de aldri bruker. Funksjonen remove_menu_page() fjerner et toppnivåvalg fra menyen:

add_action( 'admin_menu', 'dn_rydd_admin_meny' );

function dn_rydd_admin_meny() {
    remove_menu_page( 'edit-comments.php' ); // skjul «Kommentarer»
    remove_menu_page( 'tools.php' );         // skjul «Verktøy»
    // remove_menu_page( 'link-manager.php' ); // bare aktuelt hvis «Lenker» er slått på igjen
}

Hvert menyvalg har en «slug» (en kort kjennestreng) du oppgir til funksjonen: edit-comments.php for Kommentarer, tools.php for Verktøy, edit.php for Innlegg og så videre. Er «Lenker» faktisk slått på igjen hos deg, fjerner link-manager.php den. Vær varsom: å skjule et menyvalg fjerner bare snarveien, ikke rettighetene – en bruker som kjenner adressen, kan fortsatt nå siden direkte. Skal tilgangen virkelig stenges, må du styre brukerroller og rettigheter. Vil du gå lenger i å forenkle baksiden for kunder, har vi en egen guide til å tilpasse dashbordet i WordPress for kundene dine.

Slik bytter du ut standard-feeden i WordPress-dashbordet

Du kan fjerne WordPress sine egne dashbord-widgets og sette inn din egen RSS-feed i stedet. Når en kunde logger inn, møtes de ofte av nyheter fra WordPress-prosjektet som de ikke har noe forhold til. Da er det ryddigere å vise din egen siste-nytt-liste – eller en relevant nyhetskilde – øverst i dashbordet.

Også her er oppskriften modernisert. Den gamle koden brukte unset() rett i den globale variabelen $wp_meta_boxes og pekte på widgets som ikke lenger finnes (for eksempel «dashboard_plugins» og «dashboard_secondary» er borte fra kjernen). Den anbefalte måten i dag er funksjonen remove_meta_box() med gjeldende widget-ID-er, kombinert med wp_add_dashboard_widget() for å legge til din egen:

add_action( 'wp_dashboard_setup', 'dn_tilpass_dashbord' );

function dn_tilpass_dashbord() {
    // Fjern standard-widgets
    remove_meta_box( 'dashboard_primary', 'dashboard', 'side' );     // WordPress-nyheter
    remove_meta_box( 'dashboard_quick_press', 'dashboard', 'side' ); // Hurtigutkast
    remove_meta_box( 'dashboard_activity', 'dashboard', 'normal' );  // Aktivitet

    // Legg til din egen RSS-widget
    wp_add_dashboard_widget( 'dn_egen_feed', 'Siste fra bloggen', 'dn_egen_feed_utskrift' );
}

function dn_egen_feed_utskrift() {
    echo '<div class="rss-widget">';
    wp_widget_rss_output( array(
        'url'          => 'https://eksempel.no/feed/',
        'items'        => 3,
        'show_summary' => 1,
        'show_author'  => 0,
        'show_date'    => 1,
    ) );
    echo '</div>';
}

De sentrale ID-ene i dagens WordPress er dashboard_primary (WordPress-nyheter og arrangementer), dashboard_quick_press (Hurtigutkast), dashboard_activity (Aktivitet med siste kommentarer og publiserte innlegg) og dashboard_right_now («Et overblikk»). Bytt ut https://eksempel.no/feed/ med adressen til din egen eller en annen offentlig RSS-feed, og juster hvor mange saker som vises med items. Funksjonen wp_widget_rss_output() henter og formaterer feeden for deg, så du slipper å skrive egen kode for å lese RSS.

Vanlige feil når du tilpasser WordPress

De fleste problemene med egen kode skyldes noen få gjengangere. Unngår du disse, slipper du de klassiske «hvit skjerm»-krisene:

• Du redigerer hovedtemaet direkte. Neste temaoppdatering sletter alt. Bruk child-tema eller en snippets-plugin.
• Du har ingen backup. Én manglende semikolon kan ta ned hele siden. Ta backup før du starter, og rediger gjerne via FTP/filbehandler slik at du kan angre raskt.
• Du gjør globale tekst-erstatninger. str_ireplace på alt WordPress oversetter gir uønskede treff. Match eksakte strenger og sjekk tekstdomenet.
• Du stoler på HTTP_REFERER. Den kan mangle eller forfalskes. Rens den, bruk wp_safe_redirect(), og ha en reserve-URL.
• Du tror skjult = stengt. Å fjerne et menyvalg hindrer ikke tilgang via direkte adresse. Vil du styre tilgang, bruk brukerroller.
• Du kopierer gammel kode ukritisk. Snutter fra 2011 kan peke på funksjoner og widgets som er endret eller fjernet. Sjekk alltid mot dagens dokumentasjon.

Sikkerhet og personvern når du rører admin

Egne innloggings- og admin-tilpasninger bør alltid vurderes med sikkerhet i bakhodet. Et tilpasset innloggingsskjema på forsiden gjør det enklere for både ekte brukere og for roboter som prøver passord i stor skala. Kombiner derfor triksene over med fornuftige tiltak: begrens antall innloggingsforsøk, bruk sterke passord og gjerne tofaktorpålogging, og logg mislykkede forsøk i stedet for å avsløre detaljer i feilmeldingen. Viser du en RSS-feed i dashbordet, husk at den hentes fra en ekstern kilde – bruk en adresse du stoler på. En bredere gjennomgang av tiltak finner du i guiden om hva du bør gjøre for å beskytte WordPress-siden mot angrep.

Hvem passer disse triksene for?

Triksene passer best for deg som bygger eller drifter WordPress-sider for andre, eller som vil ha en ryddigere egen baksiden. Jobber du for kunder, gjør navnebytte, menyrydding og en egen dashbord-feed baksiden mer forståelig og mindre skremmende. Er du nybegynner, kan du gjerne starte med en snippets-plugin i stedet for å redigere filer – da er terskelen lav og angrefristen kort. Vil du heller se hvilke utvidelser som løser lignende behov uten kode, har vi en oppdatert gjennomgang i artikkelen om WordPress-plugins og hva du bør bruke i dag.

Vanlige spørsmål (FAQ)

Hvor legger jeg denne koden i WordPress?

I functions.php i et child-tema, eller i en kodesnutt-plugin som Code Snippets eller WPCode. Legg den aldri i hovedtemaets functions.php direkte, for da forsvinner den ved neste temaoppdatering.

Hvorfor ser jeg ikke «Lenker»-menyen jeg skal fjerne?

Fordi den ble skjult som standard i WordPress 3.5 (desember 2012). Nye installasjoner viser den ikke, så snutten for å fjerne den er som regel unødvendig med mindre funksjonen er slått på igjen via en plugin.

Er det trygt å endre «Innlegg» til «Artikler»?

Ja. gettext-filteret endrer bare teksten som vises, ikke funksjonaliteten eller dataene. Så lenge du matcher eksakte strenger og sjekker tekstdomenet «default», påvirkes ingen andre deler av siden.

Hva er forskjellen på wp_redirect() og wp_safe_redirect()?

wp_redirect() sender brukeren til en hvilken som helst adresse, mens wp_safe_redirect() bare tillater adresser på ditt eget domene. Ved innlogging bør du alltid bruke den trygge varianten for å unngå åpne redirects.

Hvilken WordPress-versjon gjelder dette for?

Snuttene er oppdatert til dagens WordPress (7.1.3, oktober 2026) og fungerer på alle moderne versjoner. Kjør alltid nyeste utgave og ta backup før du redigerer kode.