Inlogadres verplaatsen: instellen, controleren, terugzetten
Wat vooraf moet kloppen
Standaard staat de functie uit en zij schakelt zichzelf nooit vanzelf in. Drie dingen verhinderen het verplaatsen helemaal — de schakelaar blijft dan geblokkeerd en noemt de reden: (1) In de wp-config.php staat de noodrem define( 'KWPSEC_LOGIN_SLUG_OFF', true );. (2) De installatie is een netwerk met meerdere locaties; daar delen alle sites één aanmelding, het verplaatsen zou netwerkbreed moeten gebeuren. (3) De permalinks staan op ‘Eenvoudig’. Dan bereikt een pad als /gartentor helemaal geen PHP, de webserver antwoordt al eerder met 404. Stel onder Instellingen › Permalinks een andere structuur in voordat je verdergaat.
Een pad kiezen
Toegestaan zijn 3 tot 40 tekens: kleine letters, cijfers, koppelteken en liggend streepje. Geen schuine strepen, geen umlauten, geen punt; hoofdletters worden omgezet naar kleine letters. Bij het opslaan lopen vier controles: namen van de gebruikelijke botlijsten (login, wp-login, admin, wp-admin, anmelden, dashboard en soortgelijke) worden geweigerd, omdat ze binnen enkele minuten weer gevonden zouden zijn. Bestaat er in de WordPress-installatie al een bestand of een map met die naam, dan wordt het pad geweigerd — de webserver zou die uitleveren voordat PHP wordt gevraagd. Gereserveerde routes als wp-json, feed, author, category, sitemap of favicon zijn geblokkeerd. En ligt er onder het pad al een bericht of een pagina, dan wordt het geweigerd, omdat die daarna niet meer bereikbaar zou zijn. Een opgeslagen pad geldt nog niet — het wordt pas van kracht als je het verplaatsen daarnaast inschakelt.
Inschakelen: wat er dan automatisch gebeurt
Bij het omzetten van de schakelaar wordt de instelling opgeslagen en daarna haalt de server twee echte HTTP-verzoeken op tegen de eigen installatie: één keer het nieuwe, één keer het oude adres. Elke oproep heeft 8 seconden tijdslimiet, volgt geen redirects en stuurt geen cookies mee. Als bewijs dat werkelijk de inlogpagina heeft geantwoord, wordt in de antwoordtekst gezocht naar id="loginform" en name="log". Antwoordt het nieuwe adres met HTTP 404 en zonder inlogformulier, dan wordt de wijziging meteen teruggedraaid en de oude toestand hersteld — bij nginx ontbreekt in dat geval meestal de try_files-regel, bij Apache de .htaccess. Komt de controle er wel doorheen, dan stuurt de plug-in het nieuwe adres als platte-tekstmail naar het opgegeven meldingsadres (anders naar het e-mailadres van de beheerder); in de mail staat ook de noodremregel voor de wp-config.php. De terugmelding zegt onverbloemd of wp_mail() het bericht heeft aangenomen — zo niet, noteer het adres dan nu. Er wordt eveneens een vermelding in het activiteitenlog geschreven.
Wat er in het dagelijks gebruik verandert
Onder het nieuwe pad wordt het originele bestand wp-login.php ingeladen, niet nagebouwd — beveiligingsupdates van WordPress werken daar meteen door. /wp-login.php gedraagt zich voor uitgelogde bezoekers als elk adres dat niet bestaat: het verzoek wordt naar een onbezet pad herschreven en heel gewoon door het thema als 404 weergegeven, zonder eigen foutmelding — een eigen melding zou juist verraden dat hier iets verborgen is. Wie ingelogd is, komt er nog steeds door; dat is met opzet. Roept een uitgelogde bezoeker /wp-admin/ op, dan gaat het via een 302 naar de homepage in plaats van naar de aanmelding, anders zou het nieuwe adres in de Location-header staan. admin-ajax.php, admin-post.php, load-styles.php en load-scripts.php blijven bereikbaar, zodat contactformulieren, winkelwagens en beoordelingen blijven werken. Alle adressen die WordPress via site_url(), network_site_url() of wp_redirect() aanmaakt — wp_login_url(), wp_logout_url(), wp_lostpassword_url(), het action-attribuut van het formulier — wijzen automatisch naar het nieuwe pad.
Als je jezelf buitensluit of als iets vastloopt
Eerste weg: zolang er in je browser een geldige inlogcookie ligt, bereik je /wp-login.php en /wp-admin/ ongewijzigd. Tweede weg: het adres staat in de e-mail van het omzetten. Derde weg: zet define( 'KWPSEC_LOGIN_SLUG_OFF', true ); in de wp-config.php — daarmee geldt meteen weer wp-login.php, en de schakelaar blijft geblokkeerd totdat je de regel verwijdert. In het beheer staan bovendien twee knoppen: een die de controleoproep herhaalt en de HTTP-code, de antwoordtijd en de status van het oude adres weergeeft, en een die de toegangsmail opnieuw verstuurt. Meldt de controleoproep een netwerkfout in plaats van een HTTP-code, dan is meestal de loopback bij de hoster geblokkeerd — dat betekent niet dat het adres niet werkt; roep het zelf een keer op. Blijft een link van een andere plug-in op wp-login.php staan, dan is die daar vast bedraad en loopt hij niet via site_url(); herschreven kan alleen worden wat door deze filters gaat. Terugzetten kan altijd via dezelfde schakelaar.