Er zijn storingen die er onschuldig uitzien en storingen die er ronduit eng uitzien. Deze hoort bij de tweede groep: in plaats van uw homepage staat er een muur programmatekst op het scherm, beginnend met iets als <?php /** * Front to the WordPress application. en verder vol met puntkomma’s en accolades. PHP-code zichtbaar in de browser betekent dat de bezoeker meeleest in bestanden die hij nooit had mogen zien.

De geruststelling vooraf: uw inhoud is er nog. Er is niets gewist. Alleen ontbreekt de stap waarin de server die code omzet naar een pagina. Wat u ziet is de grondstof in plaats van het eindproduct.

Wat er normaal gebeurt, en wat er nu niet gebeurt

Bij een verzoek aan uw site gaat een bestand met de extensie .php eerst langs de PHP-verwerker op de server. Die leest de code, haalt teksten uit de database, bouwt daar HTML van en stuurt dat naar de browser. De bezoeker krijgt het resultaat, nooit het recept.

Valt die verwerker weg of wordt hij overgeslagen, dan doet de server iets anders: hij behandelt het bestand als gewone tekst en stuurt het integraal door. De browser weet niet beter en drukt het af. Vandaar dat u soms zelfs uw eigen commentaarregels terugleest.

Belangrijk om te weten: dit is niet altijd de hele site. Soms gebeurt het alleen op één pagina of alleen bij één functie, bijvoorbeeld na het plakken van een codefragment in een tekstblok. Dat verschil bepaalt waar u gaat zoeken.

Oorzaak 1: PHP draait niet meer op de server

De meest voorkomende variant, en bijna altijd het gevolg van iets dat net is gebeurd. Denk aan een verhuizing naar een nieuwe hostingpartij, een gewijzigde PHP-versie in het klantenpaneel, of onderhoud aan de server waarna een module niet is teruggekomen.

Snelle test: maak een bestand met de naam test.php in de hoofdmap met daarin één regel, <?php phpinfo();. Roep dat bestand op in uw browser. Krijgt u een blauwgrijze tabel met versiegegevens, dan werkt PHP en ligt het aan iets anders. Krijgt u die ene regel als tekst terug, dan staat PHP uit voor uw domein. Verwijder het testbestand daarna meteen; het verklapt te veel over uw server.

Oplossen doet u hier niet zelf. Neem contact op met uw hostingpartij, meld precies wat de test opleverde en vraag of de PHP-verwerking voor uw domein weer aangezet kan worden. Bij een recente overstap is dit vaak binnen een uur geregeld; de achtergrond daarvan staat in het artikel over verhuizen naar een andere hostingpartij.

Oorzaak 2: het bestand heeft de verkeerde naam of plaats

PHP wordt alleen uitgevoerd bij bestanden die de server als PHP herkent. Is uw index.php ooit hernoemd naar index.php.txt, index.php.bak of index.phtml, dan gaat hij als tekst de deur uit. Dit gebeurt vaker dan u denkt bij handmatig terugzetten van een back-up, waarbij een bestand met een tijdelijke naam blijft staan.

Kijk ook naar de regels in .htaccess. Er bestaan configuratieregels die PHP juist uitschakelen in bepaalde mappen; dat is een beveiligingsmaatregel voor de uploadsmap, maar staat hij te hoog in de boom, dan raakt uw hele site geblokkeerd. Zoek in dat bestand naar de woorden engine, handler of type en haal alleen weg wat u herkent als recent toegevoegd.

Oorzaak 3: een fragment code in de inhoud

Ziet u geen volledige bestandsinhoud maar één regel of een klein blok tussen uw gewone tekst, dan heeft iemand PHP in de editor geplakt. WordPress voert code in berichten en pagina’s bewust niet uit; het toont hem als tekst.

De oplossing is niet om die uitvoering aan te zetten, want dan kan iedere redacteur code draaien op uw server. Haal het fragment weg en zet de functionaliteit op de juiste plek: in een kleine eigen plugin, in het functies-bestand van uw child-thema, of met een blok dat de plugin zelf aanbiedt. Weet u niet wat het fragment doet, laat het dan staan tot iemand ernaar heeft gekeken, maar zet de pagina desnoods tijdelijk op concept.

Oorzaak 4: er is geknoeid met de bestanden

De vervelendste variant. Bij een inbraak worden er nogal eens bestanden vervangen, en een half geslaagde poging levert precies dit beeld op: code die zichtbaar wordt omdat de opening of afsluiting niet meer klopt.

Aanwijzingen dat dit speelt: wijzigingsdatums van vannacht, een index.php die veel groter is dan de originele paar honderd bytes, of vreemde tekenreeksen ergens in de zichtbare code. Lees in dat geval mee met de aanpak om gewijzigde bestanden op te sporen voordat u iets terugzet, want herstellen zonder de ingang te dichten levert binnen een week hetzelfde probleem op.

Wat u meteen doet, in volgorde

  1. Haal de site tijdelijk uit de lucht of zet er een onderhoudspagina voor. Zolang code zichtbaar is, kan iedereen uw databasegegevens uit wp-config.php lezen als dat bestand ook wordt getoond.
  2. Controleer of wp-config.php leesbaar is door hem rechtstreeks op te roepen. Ziet u daar uw wachtwoord staan, wijzig dan direct het databasewachtwoord bij uw hosting.
  3. Doe de phpinfo-test zoals hierboven beschreven, zodat u weet of het aan de server of aan de bestanden ligt.
  4. Kijk naar wat er de afgelopen dagen is gebeurd. Een update, een verhuizing, een handmatige aanpassing, een nieuwe medewerker met FTP-toegang.
  5. Zet pas daarna een back-up terug. Doet u dat eerst, dan wist u het spoor uit en weet u nooit waarom het gebeurde.

Een installatiebedrijf uit Brabant kreeg dit beeld op een maandagochtend na een nachtelijke servermigratie bij de host. De PHP-module was voor twee van de zestig domeinen niet meegekomen. Anderhalf uur na de melding stond alles weer, maar in de tussentijd was wel de complete themacode publiek zichtbaar geweest, inclusief een sleutel voor een externe koppeling die daarna vernieuwd moest worden.

De les die u eraan overhoudt

Zet nooit gevoelige gegevens los in themabestanden. Sleutels en wachtwoorden horen in wp-config.php of in de instellingen van een plugin, niet in code die bij een storing zichtbaar kan worden. En houd bij welke wijzigingen er wanneer aan uw site zijn gedaan; dat maakt het verschil tussen tien minuten en twee dagen zoeken.

Blijft u er niet uit, of twijfelt u of het om een inbraak gaat, dan is een technische doorlichting van uw WordPress-site de snelste route. Bij WebMaintor is dit een van de meldingen waarbij we altijd eerst het bestandssysteem vergelijken met een schone installatie voordat er iets wordt aangeraakt.

Concreet om nu te doen: roep uw eigen wp-config.php rechtstreeks op in de browser. Blijft het scherm leeg, dan is dat goed nieuws. Ziet u tekst, dan begint u bij stap twee hierboven.