Onder Weergave en onder Plugins zit in een standaard WordPress-installatie een scherm waarmee u de code van uw thema en van uw plugins rechtstreeks kunt aanpassen. Handig bedacht, maar in de praktijk is de WordPress bestandsbewerker uitschakelen een van de eerste dingen die een beheerder doet, en met goede reden.

Het scherm combineert namelijk twee ongelukkige eigenschappen: een verkeerde tik legt uw hele site plat zonder waarschuwing, en wie ooit toegang krijgt tot uw beheerscherm heeft er meteen een gereedschapskist bij. Hieronder leest u waarom dat zo is en hoe u het regelt zonder uzelf voor de voeten te lopen.

Het risico bij normaal gebruik

De bewerker heeft geen enkel vangnet. Er is geen versiegeschiedenis, geen concept, geen ongedaan maken na het opslaan en geen controle op fouten. Vergeet u één puntkomma of één accolade in een themabestand, dan is het resultaat direct een site die niet meer laadt en, erger, een beheerscherm dat ook niet meer laadt. U kunt de fout dan niet meer terugdraaien via dezelfde weg waarlangs u hem maakte.

Dat is de klassieke route naar een witte pagina of naar de melding over een kritieke fout. Herstellen kan dan alleen nog via FTP of via de bestandsbeheerder van uw hosting, zoals beschreven in de uitleg over het uitschakelen van een plugin via FTP.

Er is nog een tweede probleem bij normaal gebruik: wat u met deze bewerker in een thema of plugin verandert, is bij de eerstvolgende update weg. Mensen passen zo een telefoonnummer of een tekst aan in een themabestand, en drie weken later staat de oude tekst er weer. Dat lijkt op spookgedrag, maar het is gewoon de update die zijn eigen bestand terugzet. Wie dat een paar keer heeft meegemaakt, zet het scherm uit eigen beweging al uit.

Het risico bij misbruik

Dit is de zwaardere reden. Lukt het iemand om in te loggen als beheerder, bijvoorbeeld met een gelekt wachtwoord, dan hoeft hij geen ingewikkelde aanval meer uit te voeren. Hij opent de bewerker, plakt een paar regels in een bestand dat op elke pagina wordt geladen, en heeft daarmee een blijvende achterdeur. Geen FTP nodig, geen server nodig, geen kennis nodig.

Wij zien dit terug bij een deel van de besmettingen die wij opruimen: de kwaadaardige code zit in functions.php van het actieve thema, en het toegangslogboek laat zien dat er kort daarvoor is ingelogd. Met de bewerker uit was diezelfde aanval een stuk lastiger geweest.

Zo zet u hem uit

De nette manier is één regel in wp-config.php, het configuratiebestand in de hoofdmap van uw site. U zet daarin de constante DISALLOW_FILE_EDIT op waar. Belangrijk: die regel moet vóór de regel staan die het einde van de configuratie aankondigt, anders doet hij niets.

  1. Maak een kopie van wp-config.php voordat u iets aanpast. Dit bestand bevat uw databasegegevens; een fout erin haalt de site direct offline.
  2. Open het bestand via FTP of via de bestandsbeheerder van uw hosting. Niet via de bewerker die u juist wilt uitschakelen.
  3. Voeg de regel toe, ergens boven de afsluitende opmerking over het stoppen met bewerken.
  4. Sla op en ververs uw beheerscherm. De menu-items voor thema- en pluginbewerking zijn verdwenen.

Kunt of wilt u niet aan het configuratiebestand komen, dan biedt vrijwel elke beveiligingsplugin dezelfde schakelaar aan. Dat werkt prima, met de bekende kanttekening dat de bescherming verdwijnt zodra die plugin wordt uitgeschakeld.

Er bestaat ook een strengere variant, DISALLOW_FILE_MODS, die daarnaast het installeren en bijwerken van plugins en thema’s via het beheerscherm blokkeert. Dat is zinvol op een site waar alle wijzigingen via een uitrolproces lopen, maar op een gewone bedrijfssite maakt het uw eigen onderhoud onnodig lastig. Kies die alleen bewust.

Wat u erdoor kwijtraakt

Eerlijk zijn hoort erbij: u levert wel iets in. Wie snel een regel CSS wil toevoegen of een klein aanpassinkje wil doen, moet nu via FTP. In de praktijk is dat zelden een probleem, om drie redenen.

  • Eigen CSS hoort niet in de bewerker. Daar is het scherm voor extra CSS in de themabewerker onder Weergave voor, en dat blijft gewoon werken.
  • Aanpassingen aan een thema horen in een child-thema, zodat ze een update overleven.
  • Wijzigingen in code hoort u eerst te testen, en dat doet u niet in een venster zonder ongedaan maken op de site waar uw klanten op zitten.

Werkt u met een extern bureau dat af en toe iets aanpast, spreek dan af dat zij via FTP of via een testomgeving werken. Dat is toch al de manier waarop het hoort te gaan.

Waar het in het geheel past

Deze maatregel staat nooit alleen. Hij hoort in het rijtje met een sterk wachtwoord, een tweede stap bij het inloggen, en het beperken van het aantal beheerders. Die laatste is minstens zo belangrijk: als de helft van uw team beheerderrechten heeft, is de bewerker maar een van de vele dingen die zij kunnen. Kijk daarom ook naar de verdeling van rechten over gebruikersrollen.

Bij WebMaintor zetten we de bewerker standaard uit op elke site die we in beheer nemen, als vast onderdeel van het basisniveau waarmee elke WordPress-site begint. Het kost vijf minuten, het is onzichtbaar voor bezoekers en het heeft bij herstelwerk al meer dan eens gescheeld.

Concrete volgende stap: log in en kijk of u onder Weergave een menu-item voor het bewerken van themabestanden ziet staan. Staat het er, dan weet u wat er deze week nog uit kan.