Dieses Tutorial ist VALID.

Bitte lies Dir den Disclaimer durch, bevor Du eine Anleitung umsetzt...

Haftungsausschluss / Disclaimer

WordPress Docker Container

Konfiguration abschließen

An dieser Stelle lassen wir den Browser stehen und machen noch eine kurze Ergänzung auf unserem Terminal. Damit erweitern wir die WordPress Config um ein paar sicherheitsrelevante Punkte, ein wenig Performance Einstellungen und „Quality of Life“ Verbesserungen.

In der Datei „wp-config.php“, die im Webroot liegt, scrollen wir ins unter Drittel zu der Zeile „define( ‚WP_DEBUG‘, false );“. Danach ergänzen wir die folgenden Zeilen:

nano /var/www/wordpress.xp-server.de/wpdata/wp-config.php

### runterscrollen, nach "define( 'WP_DEBUG', false );" folgende Zeilen einfügen:
define( 'WP_DEBUG', false );
define( 'DISABLE_WP_CRON', true );
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );
define( 'WP_POST_REVISIONS', 3 );
define( 'AUTOSAVE_INTERVAL', 600 ); // Sekunden
define( 'EMPTY_TRASH_DAYS', 14 ); // Tage
define( 'FORCE_SSL_ADMIN', true );
define( 'IMAGE_EDIT_OVERWRITE', true );
define( 'WPLANG', 'de_DE' );

Zeile 4 ist selbsterklärend: Der Debug-Modus von WordPress wird deaktiviert.

In Zeile 5 schalten wir den internen „wp-cron“ aus. Stattdessen legen wir gleich im Anschluss einen crontab von unserem Host-System aus an…

Zeile 6 setzt das Memory Limit von php auf 256 MB.

Zeile 7 setzt das „Max“ Memory Limit auf 512 MB. Damit können wir für php kurzfristig bis zu 512 MB RAM allozieren.

Zeile 8 limitiert die Revisionen (Sicherheitskopien) der WordPress Beiträge und Seiten auf drei Stück. Bei jedem Speichern wird eine Sicherheitskopie des Artikels erstellt, um notfalls dahin zurückkehren zu können. Das bläht aber die Datenbank so richtig auf, wenn zu jedem Artikel unbegrenzt viele Revisionen gespeichert werden würden. Hier limitieren wir deren Anzahl auf drei pro Artikel. Willst Du mehr? Kein Problem, einfach eine höhere Zahl eintragen. Möchtest Du das Revisionssystem komplett ausschalten, dann tragen wir hier eine „0“ ein.

Zeile 9: Das Autospeicher-Intervall wird auf 600 Sekunden eingestellt. Alle 10 Minuten speichert WordPress unsere Artikel zwischen.

Zeile 10: Sämtliche Dokumente, die mehr als 14 Tage im Papierkorb liegen, werden entfernt. Hier kannst Du auch mehr oder weniger einstellen, was auch immer für Deinen Workflow passend ist.

Zeile 11 forciert den Admin-Zugang über „https“. Ohne SSL darf sich dann niemand mehr ins Backend einloggen. Unser Traefik macht zwar eine automatische Umschaltung von http auf https, aber mit der Einstellung gehen wir auf Nummer Sicher, uns niemals „ungesichert“ einzuloggen.

Zeile 12 fordert WordPress auf, die Vorschau-Bilder neu zu erstellen, nachdem wir ein Bild editiert haben.

In Zeile 13 legen wir die Sprache des CMS auf „Konfig-Ebene“ fest: „Deutsch“ mittels „de_DE“. Das ist beispielsweise für ein Übersetzungs-Plugin nötig. Und schaden tuts nicht ^^

Mit dem Speichern der Änderungen werden diese sofort aktiv.

Crontab zum periodischen Ausführen des Wartungs-Skripts anlegen

Hier finden wir noch ein wenig zusätzliche Infos zum Anlegen der Crontab und warum wir das überhaupt so machen…

Mit dem Befehl „crontab -e“ starten wir den Crontab-Editor und fügen folgende Zeile für unseren WordPress Dienst ein:

*/15 * * * * /usr/bin/docker exec -d wordpress /usr/local/bin/php -q -f /var/www/html/wp-cron.php > /dev/null 2>&1

Mit „Strg+x / y“ speichern wir die Crontab ab. Cron wird uns nun informieren, dass er den Cronjob erfolgreich integriert hat.

Ab jetzt wird zu jeder viertel Stunde durch den Host-Cron das Script „wp-cron.php“ im „wordpress“ Container ausgeführt. Dadurch stellen wir sicher, dass es zuverlässig läuft, da der „interne“ Mechanismus gerne hängt. Der basiert darauf, dass Besucher auf der Seite sind und dann periodisch das Script auslösen. Sind aber gar keine Besucher – und wir auch nicht – auf der Seite ODER haben wir so viele Besucher, dass wir ein Caching-Plugin fahren müssen, um die Last abzufangen, wird das Script nicht mehr ausgelöst. Dies umgehen wir elegant mit der Lösung über den Host-Cron. Und die hat mir von allen möglichen Varianten am Besten gefallen…

Strippen von Plugins und Themes

WordPress kommt standardmäßig mit den beiden Plugins „Akismet“ und „Hello Dolly“ daher. Akismet dient der Spam-Bekämpfung, ist aber aufgrund der beschissenen EU-DSGVO bei uns verboten. Hello Dolly nimmt niemand her. Also weg damit:

rm -rf /var/www/wordpress.xp-server.de/wpdata/wp-content/plugins/akismet
rm /var/www/wordpress.xp-server.de/wpdata/wp-content/plugins/hello.php

Zur Installation von WordPress gehören auch immer ein paar der Standard-Themes. Ein „Theme“ ist eine Art „Mantel“ für unsere Artikel: Die Texte werden aus der Datenbank geladen und das Theme kümmert sich darum, an welche Stelle mit welcher Schrift und welcher Farbe sie platziert werden. So können wir im Handumdrehen das Aussehen unserer Seiten ändern, indem wir nur ein neues Theme aktivieren.

Persönlich arbeite ich aber mit dem „Astra“-Theme, seit es damals im Mai 2017 das Licht der Welt erblickt hat. Astra ist sehr schlank und schnell, es hat eine Menge gut durchdachter Funktionen und wird von einem sehr enthusiastischem Team weiterentwickelt. Allesamt gute Zutaten für das Theme der Wahl :)

Natürlich möchte ich hier niemand vorschreiben, welches Theme er zu verwenden hat. Arbeitest Du lieber mit einem der Standard-Themes von WordPress? Kein Thema! Dann lösche es einfach nicht. Ich persönlich entledige mich aber an dieser Stelle von allen vorinstallierten Standard-Themes:

rm -rf /var/www/wordpress.xp-server.de/wpdata/wp-content/themes/twenty*

Jetzt sind wir „blank“: Keine Plugins, keine Themes. Das macht die Ausgabe der Seite auch etwas schwierig :)

WordPress ohne Themes – das Frontend ist tot, Jim…

Das „Backend“ hat zum Glück sein eigenes „Theme“ und wir können im Dashboard ganz normal arbeiten, auch, wenn das Frontend kein Theme mehr hat…

Wir legen hier komplett von „Null“ aus los… Darum löschen wir jetzt gleich im Backend von WordPress alle Beiträge, Kommentare und Seiten. Außerdem ändern wir ein paar Basis-Einstellungen.

Anzeige *

12 Kommentare zu „WordPress Docker Container“

  1. Hallo Peter,

    auch als Halblaie habe ich es nach Deinem Tutorial geschafft. Danke dafür.
    Meine Seite ist in Joomla und es wäre toll, könntest du auch ein Joomla-Tutorial erstellen.
    Die andere Lösung wäre, mich mit WordPress zu beschäftigen.

    1. Peter Fiedler

      Hallo Joachim,
      freut mich, wenn Du Erfolg mit der Anleitung hattest :)

      Joomla… Hatte ich kurz im Einsatz so 2008 / 2009 rum, bis ich entnervt auf WordPress umgestiegen bin.

      Problem ist, ich könnte wahrscheinlich ein Tutorial basteln, um Joomla zum Laufen zu bekommen. Aber da ich es nicht selber nutze, kann ich es nicht pflegen und hab auch keine Möglichkeit, das Ding im Einsatz rund zu schleifen. Mein WordPress Image / -Container hat buchstäblich Jahre an Entwicklungsarbeit in sich stecken und ich kann mit voller Überzeugung sagen, dass er gut funktioniert. Was ich bei einem Joomla Ableger halt nicht kann.

      Beste Grüße
      Peter.

      1. Hallo Peter,
        danke für die Antwort, dann werde ich mich WordPress widmen.
        Kann man später im Container WordPress durch die fertige lokale WordPress-Installation ersetzen?
        Kannst Du ein (Video) Tutorial empfehlen?

        Gruß Joachim

        1. Peter Fiedler

          Servus Joachim,
          ja, das geht. Das nennt man „Migrieren“ einer WordPress Installation.
          Ich nehm dafür „wpvivid Backup“ als Plugin. Damit erstellst Du lokal ein Backup, lädst das hoch und spielst es auf der produktiven Maschine zurück.
          Hinterher hab ich ein Plugin, das in der Datenbank suchen und ersetzen kann. Damit ändere ich noch letzte „lokale“ Adressen auf die „echten“.

          Videos hab ich mir dazu keine angesehen, die gibts aber sicher.
          Wenn es so weit ist, kannst Du Dich gerne noch mal melden. Das Migrieren ist kein Hexenwerk. Das bekommen wir schon hin ;)

          Beste Grüße
          Peter.

  2. Hallo,
    Ich bekomme keine zweite WP-Instanz zum laufen.
    Habe bisher eine subdomain.hauptdomain.de problemlos installiert bekommen.
    Nun wollte ich die Hauptdomain mit WP bestücken – klappt nicht – auch eine weitere subdomain1.hauptdomain.de klappt nicht.
    Wenn die neuen Container online sind, sind diese nicht zu erreichen und auch die bisher funktionierende Instanz ist dann nicht mehr zu erreichen.
    Habe eine neue Datenbank mit neuem User angelegt und diese natürlich in der WP-yml eingetragen. Die subdomain auch in den 2 Zeilen geändert. (auch die http://www.-Einträge bei der Hauptdomain)
    In welchen Punkten/Zeilen müssen sich die jeweiligen yml-Datein unerscheiden, wenn man mehrere Subdomains und die Hauptdomain online bringen möchte?
    Wer kann helfen?
    VG Hardy

    hier die Fehlermeldung: ~# docker logs -f –tail=“30″ beispielsudomain.hauptdomain.de
    WordPress not found in /var/www/html – copying now…
    Complete! WordPress has been successfully copied to /var/www/html
    AH00558: apache2: Could not reliably determine the server’s fully qualified domain name, using 172.18.0.4. Set the ‚ServerName‘ directive globally to suppress this message
    AH00558: apache2: Could not reliably determine the server’s fully qualified domain name, using 172.18.0.4. Set the ‚ServerName‘ directive globally to suppress this message
    [Wed Mar 04 07:55:49.290028 2020] [mpm_prefork:notice] [pid 1] AH00163: Apache/2.4.38 (Debian) PHP/7.4.3 configured — resuming normal operations
    [Wed Mar 04 07:55:49.290281 2020] [core:notice] [pid 1] AH00094: Command line: ‚apache2 -D FOREGROUND‘

    1. Peter Fiedler

      Ich tippe mal, dass bei den Traefik Labeln in den docker-compose-Dateien zwei Mal der selbe Name für die Router verwendet wurden…

      Die Lösung wäre dann:
      Domain1: traefik.http.routers.domain1.entrypoints=http
      Domain2: traefik.http.routers.domain2.entrypoints=http

      Das muss für alle Zeilen geändert werden und ist ein echter Nachteil zur Traefik v1 Config.

  3. Hallo Peter,
    erstmal vielen Danke für deine Tutorials. Dadurch habe ich es geschafft auf meinem Heimserver eine WordPressinstallation mit Rev.Proxy zu installieren.
    Jetzt habe ich aber ein Problem mit dem Matomo iFrame in meine Datenschutzerklärung. Leider wird mit der Inhalt im Frame nicht angezeigt, ich bekomme im Edge die Meldung, dass „Dieser Inhalt kann nicht in einem Frame angezeigt werden.
    An dieser Stelle sollten Sie eigentlich Inhalte sehen, aber der Herausgeber lässt die Anzeige in einem Frame nicht zu. Dadurch wird die Sicherheit der Informationen gewährleistet, die Sie ggf. auf dieser Website eingeben.“

    Wenn ich den Link anklicke wird mir der Inhalt auf einer extra Seite korrekt angezeigt.

    Habe keine Ahnung wo ich da anfagen soll. Bzw. wo das Problem liegt (WordPress,Ninja-Firewall,Traefik,Matomo)? Vielleicht kannst du mir helfen?

    Grüße Oliver

    1. Hallo Oliver,
      vielen Dank für das Lob! Dann hat sich die ganze Mühe auch rentiert, wenn ich jemand damit helfen konnte.

      Ich glaube, dass Dein iframe Link beim Kopieren oder Einfügen geändert wurde. Da stehen hinter den Anweisungen jeweils (ich muss das gesperrt schreiben, sonst wird das auch interpretiert) [& a m p ;], was da eigentlich nicht hingehört.

      In Gutenberg mach ich den Iframe mit einem „HTML“-Block, damit der 1:1 dargestellt und nicht interpretiert wird.

      Was auch sein kann sind besondere Security Header (X-Frame-Options), welche das Ausliefern von Iframes unterbinden. Aber da sehen ich auf Deiner Seite eigentlich nichts davon.

      Probier mal bitte, den Iframe als „HTML“-Block neu zu setzen. Ich hoffe, dass es das war :)

      Update: Ist doch ein Security Frame, der Inspector bringt mir diese Ausgabe:
      [ Laden verboten durch X-Frame-Options: „DENY“ ]

      Update 2: Mea Culpa…
      Ich hab beim traefik nicht aufgepasst. Da gehört für Matomo einer der Labels anders gesetzt, sonst haben wir den Salat.
      In Zeile 30 der docker-compose.yml Datei von matomo gehört „traefik.frontend.headers.frameDeny=true“ auf „false“ gesetzt.
      Danach den Container stoppen, starten und es müsste gehen.

        1. Super, danke für die Rückmeldung :)
          Hab das Tutorial entsprechend angepasst, damit da keiner mehr drüber stolpert.
          Noch viel Erfolg mit Deiner Webseite und einen „Guten Rutsch“ in neue Jahr!

    1. Noch mal Danke für diesen Hinweis, Christian!

      Da dachte ich, dass sich im WordPress Image das Apache Modul „remoteip“ darum kümmert?

      Vorher hab ich das über die Datei „.htninja“ im Webroot von WordPress gelöst…
      Mehr Info: http://nintechnet.com/ninjafirewall/wp-edition/help/?htninja

      Wobei die Lösung direkt über die wp-config.php schon sehr elegant ist, muss ich sagen…

      Und gern geschehn! Wenn die ganze Dokumentation für jemand hilfreich war, hab ich sie gerne ins Netz gestellt :)

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Verwendung
von Cookies

Um unsere Webseite für Sie optimal zu gestalten und fortlaufend verbessern zu können, verwenden wir Cookies. Durch die weitere Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen zu Cookies erhalten Sie in unserer Datenschutzerklärung.

Scroll to Top