Hvordan tilpasse WordPress innloggingsside i 2026 (uten plugins)

Standard WordPress-innloggingsskjerm (wp-login.php) er gjenkjennelig, men den signaliserer «generisk installasjon». Når et byrå leverer til en kunde, er WordPress-logoen på innloggingssiden en merkevarelekkasje.

I 2026 er white-label av innlogging standard i klientprosjekter. Denne guiden viser hvordan du tilpasser opplevelsen med functions.php eller - bedre - en must-use-plugin, slik at skjermen føles som en del av produktet. Offisiell referanse: login_enqueue_scripts, login_headerurl og login_errors.

#Hvorfor tilpasse innlogging før overlevering

Tre grunner som dukker opp i support:

1. Tillit - redaktører logger inn hver uke. En merket skjerm reduserer «er dette riktig side?»-spørsmål.
2. Sikkerhet - generiske feilmeldinger og færre hint om brukernavn gjør enumerering vanskeligere.
3. Konsistens - samme farger og logo som frontend gjør at CMS-et føles ferdig, ikke midlertidig.

På et norsk forlagsprosjekt med tre redaktører og én ekstern korrekturleser forsvant «hvilken URL logger jeg inn på?» etter at logo, favicon-hint i nettlesertittel og login_headertext pekte til kundens merkevare. Det var femten linjer PHP, ikke en plugin-suite.

#Isoler koden i must-use-plugin

Ikke legg login-CSS i barne-temaets functions.php alene. Når kunden bytter skin, forsvinner white-label. Bruk wp-content/mu-plugins/wppoland-login.php (eller tilsvarende) slik at tilpasningen overlever temabytte og forblir under byråkontroll.

#1. Erstatt logoen

Bytt ut WordPress-«W» med kundens logo via CSS på #login h1 a.

function wppoland_login_logo() { ?>
    <style type="text/css">
        #login h1 a, .login h1 a {
            background-image: url(<?php echo esc_url( get_stylesheet_directory_uri() . '/images/kunde-logo.svg' ); ?>);
            height: 65px;
            width: 320px;
            background-size: contain;
            background-repeat: no-repeat;
            padding-bottom: 30px;
        }
    </style>
<?php }
add_action( 'login_enqueue_scripts', 'wppoland_login_logo' );

Bruk esc_url rundt URI. SVG eller PNG med transparent bakgrunn fungerer best på både lys og mørk flate.

Standardlenken går til WordPress.org. Pek den til forsiden:

function wppoland_login_logo_url() {
    return home_url( '/' );
}
add_filter( 'login_headerurl', 'wppoland_login_logo_url' );

function wppoland_login_logo_title() {
    return get_bloginfo( 'name' );
}
add_filter( 'login_headertext', 'wppoland_login_logo_title' );

login_headertext erstatter den gamle login_headertitle-filteret i moderne WordPress.

#2. Full CSS-overhaling

Den grå standardbakgrunnen er sjelden merkevare. Last en dedikert fil bare på innloggingssiden:

function wppoland_login_stylesheet() {
    wp_enqueue_style(
        'wppoland-custom-login',
        get_stylesheet_directory_uri() . '/style-login.css',
        array(),
        '2026.1'
    );
}
add_action( 'login_enqueue_scripts', 'wppoland_login_stylesheet' );

Eksempel style-login.css:

body.login {
    background-color: #0d1117;
    display: flex;
    align-items: center;
    justify-content: center;
}
.login form {
    background: #161b22;
    border: 1px solid #30363d;
    box-shadow: none;
    border-radius: 8px;
}
.login label {
    color: #c9d1d9;
}
.wp-core-ui .button-primary {
    background: #238636;
    border-color: rgba(27, 31, 35, 0.15);
}
.login #backtoblog a,
.login #nav a {
    color: #8b949e;
}

Test både lys og mørk preferanse hvis kunden har offentlig frontend i lys modus - kontrast på knapper og feilmeldinger er det som vanligvis glipper.

#Hva du bør style (sjekkliste)

#3. Sikkerhetsherding av feilmeldinger

Som standard kan WordPress avsløre om et brukernavn finnes. Det hjelper brute force. Tving en generisk melding:

function wppoland_login_errors() {
    return 'Innlogging mislyktes. Sjekk brukernavn og passord.';
}
add_filter( 'login_errors', 'wppoland_login_errors' );

Dette er ikke erstatning for rate limiting, 2FA eller sterke passord. Det er én lag i dybden. Kombiner med:

• Unikt administratorbrukernavn (ikke admin)
• Begrensning av innloggingsforsøk (plugin eller serverregel)
• HTTPS overalt
• Eventuelt bytte av innloggings-URL bare hvis du også sikrer resten av overflaten

#4. Fjerne riste-effekten

Ved feil rister skjemaet. Noen klienter synes det er uprofesjonelt eller distraherende:

function wppoland_remove_login_shake() {
    remove_action( 'login_head', 'wp_shake_js', 12 );
}
add_action( 'login_head', 'wppoland_remove_login_shake' );

Test etter kjerneoppdateringer - prioritet og hook kan endre seg mellom major-versjoner.

#5. Extra hooks som ofte mangler i «logo-only»-guider

#Skjul language switcher når den ikke trengs

add_filter( 'login_display_language_dropdown', '__return_false' );

#Sett body-klasse for mer spesifikk CSS

function wppoland_login_body_class( $classes ) {
    $classes[] = 'wppoland-branded-login';
    return $classes;
}
add_filter( 'login_body_class', 'wppoland_login_body_class' );

#Redirect etter innlogging per rolle

function wppoland_login_redirect( $redirect_to, $request, $user ) {
    if ( isset( $user->roles ) && is_array( $user->roles ) ) {
        if ( in_array( 'shop_manager', $user->roles, true ) ) {
            return admin_url( 'edit.php?post_type=shop_order' );
        }
    }
    return $redirect_to;
}
add_filter( 'login_redirect', 'wppoland_login_redirect', 10, 3 );

Ikke hardkod kunde-URL-er uten admin_url() / home_url() - det knuser staging.

#6. 2FA og passkeys

I 2026 er passord alene sjelden nok for administratorer. Du bygger sjelden 2FA fra bunnen i functions.php. Bruk en vedlikeholdt løsning (for eksempel Two Factor-økosystemet) og style feltene:

.login .backup-methods,
.login .two-factor-email,
.login .two-factor-totp {
    /* match brand tokens */
}

Test recovery codes i staging før go-live. En merket innlogging uten fungerende 2FA-recovery er verre enn standardskjermen.

#Staging-sjekkliste før overlevering

1. Logo lastes over HTTPS uten blandet innhold
2. login_headerurl peker til produksjonsforside (ikke staging-domene etter cutover)
3. Feilmelding er generisk på både norsk og engelsk locale hvis begge brukes
4. Riste-JS er fjernet hvis ønsket
5. Mobile: skjemaet er lesbart på 375px bredde
6. mu-plugins-filen er i repo og dokumentert i overleveringsnotat
7. 2FA / passkey flyt testet med én ikke-admin-bruker

#Det du ikke bør gjøre

• Injisere jQuery tungt på login bare for animasjoner
• Skjule «Lost your password?» uten alternativ supportkanal
• Hoste logo fra et eksternt CDN uten cache-policy
• Låse innlogging bak obscurity alene (hemmelig URL) uten rate limits
• Legge merkevare-CSS i et page builder-plugin som kunden kan deaktivere

#Praktiske feil vi ser i leveranser

Byråer glemmer ofte at staging og produksjon har ulike domener. Logo-URL hardkodet til staging gir ødelagt bilde etter cutover. Løsningen er alltid tema- eller plugin-relative stier via get_stylesheet_directory_uri() eller assets i must-use-plugin med plugin_dir_url(). Et annet klassisk problem: CSS lastes globalt via wp_enqueue_scripts i stedet for login_enqueue_scripts, så frontend får login-stiler og omvendt.

Vi ser også at folk fjerner «Glemt passord»-lenken for å «se ryddigere ut». Det flytter support til e-post og Slack. Behold lenken, eller erstatt den med en tydelig supportadresse. På flerspråklige nett (bokmål/nynorsk eller nb/en) må feilmeldingen og login_headertext testes i begge locales - ellers får engelske redaktører norske strenger midt i en engelsk UI, eller motsatt.

#Tilgjengelighet og kontrast

White-label er ikke unnskyldning for lav kontrast. Primærknapper må ha tilstrekkelig kontrast mot bakgrunn. Feilmeldinger skal ikke kun kommuniseres med farge. Fokustilstander på felt og knapper må være synlige for tastaturnavigasjon. Hvis du bruker mørk bakgrunn, test også systemets «prefers-color-scheme» hvis frontend er lys - mange redaktører logger inn fra samme maskin som de leser nettsiden på, og forventer ikke et helt annet kontrastregime uten varsel.

Skjermlesere får tittel fra dokumentet og fra logo-lenketeksten. Tom login_headertext eller bare «Powered by WordPress» er svakt. Bruk nettstedsnavnet. Unngå bakgrunnsvideo eller store parallaks-effekter på login - det øker lastetid og gir ingenting for oppgaven «logg inn».

#Når plugin likevel er riktig valg

Ren PHP-tilpasning er nok for logo, CSS, feilmeldinger og redirect. Den er ikke nok når du trenger full social login, avansert brute-force-beskyttelse med geo-regler, eller et komplett white-label-admin utover login. Da er en vedlikeholdt plugin-stack bedre enn hjemmesnekret sikkerhetskode. Regelen: merkevare på login i egen mu-plugin; sikkerhetskontroller i dedikerte, oppdaterte pakker; ingen «all-in-one» som både styler login og skriver om REST-API uten at du har lest koden.

#Drift etter lansering

Dokumenter i overleveringen hvilken fil som eier login-stilen, hvordan logo byttes, og hvem som godkjenner endringer. Legg en regresjonstest i release-sjekklisten: åpne /wp-login.php på staging etter hver kjerneoppdatering. WordPress endrer av og til markup rundt language switcher og consent-bokser. En CSS-selektor som var stabil i fem år kan plutselig miste treff. Sett derfor versjon på enqueued CSS og bump den bevisst når du endrer filen, slik at CDN og nettlesere ikke serverer gammel stil.

For kunder med mange undersider og egne innlogginger (membership, WooCommerce my-account) skill offentlig konto-innlogging fra wp-login.php for administrasjon. Style begge, men ikke anta at samme CSS-fil treffer begge malene. WooCommerce-konto bruker ofte tema-maler; admin-login er kjerne. Test begge stier med en redaktørkonto og en kundekonto før go-live.

#Samspill med admin white-label

Login er ofte førsteinntrykket, men kundene tilbringer mest tid i wp-admin. Hold fargepalett og logo i sync med admin-tilpasning (menyopprydding, egne dashbord-widgeter). Når login er mørk og admin er standard grå, føles leveransen uferdig. Dokumenter tokens (primærfarge, radius, font) ett sted og gjenbruk dem i login-CSS og admin-CSS.

Hvis du allerede har en must-use-plugin for admin-meny, legg login-hooks i samme plugin under en tydelig seksjon. Én fil å reviewе i PR er bedre enn tre spredte snutter i child theme. Husk capability: login-tilpasning trenger ingen manage_options i runtime, men deploy av mu-plugin gjør det.

#Observabilitet

Logg ikke passord. Logg gjerne mislykkede innlogginger på servernivå (rate, IP, user-agent) via host eller WAF. Når en klient rapporterer «jeg kommer ikke inn», skill mellom glemt passord, 2FA-lås, IP-blokk og CSS-feil som skjuler knappen. En merket login uten synlig primærknapp på mobil er en support-felle vi har sett etter aggressive display-regler.

#Estimat for byråtimer

For en standard white-label login med logo, CSS, generiske feil, shake-removal og staging-sjekk: planlegg en halv dag inkludert review og mobiltest. Legg til tid hvis WooCommerce my-account skal matches, hvis flerspråk krever egne strenger, eller hvis 2FA-plugin trenger egen styling. Billigere enn å forklare WordPress-logoen i kickoff-møtet etter lansering.

Etter lansering: ta en skjermdump av login på desktop og mobil, legg den i overleveringsmappen, og gjenta sjekken etter neste WordPress-major. Små markup-endringer i kjernen er vanlige. En kvart time med regresjon sparer timer med «hvorfor er knappen borte»-support.

#Oppsummering

En tilpasset innloggingsside er liten kode med stor opplevd kvalitet.

• Merk den: logo, lenke, titteltekst
• Style den: egen CSS via login_enqueue_scripts
• Sikre den: generiske feil, 2FA for admin, rate limits
• Isoler den: must-use-plugin, ikke bare tema
• Verifiser den: staging etter oppdateringer, kontrast, flerspråk

Ikke la kunden møte standard WordPress-grensesnitt på første innlogging. Det undergraver hele leveransen. Bruk et kvarter på merkevare og et kvarter på sikkerhetslag - det er billigere enn å forklare hvorfor logoen fortsatt peker til WordPress.org tre måneder etter lansering.

Se vår WordPress-sikkerhetsrevisjon når neste steg er hardening utover skjermen.