Blog · 23. August 2026

Theme-Anpassungen, die das nächste Update überleben

Wer CSS oder PHP direkt ins Theme schreibt, verliert alles beim nächsten Update. Vier saubere Wege — und welcher wann der richtige ist.

Es ist einer der häufigsten WordPress-Unfälle, und er passiert lautlos: Jemand ändert eine Farbe in der style.css des Themes oder baut eine Funktion in dessen functions.php ein. Monate später kommt ein Theme-Update — und WordPress ersetzt dabei den kompletten Theme-Ordner durch die neue Version. Alle Änderungen sind weg, ohne Warnung, ohne Papierkorb. Updates aufzuschieben ist keine Lösung, denn veraltete Themes sind eines der größten Einfallstore für Angreifer.

Die Lösung ist immer dieselbe: Eigene Änderungen gehören an einen Ort, den Updates nicht anfassen. Dafür gibt es vier bewährte Wege.

Weg 1: Das Child-Theme (in 15 Minuten eingerichtet)

Ein Child-Theme ist ein Mini-Theme, das auf dem Original aufsetzt: Alles kommt weiter vom Eltern-Theme, nur Ihre Änderungen liegen im eigenen Ordner — und den lässt jedes Update in Ruhe. Zwei Dateien genügen:

  1. Ordner anlegen, z. B. wp-content/themes/meintheme-child/.

  2. style.css mit dem Pflicht-Kopf erstellen — entscheidend ist die Zeile Template:, sie muss exakt den Ordnernamen des Eltern-Themes nennen:

    /*
     Theme Name: Mein Theme Child
     Template:   meintheme
    */
  3. functions.php erstellen, die das Eltern-Stylesheet lädt:

    <?php
    add_action('wp_enqueue_scripts', function () {
        wp_enqueue_style('parent-style', get_template_directory_uri() . '/style.css');
    });
  4. Im Backend unter Design das Child-Theme aktivieren. Danach kurz prüfen, ob Menüs und Widgets noch sitzen — die hängen am Theme-Namen und müssen nach dem Wechsel manchmal neu zugewiesen werden.

Ab jetzt kommt eigenes CSS in die style.css des Child-Themes, eigener PHP-Code in dessen functions.php. Auch Template-Overrides funktionieren so: Eine Kopie von z. B. single.php im Child-Ordner hat Vorrang vor der Datei des Eltern-Themes — Sie ändern die Kopie, das Original bleibt unberührt.

Weg 2 bis 4: Die Alternativen

  • Customizer → „Zusätzliches CSS” — für reine Optik-Anpassungen der schnellste Weg. Das CSS liegt in der Datenbank und überlebt Theme-Updates (aber nicht einen Theme-Wechsel — es hängt am aktiven Theme).
  • Code-Snippets-Plugin — verwaltet PHP-Schnipsel einzeln, jeder mit Titel und Beschreibung, einzeln abschaltbar. Gut für kleine Funktionen, wenn kein Child-Theme existiert und keins eingerichtet werden soll.
  • Eigenes Mini-Plugin — eine einzige PHP-Datei in wp-content/plugins/ mit Plugin-Kopf. Der sauberste Ort für alles, was mit der Funktion der Seite zu tun hat statt mit dem Design, denn es überlebt sogar einen Theme-Wechsel.

Was gehört wohin?

  1. Nur ein paar Zeilen CSS? → Customizer, „Zusätzliches CSS”.
  2. CSS in größerem Umfang oder Template-Änderungen? → Child-Theme.
  3. PHP-Funktionen, die zum Design gehören (Theme-Hooks, Layout-Logik)? → functions.php des Child-Themes.
  4. PHP-Funktionen, die die Seite auch nach einem Theme-Wechsel braucht (eigene Shortcodes, Anpassungen an WooCommerce, Schnittstellen)? → eigenes Mini-Plugin oder Code-Snippets-Plugin.

Selbstschutz: Aufschreiben, was geändert wurde

Der zweite häufige Unfall ist der vergessene: Zwei Jahre später weiß niemand mehr, warum ein Schnipsel existiert — und keiner traut sich, ihn zu löschen. Dagegen hilft Disziplin, keine Technik: über jede Änderung ein Kommentar mit Datum und Zweck, und eine kurze Liste aller Anpassungen an zentraler Stelle. Wer mit Git arbeitet, versioniert das Child-Theme; für alle anderen tut es ein Textdokument. Zukünftige Entwickler (und Sie selbst) werden es danken.

Wenn eine Anpassung über den Selbermach-Rahmen hinausgeht: Unsere Entwicklungs-Stunden (1 bis 10 Stunden, ab 89 €/Std im Paket) setzen genau so um, wie es dieser Beitrag beschreibt — updatesicher im Child-Theme oder eigenen Plugin, nach WordPress-Standards und mit kurzer Dokumentation zu jeder Arbeit.