Er zijn weinig velden in WordPress die zoveel schade aanrichten als de twee bovenaan het scherm met algemene instellingen. Eén verkeerd getypt teken en u kunt niet meer inloggen, niet meer terug naar de instellingen, en soms is de site zelf ook niet meer bereikbaar. Een verkeerde WordPress site-url is de klassieke manier om uzelf binnen twee seconden buiten te sluiten.
De rust bewaren helpt hier, want het is altijd te herstellen en meestal binnen tien minuten. Wat u nodig heeft, is toegang tot uw bestanden of tot uw database. Hieronder staan drie routes terug, van makkelijk naar minder makkelijk.
Waarom dit zo hard misgaat
WordPress kent twee adressen. Het ene, WordPress-adres genoemd, wijst naar de plek waar de programmatuur staat. Het andere, site-adres, wijst naar het adres waarop bezoekers binnenkomen. In veruit de meeste installaties zijn die twee gelijk.
Elk adres in uw site wordt vanuit deze velden opgebouwd: uw stijlbestanden, uw afbeeldingen, uw inloglink. Klopt het WordPress-adres niet, dan zoekt uw browser die bestanden op een plek waar niets staat. En omdat de inlogpagina ook op dat adres wordt gezocht, kunt u het niet meer via het beheerscherm corrigeren.
De meest gemaakte fouten: een www weggehaald of juist toegevoegd terwijl de site het andere gebruikt, een schuine streep te veel aan het eind, http in plaats van https, of een adres van een testomgeving dat bij het live zetten is blijven staan.
Route 1: vastzetten via wp-config.php
Dit is de snelste weg en werkt bijna altijd. U heeft FTP-toegang nodig of de bestandsbeheerder in het klantenpaneel van uw hosting.
- Download wp-config.php uit de hoofdmap van uw site en maak eerst een kopie op uw eigen computer.
- Open het bestand in een teksteditor als Kladblok of Notepad++, niet in een tekstverwerker.
- Voeg boven de regel die begint met /* That’s all twee regels toe: define( ‘WP_HOME’, ‘https://uwdomein.nl’ ); en define( ‘WP_SITEURL’, ‘https://uwdomein.nl’ );
- Let op de details. Geen schuine streep aan het eind, en gebruik precies de variant met of zonder www die uw certificaat dekt.
- Upload het bestand terug en roep uw inlogpagina op.
Deze regels overschrijven wat er in de database staat. Zolang ze erin staan, is het veld in het beheerscherm grijs en kunt u het niet meer per ongeluk verzetten. Dat is meteen het beste argument om ze te laten staan.
Route 2: rechtstreeks in de database
Wilt u de waarde echt corrigeren in plaats van overschrijven, dan gaat u naar phpMyAdmin in het klantenpaneel van uw hosting.
Kies uw database, open de tabel die eindigt op _options en zoek de rijen met de namen siteurl en home. Die staan vrijwel altijd op de eerste pagina, want ze hebben de laagste nummers. Klik op bewerken, corrigeer de waarde en sla op.
Twee waarschuwingen. Maak eerst een export van de tabel, zodat u terug kunt. En let op de tabelvoorvoegsels: heeft u meerdere sites in één database staan, dan zijn er meerdere tabellen die op _options eindigen en moet u de juiste hebben.
Deze route is ook de enige die werkt als er geen bestandstoegang is, bijvoorbeeld als u alleen databasetoegang heeft gekregen van een vorige beheerder.
Route 3: tijdelijk via het functies-bestand
Heeft u alleen toegang tot de themabestanden, dan kunt u de waarden tijdelijk forceren vanuit het functies-bestand van uw actieve thema. Zet bovenin twee regels die de opties voor home en siteurl bijwerken, laad uw site één keer, en haal de regels daarna direct weer weg.
Dit is nadrukkelijk een noodgreep. Blijven die regels staan, dan wordt bij elke paginaweergave de database bijgewerkt en dat kost onnodig veel tijd. Bovendien verdwijnt de oplossing zodra het thema wordt bijgewerkt of gewisseld.
Wat u daarna nog moet nalopen
De site is terug, maar u bent er nog niet helemaal. Loop deze punten na.
- Afbeeldingen en links in oude berichten. Die staan met het volledige adres in de database. Is het adres echt gewijzigd, dan moeten die worden omgezet met een zoek-en-vervangwerktuig dat ook met geserialiseerde gegevens overweg kan.
- Permalinks opnieuw wegschrijven. Ga naar Instellingen en dan Permalinks en klik op opslaan zonder iets te wijzigen.
- Alle caches legen, inclusief die van een netwerkdienst als Cloudflare. Anders blijven bezoekers de oude, kapotte versie zien.
- Doorverwijzingen controleren. Staat er ergens een regel die www afdwingt terwijl u nu zonder www draait, dan krijgt u een lus. Wat u daaraan doet, staat in de uitleg over een site die te vaak doorstuurt.
- Uw eigen sessie. Log één keer uit en weer in; oude cookies horen bij het oude adres.
Wanneer het geen typefout was
Verandert het adres opnieuw nadat u het heeft hersteld, dan heeft u geen vergissing maar een ingreep te pakken. Bij bepaalde vormen van misbruik wordt de site-url aangepast om bezoekers ergens anders naartoe te sturen, terwijl de beheerder niets doorheeft.
Aanwijzingen: het adres verandert naar een domein dat u niet kent, of het gebeurt alleen voor bezoekers die uit Google komen. Zet in dat geval de regels in wp-config.php vast, maar ga daarna verder zoeken. Ook een verlopen abonnement bij een migratieplugin of een verkeerd ingestelde staging-koppeling kan de waarde overschrijven; dat is onschuldiger maar even hardnekkig.
Kunt u helemaal niet meer inloggen en twijfelt u of dit de oorzaak is, kijk dan ook naar de bredere lijst met redenen in het overzicht van inlogproblemen bij WordPress. Niet elk buitengesloten worden komt van dit veld.
Een voorbeeld en de les eruit
Een bouwbedrijf uit Limburg wilde de site zonder www laten draaien en paste beide velden aan. Alleen was het certificaat destijds alleen voor de www-variant afgegeven. Resultaat: elke bezoeker kreeg een waarschuwing over een onveilige verbinding, en de eigenaar kon niet meer inloggen om het terug te zetten. Het herstel via wp-config.php kostte een kwartier, het aanvragen van een certificaat dat beide varianten dekt nog eens een uur.
De les: verander deze velden nooit zonder eerst te controleren welke varianten uw certificaat dekt en welke doorverwijzingen er al staan. En doe het niet op vrijdagmiddag.
Voorkomen kost twee regels
Zet de adressen vast in wp-config.php en het veld kan door niemand meer per ongeluk worden aangeraakt, ook niet door een medewerker die op zoek was naar iets anders. Voor sites met meerdere beheerders is dat wat ons betreft standaard.
Komt u er niet in en durft u niet in de database te werken, dan is dit typisch een geval voor hulp als u niet meer bij uw eigen beheerscherm komt. Bij WebMaintor is dit een van de meldingen die vrijwel altijd binnen het uur is opgelost, mits de FTP-gegevens bij de hand zijn.
Zoek die gegevens daarom nu alvast op en bewaar ze op een plek die u ook bereikt als uw site plat ligt. Dat is de enige voorbereiding die dit soort storingen echt korter maakt.
