DISALLOW_FILE_EDIT: WordPress-Dateieditor deaktivieren

Eine einzige Zeile in der wp-config.php genügt: define( 'DISALLOW_FILE_EDIT', true );. Damit verschwinden der Theme-Datei-Editor und der Plugin-Datei-Editor aus dem Dashboard. Das dauert zwei Minuten und hat keinen Einfluss auf Updates. Gleichzeitig kappen Sie den kürzesten Weg von einem gestohlenen Admin-Passwort zu Code, der auf Ihrem Server läuft.

Dieser Artikel erklärt, warum DISALLOW_FILE_EDIT wichtig ist, wie Sie die Konstante sicher setzen und was sie nicht verhindert. Außerdem geht es darum, wann sich die strengere Variante DISALLOW_FILE_MODS den zusätzlichen Aufwand wert ist.

Warum DISALLOW_FILE_EDIT wichtig ist: vom Admin-Login zum ausgeführten Code

WordPress bringt zwei eingebaute Code-Editoren mit. Den Theme-Datei-Editor finden Sie bei klassischen Themes unter Design, bei Block-Themes unter Werkzeuge. Der Plugin-Datei-Editor liegt bei klassischen Themes unter Plugins, bei Block-Themes ebenfalls unter Werkzeuge. Mit beiden können Administratoren (in Multisite-Netzwerken Super-Admins) PHP-Dateien direkt im Browser ändern und speichern. Beim nächsten Seitenaufruf führt der Server diesen Code aus.

Ein Admin-Login ist damit praktisch ein Shell-Zugang. Wer ein Admin-Passwort per Phishing erbeutet, aus einem anderen Datenleck wiederverwendet oder per Brute Force erraten hat, kann die functions.php öffnen und eine Hintertür einfügen. Genauso gut lässt sich eine versteckte Weiterleitung für Suchmaschinenbesucher einbauen oder ein Kartenskimmer in das Checkout-Template schleusen. Dafür braucht der Angreifer weder FTP noch Zugang zum Hosting, nur den Login.

Die meisten Produktivseiten brauchen keine Code-Bearbeitung im Browser. Entwickler arbeiten im Code-Editor, auf einer Staging-Umgebung oder über eine Versionsverwaltung. Live-PHP in einem Textfeld zu ändern bedeutet: kein Rückgängig, keine Prüfung, und ein einziger Syntaxfehler kann die Website lahmlegen. Auf einer geschäftlich genutzten Live-Seite bringt der Editor vor allem Risiko.

Den Login selbst abzusichern ist eine eigene Aufgabe, die wir in unserem Leitfaden zur Zwei-Faktor-Authentifizierung für WordPress-Admins behandeln. DISALLOW_FILE_EDIT begrenzt, was ein gestohlener Login anrichten kann.

So tragen Sie DISALLOW_FILE_EDIT in die wp-config.php ein

1. Laden Sie die wp-config.php herunter und bewahren Sie die Kopie als Sicherung auf. Bei vielen Hostern liegt sie im WordPress-Hauptverzeichnis, manche Setups legen sie ein Verzeichnis darüber ab.
2. Öffnen Sie die Datei per SFTP oder über den Dateimanager Ihres Hosters. Nehmen Sie dafür kein WordPress-Plugin.
3. Suchen Sie in der Datei nach DISALLOW_FILE_EDIT. Ist die Konstante schon definiert, ändern Sie die vorhandene Zeile, statt eine zweite hinzuzufügen. Eine doppelt definierte Konstante löst eine PHP-Warnung aus.
4. Fügen Sie die Zeile oberhalb des Kommentars ein, der mit /* That's all, stop editing! beginnt. Sie muss stehen, bevor wp-settings.php geladen wird.
5. Speichern, hochladen und das Dashboard neu laden.

/* Theme- und Plugin-Datei-Editor im Dashboard deaktivieren */
define( 'DISALLOW_FILE_EDIT', true );

/* That's all, stop editing! Happy publishing. */

Prüfen Sie anschließend das Ergebnis. Die Menüpunkte Theme-Datei-Editor und Plugin-Datei-Editor sollten verschwunden sein. Rufen Sie /wp-admin/theme-editor.php direkt auf, erscheint jetzt eine Fehlermeldung zu fehlenden Berechtigungen statt des Editors.

Über das Dashboard lässt sich die Konstante nicht wieder aufheben, und genau darum geht es. Wer den Editor zurückhaben will, braucht Dateizugriff auf den Server, ein Admin-Passwort reicht nicht mehr. Die Einstellung gilt für die gesamte Installation, in einem Multisite-Netzwerk also für jede Website. Die offizielle Dokumentation zur wp-config.php führt sie zusammen mit den übrigen Konfigurationskonstanten auf.

Falls Sie weder SFTP noch einen Dateimanager zur Verfügung haben: Das Plugin Security Audit & Compliance von secaudit.eu bietet einen optionalen Schalter, der die Datei-Editoren im Dashboard abschaltet.

Wovor das Abschalten des Dateieditors nicht schützt

DISALLOW_FILE_EDIT versperrt den bequemsten Weg. Ein Admin-Konto wird dadurch aber nicht harmlos. Ein Administrator – oder ein Angreifer mit dessen Zugang – kann weiterhin:

• ein Plugin- oder Theme-ZIP mit Schadcode hochladen, unter Plugins → Neues Plugin hinzufügen oder Design → Themes
• neue Administratorkonten anlegen, die Admin-E-Mail-Adresse ändern oder Passwörter anderer Nutzer zurücksetzen
• Einstellungen ändern, etwa die Website-URL, die Benutzerregistrierung oder die Standardrolle
• Nutzer- und Bestelldaten exportieren

Wer Zugang zu FTP, SSH, Hosting-Panel oder Datenbank hat, umgeht WordPress vollständig, und keine Konstante in der wp-config.php hält ihn auf. Ebenso wenig hilft sie gegen verwundbare Plugins, die sich ganz ohne Login ausnutzen lassen. Das ist ein eigenes Problem mit eigenen Gegenmaßnahmen, beschrieben in unserem Leitfaden zu verwundbaren WordPress-Plugins.

Sehen Sie DISALLOW_FILE_EDIT als eine Schutzschicht von mehreren. Sie kostet fast nichts und lohnt sich unbedingt, behebt aber weder einen schwachen Login noch ein ungepatchtes Plugin.

Dateimanager- und Code-Snippet-Plugins: der Editor unter anderem Namen

Etliche Plugin-Typen holen genau dieses Risiko zurück, und DISALLOW_FILE_EDIT greift bei ihnen nicht:

• Dateimanager-Plugins, mit denen Sie Dateien im Dashboard durchsuchen, bearbeiten und hochladen
• Code-Snippet-Manager, die PHP speichern und bei jedem Aufruf ausführen
• Felder wie „Code in Header/Footer einfügen“, die Skripte oder PHP annehmen
• Theme- oder Page-Builder-Optionen mit einem Feld für eigenen Code

Ist eines davon aktiv, hat ein Angreifer mit Admin-Login nach wie vor einen Code-Editor.

Verschaffen Sie sich zuerst einen Überblick. Gehen Sie Plugins → Installierte Plugins und Ihre Theme-Optionen durch und notieren Sie alles, was Dateien bearbeiten oder eigenen Code ausführen kann. Dann gehen Sie je nach Typ vor:

• Dateimanager: Löschen Sie sie, sobald die einmalige Aufgabe erledigt ist. Deaktivieren reicht nicht, denn der Code bleibt auf dem Server und kann selbst Sicherheitslücken haben.
• Snippets, die Sie wirklich brauchen: Verschieben Sie sie in ein kleines eigenes Plugin oder ein Child-Theme und legen Sie es in die Versionsverwaltung. Änderungen laufen dann über Ihr normales Deployment statt über den Browser.
• Snippet-Manager, die bleiben: Prüfen Sie, welche Rollen Snippets anlegen oder bearbeiten dürfen, und beschränken Sie das auf so wenige Personen wie möglich.

DISALLOW_FILE_MODS: stärkere Sperre, echte Nachteile

define( 'DISALLOW_FILE_MODS', true ); geht einen Schritt weiter. Die Konstante verhindert, dass Plugins und Themes im Dashboard installiert, aktualisiert oder gelöscht werden, und schaltet die automatischen Hintergrund-Updates von WordPress ab. Damit ist auch der ZIP-Upload versperrt, den DISALLOW_FILE_EDIT offenlässt.

Der Preis: Nichts aktualisiert sich mehr von selbst. Kümmert sich niemand auf anderem Weg um Updates, fällt die Website bei Sicherheitskorrekturen nach und nach zurück. Auch die gewohnten Update-Hinweise im Dashboard verschwinden. Nur der Website-Zustand meldet noch, dass Hintergrund-Updates deaktiviert sind – die Lücke fällt also leicht niemandem auf.

Update-Weg einrichten, bevor Sie DISALLOW_FILE_MODS aktivieren

Entscheiden Sie sich für einen dieser Ansätze und machen Sie ihn zur Routine:

• WP-CLI auf dem Server. Updates laufen über die Kommandozeile, von Hand oder als geplanter Job:

wp core update
wp plugin update --all
wp theme update --all

• Deployment über Git oder Composer. Die Versionen von Plugins und Themes stehen im Repository, eine Pipeline baut die Website und spielt sie aus. Updates werden so zu Commits, die Sie prüfen und zurückrollen können.
• Update-Werkzeuge des Managed Hosters. Manche Hoster spielen Updates für Sie ein, oft mit vorheriger Sicherung oder visueller Prüfung. Klären Sie genau, was abgedeckt ist und ob Premium-Plugins dazugehören.

Testen Sie die gewählte Methode auf einer Staging-Kopie, auf der DISALLOW_FILE_MODS bereits aktiv ist. Was dort funktioniert, hängt von Ihrer Serverkonfiguration ab – stellen Sie das sicher, bevor Sie die Produktivseite umstellen.

Planen Sie die Updates per Cronjob oder Pipeline-Trigger und kontrollieren Sie, ob der Job tatsächlich läuft. Ein Job, der still scheitert, ist nicht besser als gar keiner. Halten Sie fest, was wann aktualisiert wurde. Dieses Protokoll ist ein nützlicher Nachweis für „geeignete technische und organisatorische Maßnahmen“ nach Art. 32 DSGVO.

Tempo zählt. Der Sicherheitsanbieter Patchstack berichtet in seinem State of WordPress Security in 2026, dass bei stark ausgenutzten Schwachstellen der gewichtete Median bis zur massenhaften Ausnutzung bei 5 Stunden lag. Mit einer monatlichen manuellen Update-Runde halten Sie da nicht Schritt.

Prüfen, ob die Sperre noch greift

Konstanten gehen gern bei Migrationen, Hosterwechseln und „vorübergehendem“ Debugging verloren. Kontrollieren Sie sie deshalb regelmäßig:

grep -n DISALLOW_FILE wp-config.php
wp config get DISALLOW_FILE_EDIT

Der erste Befehl zeigt jede passende Zeile mit Zeilennummer, der zweite den Wert, den WP-CLI aus der Konfiguration liest. Führen Sie beide nach jedem Umzug auf einen neuen Server oder zu einem neuen Hoster erneut aus. Achten Sie außerdem auf unerwartete Änderungen an PHP-Dateien in Theme und Plugins. Ist die Sperre aktiv, bedeutet eine solche Änderung, dass sich jemand auf anderem Weg Zugang verschafft hat.

Stellen Sie fest, dass der Editor bereits gegen Sie eingesetzt wurde, geht es nicht mehr um Härtung, sondern um Incident Response. Lesen Sie dann unsere Leitfäden zum Aufspüren von Web-Shells und zur Malware-Entfernung bei WordPress, bevor Sie irgendetwas anderes ändern.

Das Audit-Plugin von secaudit.eu prüft Ihre Härtungs- und Konfigurationseinstellungen, darunter den Dateieditor. Außerdem überwacht es die Dateiintegrität gegenüber einem Ausgangsstand, sodass Änderungen an Theme- und Plugin-Dateien im Bericht auftauchen → secaudit.eu

FAQ

Legt DISALLOW_FILE_EDIT meine Website oder die Updates lahm?

Nein. Die Konstante entfernt nur die beiden Editoren im Dashboard. Updates für Plugins, Themes und den Core laufen weiter, auch die automatischen. Erst DISALLOW_FILE_MODS verändert, wie Updates funktionieren.

Kann ich den Editor vorübergehend wieder einschalten?

Ja. Setzen Sie die Konstante auf false oder kommentieren Sie die Zeile aus und stellen Sie sie danach wieder her. Besser ist es, die Datei per SFTP oder auf Staging zu bearbeiten – dann muss der Editor gar nicht erst zurückkommen.

Gibt es diese Einstellung im WordPress-Dashboard?

Nein. Der Core bietet dafür keine Option im Dashboard; es ist eine Konstante, die Sie in der wp-config.php setzen. Können Sie diese Datei nicht bearbeiten, nutzen Sie ein Plugin mit einem Schalter zum Deaktivieren der Datei-Editoren.