Es gibt viele Anleitungen wie man WordPress unter Windows installiert. Viele beschränken sich dabei auf das Nötigste. Performance- und sicherheitsrelevante Hinweise werden dabei in den wenigsten Tutorials erwähnt. Der Begriff Windows besitzt zudem einen faden Beigeschmack: zu unsicher, zu langsam, zu kompliziert, zu fehleranfällig. Doch diese Zeiten sind längst vorbei. In dieser Anleitung wird die grundlegende Installation von WordPress auf einem Windows Server 2016 beschrieben. In nächster Zeit werden weiterführende Beiträge zum Thema Sicherheit und Performance erscheinen, um die Anleitung abzurunden.
Einleitung Installation IIS Installation PHP Konfiguration IIS Konfiguration PHP Installation MariaDB Installation WordPress
Einleitung
Der Webserver
In der neuesten Windows Server-Generation erscheint mit IIS 10 ein stabiler, performanter und gut abgesicherter Webserver aus dem Hause Microsoft. IIS unterstützt den kürzlich erschienenen Protokollstandard HTTP/2. Hauptsächlich zum neuen Standard beigetragen haben Google mit ihrer HTTP-Weiterentwicklung SPDY und Microsoft mit „HTTP Speed+Mobility“. HTTP/2 zeichnet sich u.a. durch Zusammenfassen von Requests und Server-initiierten Datenübertragungen (Push) aus.
IIS wird mit einer Vielzahl von Modulen ausgeliefert, aus denen die Benötigten ausgewählt und installiert werden. Damit reduziert sich die Angriffsfläche. Durch den modularen Aufbau ist er zudem problemlos durch Drittanbieter-Plugins erweiterbar. FastCGI ist Bestandteil des hauseigenen CGI-Moduls. Es bietet eine nahtlose Integration des PHP-Interpreters. Die Verwendung von IIS ist durch die Windows Server-, IIS Express durch die Windows Client-Lizenz abgedeckt.
Die Skriptsprache
PHP ist eine bekannte Sprache in der Anwendungsentwicklung des Webdesigns. Waren früher umfangreiche Webseiten von einer ungenügenden Geschwindigkeit gezeichnet, ist durch die Integration von Cache- und Optimierungsfunktionen der Einsatz von PHP keineswegs hinderlich, eine medienlastige Webseite mit Responsive Design und vielen Funktionen zu veröffentlichen. Das Entwicklerteam bietet mittlerweile PHP in einer stabilen 64 Bit-Version an, was gerade x64-Plattformen zugutekommt. Allerdings verbrauchen 64 Bit-Anwendung aufgrund ihrer Architektur mehr Arbeitsspeicher als vergleichbare 32 Bit-Anwendungen. Doch in Zeiten günstiger RAM-Riegel ist der Unterschied im Vergleich nur marginal.
Die Datenbank
Es gibt diverse Datenbank-Systeme die kostenlos zur Verfügung gestellt werden. War MySQL früher der Platzhirsch unter den Open Source-Datenbanken, so zeichnet sich ab, dass die ehemaligen MySQL-Entwickler durch die Abspaltung und Entwicklung der mAriaDB diesen Platz für sich erobern.
Das CMS
In der Anfangszeit des Internet existierten nur wenige, privat entwickelte Webseiten. Standards wurden erst noch entwickelt und wurden bisweilen nur rudimentär oder gar nicht in alle Browser portiert. Man musste sich in HTML, CSS, JS und PHP einarbeiten und die Eigenheiten der damals bestehenden Browser berücksichtigen. Content Management Systeme (CMS) kamen vermehrt um die Jahrhundertwende auf und gebaren eine Großzahl an Blogs und Webseiten u.a. durch den Einsatz benutzerfreundlicher Installations-Assistenten – Microsoft lässt grüßen 😉 – und die Integration grafischer Werkzeuge anstelle von Kommandozeilenbefehlen.
Insbesondere durch WYSIWYG-Editoren (What You See Is What You Get) ist eine eigene Webseite keine schwer zu überwindende Hürde mehr. Neben Joomla und Drupal konnte WordPress als Open Source-Projekt große Erfolge feiern. Es ist eines der weltweit am häufigsten verwendeten CMS. WordPress zeichnet sich insbesondere durch die einfache Bedienung und Erweiterbarkeit aus. Automatische Sicherheitsupdates machen es besonders pflegeleicht. Die deutsche Community betreibt ein eigenes, deutschsprachiges Portal.
Voraussetzungen
Für eine komplette Neuinstallation von WordPress werden in diesem Szenario folgende Komponenten eingesetzt:
- Webserver: Internet Information Server (IIS)
- Pipeline zum PHP-Interpreter: Fast Common Gateway Interface (FastCGI)
- Visual C++ Redistributable for Visual Studio in 32 Bit oder 64 Bit, Version ist zudem abhängig von der eingesetzten PHP-Version, siehe linke Spalte “Which version do I choose?” im Download-Bereich der PHP Webseite
- Serverseitige Skriptsprache: PHP VC15 x64 Non Thread Safe (aktuell Version 7.4, Download)
- Datenbank: MariaDB x64 (performanter MySQL-Fork, Download)
- Content Management System (CMS): WordPress 5 (Download)
Nach dem Download sollte das “Download from Internet”-Flag entfernt werden. Insbesondere bei Zip-Archiven kann sich das Flag auf die entpackten, ausführbaren Dateien auswirken.
Einleitung Installation IIS Installation PHP Konfiguration IIS Konfiguration PHP Installation MariaDB Installation WordPress
Einleitung Installation IIS Installation PHP Konfiguration IIS Konfiguration PHP Installation MariaDB Installation WordPress
Installation des Webservers
Die Installation des IIS ist denkbar einfach. Über den Server Manager wird die Webserver-Rolle hinzugefügt.
Wichtig ist, zusätzlich zur Standardauswahl, das Modul CGI unterhalb des Knotens Anwendungsentwicklung zu installieren.
Ob die Installation erfolgreich abgeschlossen wurde, kann nun über einen Funktionstest auf dem Server selbst erfolgen. Hierzu ruft man im Browser http://localhost auf und sollte die Startseite des IIS sehen.
Ein Hinweis zu dieser Anleitung, da es schon zu Missverständnissen kam: Localhost, wie oben genannt, ist immer der Rechner oder Server an dem man sitzt, ergo lokaler Host = localhost. Die Adresse eines Localhost ist immer die eigene, repräsentiert durch 127.0.0.1 (IPv4) oder ::1 (IPv6). Es ist in etwa so, als ob du mit dem Finger auf dich selbst zeigst. Das oben genannte Beispiel kann nur funktionieren, wenn man sich auf dem Rechner befindet, auf dem der IIS installiert wurde. In der Praxis ist das natürlich nicht der Fall. Da muss zum Aufrufen der Webseite der (öffentliche) Name des Webservers (bspw. www.privalnetworx.de) oder dessen (öffentliche) IP-Adresse (bspw. 130.180.81.222) eingegeben werden. Der IIS lauscht per default auf allen IP-Adressen des Servers – technisch gesehen ist das die IP 0.0.0.0 – auf dem TCP-Port 80. Daher muss in der Standardkonfiguration nichts angepasst werden. Es ist nur ein Eintrag im DNS notwendig, damit der Webseitenname in die IP-Adresse des Webservers übersetzt wird. Ich hoffe ich konnte das einigermaßen gut erläutern. Ansonsten bemüht gern die Kommentarfunktion weiter unten und ich versuche das Rätsel weiter zu entknoten. 🙂
Einleitung Installation IIS Installation PHP Konfiguration IIS Konfiguration PHP Installation MariaDB Installation WordPress
Einleitung Installation IIS Installation PHP Konfiguration IIS Konfiguration PHP Installation MariaDB Installation WordPress
Installation des PHP-Interpreters
PHP wurde mit C++ kompiliert und funktioniert daher nur in Verbindung mit einer Visual Studio-Laufzeitumgebung (64 Bit). Voraus geht daher die Installation von Visual C++ Redistributable for Visual Studio: Assistent ausführen, installieren, fertig. Welche VC Studio-Version zu installieren ist, hängt davon ab, welche PHP-Version verwendet werden soll. Weitere Infos finden sich auf der PHP-Webseite in der linken Spalte.
IIS leitet die Ausführung eines PHP-Skripts über FastCGI in einen eigenen Prozess aus, der php-cgi.exe. Das erfordert den Einsatz der Non Thread Safe-Version (NTS). Das heruntergeladene ZIP-File wird in einen Ordner entpackt, in diesem Szenario nach C:\PHP.
Obacht beim Download. Benötigt wird die x64-Variante der NTS-Version „VC1x x64 Non Thread Safe“ als ZIP-File, nicht das Debug Pack! Zudem sollte vor dem Entpacken das Internet Flag gelöscht werden.
Einleitung Installation IIS Installation PHP Konfiguration IIS Konfiguration PHP Installation MariaDB Installation WordPress
Einleitung Installation IIS Installation PHP Konfiguration IIS Konfiguration PHP Installation MariaDB Installation WordPress
Konfiguration des Webservers
Dem Webserver ist PHP bisher unbekannt. Diesen Umstand ändert man im Internet Information Services Manager (Aufruf über inetmgr.exe). Dem IIS muss mitgeteilt werden, welche Anforderung an welchen Handler weitergeleitet werden soll. Handler sind – vereinfacht ausgedrückt – Applikationen, die für die Verarbeitung definierter Dateitypen zuständig sind, in diesem Fall ist es der PHP-Interpreter, der die PHP-Skripte weiterverarbeitet. PHP-Skripte erkennt man an ihrer Dateiendung .php. Der IIS ist nun so zu konfigurieren, dass er Anfragen zu Dateien mit dieser Endung an PHP übergibt. Das geschieht über die Handler Mappings.
Über das Action Panel fügt man eine neue Modulzuordung (Add Module Mapping…) hinzu.
Neben den Pflichtangaben, wie in der Abbildung oben zu sehen, müssen die Einschränkungen gelockert werden, damit auch dann der PHP Handler greift, wenn auf Ordner zugegriffen wird.
Beim Speichern des neuen Module Mappings erscheint eine Frage bezüglich weitergehender Konfigurationen, die mit Ja bestätigt wird.
Über die FastCGI-Einstellungen kann nun die PHP-Anwendung konfiguriert werden.
Folgende Werte empfehlen sich für eine produktive Webseite.
| Option (deutsch) | Option (englisch) | Beschreibung | Wert |
| Vollst. Pfad | Full Path | Pfad zum PHP-Interpreter | C:\PHP\php-cgi.exe |
| MaxRequests-Instanz | Instance MaxRequests | Max. Anzahl von Anforderungen pro Instanz, bevor ein Prozess recycelt wird. Beim Recycling bzw. Wiederverwendung werden neue Anforderungen an einen neuen Prozess weitergeleitet. Der alte Prozess wird nach Abarbeiten aller noch bestehenden Requests beendet. Wichtig! Der Wert muss gleich groß oder kleiner als die PHP-Variable PHP_FCGI_MAX_REQUESTS sein. Weiter unten folgt eine kurze Erläuterung. | 10000 |
| Max. Anzahl von Instanzen | Max Instances | Gibt an, wie viele Prozesse von PHP (php-cgi.exe) maximal gleichzeitig laufen dürfen. Wird der Wert überschritten, liefert IIS Fehler 503 (Dienst nicht verfügbar) zurück. Achtung! Ein zu hoher Wert kann den Server überlasten! | 32 |
| Änderungen an der Datei überwachen | Monitor changes to file | Überwacht die angegebene Datei auf Änderungen und recycelt laufende Prozesse, wenn dieser Fall eintritt. Durch die Angabe der php.ini werden Änderungen in der Konfigurationen sofort übernommen. | C:\PHP\php.ini |
| Aktivitätstimeout | Activity Timeout | Gibt den maximalen Zeitraum an, den ein FastCGI-Prozess für die Anwendung ausgeführt werden darf, ohne mit IIS zu kommunizieren, bevor ein Timeout für den Prozess erfolgt. Dieses Timeout kann verwendet werden, um nicht reagierende Prozesse zu erkennen und zu beenden. | 300 |
| Leerlauftimeout | Idle Timeout | Gibt an, wie lange sich ein FastCGI-Prozess für die Anwendung im Leerlauf befinden kann, bevor der Prozess aufgrund dieses Leerlaufs beendet wird. Ist der Wert zu niedrig gewählt, kann das die Performance beinträchtigen. Insbesondere dann, wenn Optimierungsfunktionen wie OpCache verwendet werden. | 3600 |
| Anforderungstimeout | Request Timeout | Gibt die maximale Zeit an, die eine Anforderung an die Anwendung in Anspruch nehmen darf. Wenn ein FastCGI-Prozess länger dauert als die für eine einzelne Anforderung festgelegte Zeit, wird er beendet. Ein zu niedriger Wert kann die korrekte Ausführung von zeitintensiven Skripten verhindern. Ein zu hoher Wert kann den Server durch fehlerhafte Skripte belasten. Der Wert sollte min. so groß wie die PHP-Variable max_execution_time sein. | 300 |
| Warteschlangenlänge | Queue Length | Gibt die maximale Anzahl von Anforderungen an, die im FastCGI-Anwendungspool in die Warteschlange eingereiht werden können. Wenn die Warteschlange voll ist, geben nachfolgende Anforderungen den HTTP-Fehlercode 503 (“Dienst nicht verfügbar”) an die Clients zurück. Dieser Fehlercode gibt an, dass die Anwendung ausgelastet ist. | 10000 |
Empfehlenswert ist es, einige grundlegende Umgebungsvariablen zu konfigurieren (über die IIS FastCGI-Einstellungen). Die Environment Variables finden sich in der gerade erstellten Anwendung. Die erste Variable ist PHPRC. Durch sie wird dem PHP-Prozess mitgeteilt, in welchem Ordner sich die Konfigurationsdatei php.ini befindet.
Eine weitere Variable ist PHP_FCGI_MAX_REQUESTS. Sie bestimmt, wann der PHP-eigene Recycling Prozess starten soll. Da sich der IIS bereits um die Freigabe von Ressourcen kümmert, sollte der Wert größer sein als die Einstellung MaxRequests-Instanz (instanceMaxRequests) vom IIS. Siehe auch https://www.iis.net/learn/application-frameworks/running-php-applications-on-iis/configure-php-process-recycling-behavior.
Würde man eine Webseite von dem Webserver aufrufen, wüsste der IIS aktuell nicht, welche Datei er anzeigen soll. Man müsste also die Webseite inklusive Dateinamen abrufen, bspw. http://www.privalnetworx.de/index.php. Das will man natürlich nicht, also folgt die Definition der Standarddokumente. Im IIS auf Server- oder Webseitenebene findet sich das entsprechende Feature. Nicht genutzte Einträge sollten deaktiviert oder ganz entfernt werden. Für WordPress ist nur ein Eintrag notwendig: index.php. Das gilt meist auch für andere PHP-Webanwendungen.
In diesem Beispiel wird das Standarddokument auf Serverebene gesetzt. Alle auf dem Server befindlichen Webseiten erben diese Einstellung.
Einleitung Installation IIS Installation PHP Konfiguration IIS Konfiguration PHP Installation MariaDB Installation WordPress
Einleitung Installation IIS Installation PHP Konfiguration IIS Konfiguration PHP Installation MariaDB Installation WordPress
Konfiguration des PHP-Interpreters
Für eine grundlegende Konfiguration benennt man im Verzeichnis C:\PHP die Datei php.ini-production nach php.ini um.
Diese php.ini öffnet man mit einem Text-Editor seiner Wahl und sucht folgende Optionen heraus, um deren Werte zu prüfen und bei Bedarf anzupassen.
| Option | Beschreibung | Wert Standard | Wert empfohlen |
| cgi.force_redirect | cgi.force_redirect wird benötigt, um Sicherheit zu garantieren, wenn PHP als CGI-Version unter den meisten Webservern läuft. | 1 | 0 |
| cgi.fix_pathinfo | Bei Aktivierung (1) korrigiert PHP die Pfadnamen durch Verwendung von PATH_TRANSLATED. Wird cgi.fix_pathinfo deaktiviert (0), was von den Entwicklern empfohlen wird, nutzt PHP die Variable SCRIPT_FILENAME statt PATH_TRANSLATED. | 1 | 1 |
| fastcgi.impersonate | Erlaubt die Ausführung von PHP im Sicherheitskontext, der vom IIS bestimmt wird. | 0 | 1 |
| fastcgi.logging | Aktiviert SAPI Logging und kann zu Fehlern führen. | 1 | 0 |
| cgi.rfc2616_headers | Bestimmt welcher Typ von Headern benutzt werden soll, wenn HTTP-Antwort-Codes gesendet werden. Default ist RFC 3875, welcher von vielen Webservern unterstützt wird. Ist diese Option aktiviert, und PHP wird in einer CGI-Umgebung ausgeführt, sollten keine üblichen RFC 2616 HTTP Status-Response-Header verwenden werden; statt dessen sollten RFC 3875 Pendants genutzt werden, z.B. sollten anstelle von header(“HTTP/1.0 404 Not found”); header(“Status: 404 Not Found”); verwenden werden. | 0 | 0 |
| max_execution_time | Gibt an, wie lange ein PHP Skript maximal laufen darf. Ein zu niedriger Wert kann die korrekte Ausführung von zeitintensiven Skripten verhindern. Ein zu hoher Wert kann den Server durch fehlerhafte Skripte belasten. | 30 | 300 |
| extension_dir | Relativer oder absoluter Pfad zum Verzeichnis der Erweiterungsmodule. Bei Angabe eines relativen Pfades, bitte darauf achten, dass die Umgebungsvariable “PHPRC” in den FastCGI-Einstellungen des IIS gesetzt ist. Siehe Abschnitt “Konfiguration IIS”. | “ext” | “ext” |
Für die spätere WordPress-Installation braucht es einige Erweiterungen. Diese müssen in php.ini im Abschnitt Dynamic Extensions durch Entfernen des Semikolons aktiviert werden.
extension=php_curl.dll extension=php_fileinfo.dll extension=php_gd2.dll extension=php_gettext.dll extension=php_mbstring.dll extension=php_exif.dll ; Must be after mbstring as it depends on it extension=php_mysqli.dll
Um nun zu testen, ob PHP auch tatsächlich funktioniert, erstellt man im Stammverzeichnis der Standardwebseite C:\inetpub\wwwroot ein PHP-Skript namens index.php. Diese editiert man und fügt folgenden Code Snippet hinzu: <?php phpinfo(); ?>
Der Aufruf von http://localhost im Browser auf dem Webserver, sollte nun Informationen zur PHP-Umgebung anzeigen. Achtung! localhost ist ein Loopback-Objekt und verweist immer auf den lokalen Host. Ein Funktionstest über einen anderen Rechner als dem Webserver unter Verwendung von localhost wird fehlschlagen. Verwende stattdessen http://servername, wobei servername durch den Namen des Webservers ersetzt wird, bspw. http://websrv1.
Einleitung Installation IIS Installation PHP Konfiguration IIS Konfiguration PHP Installation MariaDB Installation WordPress
Einleitung Installation IIS Installation PHP Konfiguration IIS Konfiguration PHP Installation MariaDB Installation WordPress
Installation der Datenbank-Engine MariaDB
WordPress benötigt eine Datenbank, in der alle Daten gespeichert werden. In diesem Szenario wird MariaDB in der 64 Bit-Version eingesetzt. Der heruntergeladene Installer (64 Bit, MSI) führt durch die Installation.
Nach Bestätigen des EULA, erfolgt die Auswahl der Komponenten. Sofern nicht benötigt, kann auf die Entwicklungswerkzeuge verzichtet werden. An dieser Stelle kann zudem das Installationsverzeichnis geändert werden. Der Einfachheit halber wird MariaDB in das Verzeichnis C:\MariaDB installiert.
Als nächstes wählt man das Passwort des Benutzers root. Der Account besitzt die höchsten Privilegien und hat erhöhten Schutzbedarf. Das sollte bei der Wahl des Kennworts berücksichtigt werden. Weiter empfiehlt es sich, UTF8 als Standard-Zeichensatz zu aktivieren.
Angaben zu Dienstnamen, Port, Buffer Pool Size und Feedback wird auf Standard belassen.
Die WordPress-Installation benötigt eine Datenbank inklusive Benutzer. Dazu startet man HeidiSQL, den SQL-Editor der MariaDB beiliegt, und erstellt im Sicherheitskontext des Benutzers root eine Verbindung zum lokalen SQL-Server.
Die neue Datenbank wird mit Rechtsklick auf localhost mittels Neu erstellen hinzugefügt.
Über die Benutzerverwaltung wird zudem ein eigenes Konto für die Datenbank erstellt.
Mit Neues Objekt fügt man dem Benutzer die neue Datenbank hinzu und vergibt alle verfügbaren Berechtigungen.
Man kann natürlich auch den bereits bestehenden Benutzer root verwenden. Doch dieser verfügt über weitreichende, globale Berechtigungen mit vollständigem Zugriff auf alle Datenbanken des MariaDB-Servers, was ein Sicherheitsrisiko darstellt und nicht empfohlen ist.
Der geneigte Kommandozeilen-Freund kann diese Schritte freilich auch über die Shell abarbeiten:
CREATE DATABASE `wordpress`; CREATE USER 'DatenbankBenutzer'@'127.0.0.1' IDENTIFIED BY 'GeheimesPasswort'; GRANT SELECT, EXECUTE, SHOW VIEW, ALTER, ALTER ROUTINE, CREATE, CREATE ROUTINE, CREATE TEMPORARY TABLES, CREATE VIEW, DELETE, DROP, EVENT, INDEX, INSERT, REFERENCES, TRIGGER, UPDATE, LOCK TABLES ON `wordpress`.* TO 'DatenbankBenutzer'@'127.0.0.1' WITH GRANT OPTION;
Einleitung Installation IIS Installation PHP Konfiguration IIS Konfiguration PHP Installation MariaDB Installation WordPress
Einleitung Installation IIS Installation PHP Konfiguration IIS Konfiguration PHP Installation MariaDB Installation WordPress
Installation von WordPress
Im ZIP-File, was von der WordPress-Webseite heruntergeladen wurde, befindet sich der Ordner wordpress. Dessen Inhalt wird in das Stammverzeichnis der Webseite entpackt, in unserem Fall nach C:\inetpub\wwwroot.
Der IIS verfügt im Verzeichnis aktuell nur über lesende Rechte. Für die Installation benötigt der Webserver aber Schreibrechte. Diese richten wir ihm über die Eigenschaften des Ordners C:\inetpub\wwwroot ein.
Zum Ändern der Berechtigungen klickt man im Reiter Security auf „Edit…“ respektive „Bearbeiten…“.
Hier fügt man den Standardbenutzer des Webservers – IUSR – hinzu und erteilt ihm die Modify-Berechtigung.
Diese Berechtigung richtet man vor der Installation von WordPress ein, andernfalls muss die Konfigurationsdatei manuell erstellt werden. Das geht auch, doch die Installation und Updates der WordPress-Instanz inklusive Plugins und Themes, setzen Schreibrechte voraus.
Nun öffnet man den Browser auf dem Webserver und ruft http://localhost auf. Achtung! localhost ist ein Loopback-Objekt und verweist immer auf den lokalen Host. Der Aufruf auf einem anderen Rechner als dem Webserver wird fehlschlagen. Verwende stattdessen http://servername, wobei servername durch den Namen des Webservers ersetzt wird, bspw. http://websrv1 oder http://www.meinedomain.de.
Die, während der MariaDB-Installation, erstellte Datenbank und der zugehörige Datenbank-Benutzer wird an dieser Stelle angegeben.
Sind alle Daten korrekt, kann die Installation starten.
Es folgt die Erstellung des WordPress-Administrators und ein paar grundlegende Informationen zur Webseite.
Nun folgt auch schon das Dashboard von WordPress. Es ist es an der Zeit, die Homepage mit Inhalten zu füllen.
Die frisch installierte Webseite kann sich bereits jetzt sehen lassen.
Einleitung Installation IIS Installation PHP Konfiguration IIS Konfiguration PHP Installation MariaDB Installation WordPress
34 Kommentare
Alex · 13. November 2023 um 10:40
Hi, danke für die tolle Anleitung! Hat super funktioniert!
Ich habe nun aber folgendes Problem: wenn ich nicht angemeldet bin, erscheint bei mir unter http://localhost nur mein Website-Titel und coming soon. Sobald ich mich über http://localhost/wp-login.php anmelde, kann ich unter http://localhost auch wieder meine Website sehen…
Kann mir jemand helfen, wie ich quasi auch “ohne Login” meine Inhalte aufrufen kann? Danke!
Mac · 15. November 2023 um 14:34
Hi Alex. Klingt für mich danach, als ob ein Maintenance-Plugin aktiv ist. Schau einmal unter Plugins nach, was du installiert und aktiviert hast.
fufinternadmin · 27. Mai 2020 um 14:27
Vielen Dank erst mal für die tolle Anleitung.
Ich habe das Problem, dass der Aufruf von http://server/wp-json/ mit 404 quittiert wird. Darüber kann man eigentlich die REST-API aufrufen – aber das klappt bei mir mit dem IIS nicht. Was mache ich falsch?
Mac · 4. August 2020 um 00:43
404 steht für “Not found”. Das deutet darauf hin, dass der Zugriff auf eine Ressource erfolgt, die nicht existiert. Aktiviere und benutze das Tracing Modul für IIS, welche über den Servermanager installiert werden kann. Das Tracing Modul erfordert eine explizite Aktivierung und Konfiguration im IIS Managers der betreffenden Seite. Am besten aktiviert man den Trace nur beim Fehler 404. Eine entsprechende Angabe ist beim Konfigurieren anzugeben.
Nach abschließender Konfig ruft man im Browser die Seite erneut auf, um den Fehler 404 zu provozieren. Über das Trace Module lässt sich jeder Einzelschritt im Detail zurückverfolgen. Die Ergebnisse werden im XML-Format in dem Ordner abgelegt, der während der Konfig anzugeben ist. Am besten ruft man die XML-Datei im Internet Explorer auf, da dieser die Ausgabe optisch aufbereitet. Über das Error Tracing sollte der Fehler schnell gefunden und behoben werden.
Reiner · 11. Januar 2022 um 12:00
Möglicherweise stehen die Permalinks auf “Einfach”, dann existiert dieser Pfad nicht, in dem Fall nutzt man: http://server/?rest_route=/
Gord3n89 · 18. Dezember 2019 um 18:44
Für alle die auch einen Error ala Gateway 500 bekommen nachdem Sie PHP Installiert / konfiguriert habt
– Startet unter C:\PHP\ eine Kommandozeile
– Versucht die die php-cgi.de zu starten
– Wenn es nicht funktioniert und die Meldung “Das Programm kann nicht gestartet werden, da VCRUNTIME140.dll auf dem Computer fehlt. Installieren Sie das Programm erneut, um das Problem zu beheben.” kommt benötigt ihr die vc_redist.x64.exe (Visual C++ Redistributable für Visual Studio)
– Das dann Installieren. Bei mir klappt es wunderbar !
Mac · 4. August 2020 um 00:34
Danke für die Ergänzung. Es sei zudem erwähnt, dass die Visual C++ Redist.-Version abhängig von der PHP-Version ist. Diese Infos finden sich auf der PHP-Webseite (https://windows.php.net/) links am Rand im Abschnitt “Which version do I choose?”.
Dominic · 11. September 2019 um 10:06
Hallo Mac,
ich habe folgendes Fehler bekommen (nachdem ich die Daten der DB angegeben habe):
PHP Fatal error: Uncaught Error: Call to undefined function mysql_connect() in C:\inetpub\wwwroot\wp-includes\wp-db.php:1645
Stack trace:
#0 C:\inetpub\wwwroot\wp-admin\setup-config.php(305): wpdb->db_connect()
#1 {main}
thrown in C:\inetpub\wwwroot\wp-includes\wp-db.php on line 1645
Was muss ich da tun/verändern?
MfG
Mac · 20. September 2019 um 17:37
Hallo Dominic,
sieht ganz danach aus, dass eine notwendige PHP-Extension fehlt. Hast du die
php_mysqli.dllin der php.ini aktiviert und wird auch geladen? Erstelle mal ein PHP-Skript mit der phpinfo-Funktion (ohne Leerzeichen zwischen der Klammer und?php):< ?php phpinfo(); ?>Führe das Skript nun im Browser aus. Wird mysqli aufgelistet?
MfG
Mac
Antonio · 12. April 2019 um 13:11
Vielen Dank für die ausführliche Anleitung.
ich habe wordpress auf einer VM windows server 2012 zusammen mit IIS installiert. Wenn ich die Seite von einem Client aus aufrufe, werden die css Einstellungen nicht angezeigt und der Seitenaufbau ist zu langsam. Die Links rufen immer localhost auf, was zu Fehler führt. Da wo localhost steht, sollte die IP vom Server stehen oder DNS-Name.
Leider habe ich nicht viel Ahnung von IIS. Könnte jemand behilflich sein?
Vielen Dank
Mac · 2. Mai 2019 um 13:19
Localhost verweist auf den eigenen Rechner, den lokalen Host. Der Client versucht also die Ressourcen von sich selbst zu laden, was natürlich fehlschlägt. Statt localhost sollte als Url der DNS des Servers stehen.
Michel · 5. Januar 2019 um 13:11
Und ist es nicht etwas gefährlich dem gesamten Ordner Schreibrechte zu vergeben?
Danke
Mac · 5. Januar 2019 um 14:47
Wenn die Webseite mit einem dedizierten Benutzerkonto oder der eigenen IIS AppPool-Identität betrieben wird, die Konfiguration (PHP, IIS, Webanwendung) restriktiv gesetzt und die Software immer auf aktuellem Stand ist, kann nicht viel passieren. Im schlimmsten Fall könnte der Angreifer aber nur eingeschränkt Schaden verursachen, er ist auf den Bereich beschränkt, auf den die Sicherheitsidentität Zugriff hat. Um zu verhindern, dass sich Angreifer in die Webseite einnisten und diese für eigene Zwecke mißbrauchen (Verteilen von Schadsoftware, Ausspähen von sensiblen Daten…), verwendet man am besten eine Web Application Firewall (WAF). Über regelmäßige File Integrity Checks kann man zudem unauthorisiertes Ändern der Quelldateien schnell feststellen.
Zu Thema Sicherheit und IIS gibts hier einen Artikel: https://www.privalnetworx.de/windows-server-sicherheit-webserver-iis. Allgemeine Tipps habe ich hier zusammengeschrieben: https://www.privalnetworx.de/windows-server-sicherheit-webserver-grundlagen. Wenn mal Zeit ist, kommt noch ein Artikel über das Absichern von WordPress und PHP.
VG
Mac
Michel · 2. Januar 2019 um 23:45
Konnen Sie vll. ein Beitrag machen wie man PHP am besten Update?
Danke
Mac · 5. Januar 2019 um 14:21
Hallo Michel,
es gibt zwei Möglichkeiten. Entweder legt man für jede PHP Version einen eigenen Ordner an und registriert den PHP Handler jedesmal neu. So kann man im laufenden Betrieb die Version wechseln. Bringt aber auch ein bißchen Menge Arbeit mit sich, da die Konfig immer wieder neu hinterlegt werden muss. Zudem erhöht sich die Gefahr eines Fehlers.
Ich habe es mir zur Angewohnheit gemacht, den PHP-Interpreter ohne explizite Versionsangabe im IIS zu registrieren, die Binaries und php.ini liegen dann in Ordnern mit allgemeinen Namen, bspw. “G:\bin\phpcgi”. Steht ein Update an, wird der IIS in den Wartungsmodus versetzt, sprich eine statische Seite wird kurzzeitig aktiviert. Dann stoppt man die Webseite, tauscht die Binaries aus, startet die Webseite und testet kurz durch. Das Ganze dauert nicht länger als 5 bis 10 Minuten.
VG,
Mac
Faranos · 18. Dezember 2018 um 12:35
Hallo zusammen,
vielen Dank für die Tolle Anleitung. Habe alles so gemacht wie beschrieben und es hat geklappt. Einzig die php.ini musste ich aus der php.ini-production erstellen (umbenannt).
Bin schon dabei und erstelle Inhalte im WordPress, will ein kleines Intranet aufsetzen mit dieser Methode.
Die Seite ist vom Browser über meinen Rechner bei Eingabe der Server IP erreichbar. Jedoch sieht diese sehr merkwürdig aus.
Nachdem ich mit dem Chrome-bug Tool einmal nachgesehen habe ist mir aufgefallen, dass diverse “net::ERR_CONNECTION_REFUSED” Meldungen erscheinen.
Scheinbar kann ich über einen Rechner im Netzwerk keinerlei Scripte und Styles laden. Ich verstehe nur nicht wieso. Am Server sieht die Seite ganz normal aus beim aufruf von http://localhost/index.php
Ich weiß nun nicht genau, wo hier der Fehler liegt. Ich glaube bei den Berechtigungen sollte es nicht liegen, wenn ich die Seite aufrufen kann, sollte ich ja auch die Scripte und styles aufrufen können, nur wird mir das leider immer wieder versagt. Habe es auch mit einem Laptop und einem administrativen Benutzer versucht, jedoch mit dem gleichen Ergebnis.
Wenn ich versuche, eine der css Dateien, die nicht geladen werden können auf einem Netzwerkrechner aufzurufen (bspw.: http://localhost/wp-content/themes/twentynineteen/print.css?ver=1.0) erhalte ich auch eine Fehlermeldung, Webseite ist nicht erreichbar.
Kann mir da wer helfen? Ich sehe den Fehler nicht
Grüße
Fara
Faranos · 20. Dezember 2018 um 14:49
Hey Mac,
ich hab das Problem gefunden.
Hab auf dem Hyper-V das Intranet mit WP eingerichtet und als adresse wie angegeben localhost verwendet. Wenn ich dann über einen Rechner im netzwerk die seite aufrufe, geht er ja auch auf localhost und sucht daher die ressourcen auf dem entsprechenden Rechner und nicht auf dem Server.
Habe in den Einstellungen von WP von localhost auf die IP-Adresse des Servers umgestellt und es funktioniert nun wunderbar. In der Adressleiste verbinde ich mich nun über die IP-Adresse und diese wird auch so angezeigt und nicht mehr als localhost aufgelöst =)
LG
Fara
Mac · 22. Dezember 2018 um 21:18
Hallo Fara,
schön zu hören, dass du die Ursache gefunden hast. Localhost steht für das eigenen Gerät, der Namen wird nach 127.0.0.1 bzw. nach ::1: (IP v6) aufgelöst. Diese Adressen gehören zu den sogenannten Loopback-Adressen (Wiki), die auf sich selbst verweisen. Um also einen schnellen Funktionstest abzuschliessen, ist es daher am einfachsten die auf der Homepage genannten Schritte (auf denselben Rechner) durchzuführen. So wurde es auch im Artikel berücksichtigt: „…Nun öffnet man den Browser auf dem Webserver und ruft http://localhost auf. Natürlich kann die Webseite auch über den Domänennamen von einem beliebigen Rechner aufgerufen werden. …“
Eine IP-Adresse als Url zu verwenden, ist eher unüblich und wird, wenn überhaupt, nur in einer Entwicklungsumgebung eingesetzt. In einem verwalteten Netzwerk existiert ja meist ein DNS oder BIND, über die man dann einen Domänennamen einer (üblicherweise Class C-) IP zuordnen kann.
Schöne Weihnachten!
Mac
MK · 24. Oktober 2018 um 14:31
Hey, habe aktuell den gleichen Fehler wie AD oben beschrieben hat. IUSR und ISS_USRS haben bei mir sogar schon Vollzugriff, aber der Fehler tritt trotzdem immer noch auf. Ich nutze die aktuellsten Versionen der in der Anleitung genannten Software und habe alles so gemacht wie oben. Ich stehe irgenwie auf dem Schlauch…
Habt ihr noch Ideen?
Mac · 27. Oktober 2018 um 16:35
Hi,
der Fehler von AD bzgl. der DB? Oder vermutest du Berechtigungsprobleme? Dann prüfe folgendes:
Die Rechte eines dedizierten TEMP-Verzeichnisses müssen ebenfalls stimmen, da sich dort der opcache beim Start einnistet. Nutzt du ein separates Benutzerkonto, wird dieser der lokalen Gruppenrichtlinie hinzugefügt. Damit diese greifen am besten den Rechner/Server neustarten.
Viel Erfolg
Mac
AB · 22. April 2018 um 17:19
Hmm habe jetzt diese Fehlermeldung beim aufrufen von Einstellungen –> “Allgemein” erhalten:
PHP Warning: Ein unerwarteter Fehler ist aufgetreten. Es scheint etwas bei WordPress.org oder mit dieser Serverkonfiguration nicht zu stimmen. Sollte das Problem weiter bestehen, nutze bitte die Support-Foren. (WordPress konnte keine sichere Verbindung zu WordPress.org herstellen. Bitte kontaktiere deinen Server-Administrator.) in C:\inetpub\wwwroot\wp-admin\includes\translation-install.php on line 65
PHP Warning: Ein unerwarteter Fehler ist aufgetreten. Es scheint etwas bei WordPress.org oder mit dieser Serverkonfiguration nicht zu stimmen. Sollte das Problem weiter bestehen, nutze bitte die Support-Foren. (WordPress konnte keine sichere Verbindung zu WordPress.org herstellen. Bitte kontaktiere deinen Server-Administrator.) in C:\inetpub\wwwroot\wp-admin\includes\translation-install.php on line 65
Zudem beim Zugriff auf die Webseite(Server) (Mit Client) mit der IP wird die Seite ohne Bilder oder überhaupt CSS dargestellt. Beim Anmelde versuch wird man zu Localhost weitergeleitet, was dann garnichts mehr darstellt.
Wisst ihr vielleicht wies dies so erscheint?
Mac · 23. April 2018 um 18:56
Hi,
checke das PHP-eigene Error Logfile. Die Fehler könnten von einer fehlenden PHP-Extension herrühren. Erstelle mal eine Seite mit der phpinfo-Funktion, rufe sie über den Browser auf und prüfe, ob bspw. cURL geladen wurden. Wie man die phpinfo-Funktion nutzt, steht im Abschnitt “Konfiguration PHP”. Weiter kannst du WordPress in den Debug Mode versetzen. Dazu in der wp-config.php die entsprechenden Parameter setzen, siehe https://codex.wordpress.org/Debugging_in_WordPress. Evtl. steht der Server auch hinter einem Web Proxy? Diesen dann auch in der wp-config.php angeben.
Bzgl. deines zweiten Fehler. Prüfe deine Website-Adresse, die du während der Installation eingetragen hast. WordPress leitet dich dahin weiter. Ggf. die Installation erneut durchführen oder trage sie in der wp-config.php ein. Auch hier hilft die WordPress-Doku. Localhost kann nur im Browser deines Webservers aufgerufen werden. Das bei dir nichts angezeigt wird, liegt möglicherweise am ersten Fehler.
Greetz
Mac
AD · 17. April 2018 um 16:48
Hallo Mac
Vielen Dank für deine Anleitung.
Ich erhalte eine kommische fehlermeldung wenn folgendes aufrufe(localhost)http://localhost/wp-admin/setup-config.php:
PHP Warning: Use of undefined constant DB_USER – assumed ‘DB_USER’ (this will throw an Error in a future version of PHP) in C:\inetpub\wwwroot\wp-includes\load.php on line 404 PHP Warning: Use of undefined constant DB_PASSWORD – assumed ‘DB_PASSWORD’ (this will throw an Error in a future version of PHP) in C:\inetpub\wwwroot\wp-includes\load.php on line 404 PHP Warning: Use of undefined constant DB_NAME – assumed ‘DB_NAME’ (this will throw an Error in a future version of PHP) in C:\inetpub\wwwroot\wp-includes\load.php on line 404 PHP Warning: Use of undefined constant DB_HOST – assumed ‘DB_HOST’ (this will throw an Error in a future version of PHP) in C:\inetpub\wwwroot\wp-includes\load.php on line 404
Stimmt noch etwas mit der Datenbank nicht oder hättest du vielleicht hier eine Idee?
AD · 18. April 2018 um 18:38
(Wahrscheinlich habe ich hier die Falsche PHP Version installiert)
AK · 18. April 2018 um 20:03
Hatte den gleichen Fehler: Auf das WordPress-Verzeichnis muss der Benutzer “IUSR” zusätzlich das Zugriffsrecht “Ändern” bekommen. Vollzugriff für den Benutzer “IIS_USRS” alleine reicht nicht.
AK · 16. April 2018 um 11:00
Ich habe inzwischen OPCache aktiviert, zusätzlich aber auch WinCache (wird so auf PHP.net empfohlen). Ab Version 2.0.0.0 macht WinCache keinen PHP-Code-Cache mehr, weil das jetzt OPCache übernimmt. WinCache cached jedoch noch die normalen Dateien. Man braucht somit beides für Maximal-Caching.
Mac · 19. April 2018 um 10:28
Moin,
klar kann man statt des IIS Cache auch WinCache nehmen. Ich bevorzuge lieber das native IIS-Modul anstelle von WinCache. Eine Software weniger, die ich zusätzlich verwalten und pflegen muss.
Mac
AK · 14. April 2018 um 13:09
Danke für diese ausführliche Antwort… Würde dann auf OPCache umstellen.
Für OPCache gibt es viele Parameter in der PHP.INI. Welche sollte man aktiveren (“;” entfernen) bzw. wie einstellen? Welche Werte empfiehlst Du?
Welches WP-Caching-Plugin ist empfehlenswert? WPFC? Hast Du gemessen was diese Plugins bringen?
Mac · 19. April 2018 um 11:13
Die Konfig vom OPCache anzupassen, ist eine Wissenschaft für sich. Zumal die Doku ziemlich dünn ist. Ich habe mich u.a. an diesen Beiträgen orientiert:
Wenn man sicherstellt, das nach WordPress Updates der IIS Worker Prozess neugestartet wird, kann man sämtliche Prüfroutinen deaktivieren. Hier ein Beispiel:
opcache.memory_consumption=160M
opcache.interned_strings_buffer=8
opcache.max_accelerated_files = 5477
opcache.max_wasted_percentage=3
opcache.use_cwd=0
opcache.validate_timestamps=0
opcache.revalidate_freq=0
opcache.revalidate_path=0
opcache.save_comments=0
opcache.load_comments=0
opcache.fast_shutdown=1
opcache.enable_file_override=1
;opcache.optimization_level=0xffffffff
opcache.inherited_hack=0
opcache.blacklist_filename="list.txt"
opcache.consistency_checks=0
opcache.force_restart_timeout=120
opcache.log_verbosity_level=2
opcache.preferred_memory_model=win32
opcache.mmap_base=0x20000000
opcache.file_cache_only=0
opcache.huge_code_pages=0
opcache.enable_slow_optimizations=0
Über die Blacklist-Datei lassen sich stetig änderte PHP-Skripte vom Cache ausnehmen. Zudem sollte man den Realpath Cache vergrößern:
realpath_cache_size = 2048K
realpath_cache_ttl = 7200
Für WordPress kann ich Autoptimze empfehlen. Es macht gleich drei Dinge, es führt alle Style- und Skriptdateien zusammen und optimiert sie, speichert dann das Ergebnis als statische Datei. Wird die Seite erneut aufgerufen, lädt es nur noch diese Ressourcen, was schneller geht. Über IIS werden diese Daten dann wiederum gecacht. Das Konstrukt funktioniert sehr gut. Ich konnte bisher keine Probleme veralteter Daten feststellen, was bei anderen Modulen durchaus passieren kann. Allerdings muss man sich für die Konfig etwas Zeit nehmen und sie der eigenen Webseite anpassen. Vorteil ist, Google Pagespeed bewertet die Webseite besser, da die Ressourcen zusammengeführt werden. Das mag Google. 🙂
Viel Erfolg
Mac
AK · 13. April 2018 um 16:44
Zuerst Danke für diese tolle Anleitung:
Ist es sinnvoll php_wincache.dll als PHP-Extention zu installieren?
Mac · 13. April 2018 um 19:33
Lange Ladezeiten von PHP-Webanwendungen werden in der Regel durch Kompilieren der PHP-Skripte verursacht. Bei vielen WordPress-Erweiterungen oder komplexen Themes kann das viel Zeit in Anspruch nehmen. Seit PHP 5.5.0 wird standardmäßig die OPCache-Erweiterung ausgeliefert. Diese führt PHP-Skripte beim ersten Aufruf aus und hält sie dann im Arbeitsspeicher vor. Ein bereits kompiliertes PHP-Skript wird dann aus dem schnellen RAM geladen. Das ist ein enormer Performance-Schub. Von daher lautet meine Antwort nein, die Wincache-Erweiterung ist nicht notwendig, wenn OPCache genutzt wird. Zumal das Wincache-Modul meist, meiner Erfahrung nach, nicht kompatibel zu den neuesten PHP-Versionen ist. Sprich, nach einem frisch erschienenen PHP-Update muss man noch etwas auf eine entsprechende Wincache-Version warten.
Hinzu kommt, dass OPCache getweakt werden kann, um noch mehr Performance herauszukitzeln. So lassen sich bestimmte Prüfroutinen, wie das Vergleichen der Datei-Zeitstempel, anpassen oder ganz deaktivieren. Weiter bietet es eine Failback-Lösung, wenn der OPCache voll ist.
Ich habe sehr, sehr viel Zeit damit verbracht, die verschiedensten Cache-Module zu testen. Dabei konnte ich keinerlei Vorteile gegenüber OPCache messen. Mit dem OPCache-Modul ist man bestens gerüstet. In Kombination mit browser- und serverseitigen, statischen Cache (bspw. für CSS- oder JS-Dateien) und Caching-Plugins für WordPress, kann man einiges an Geschwindigkeit gewinnen.
Viele Grüße
Mac
Damian · 3. Oktober 2017 um 11:32
FYI: Ich konnte den Fehler eruieren. Wäre evtl. noch wertvoll zu ergänzen.
Im PHP.ini File musste der Pfad zum Extensions-Ordner angegeben werden. Ohne diese Angabe wurde die Extensions nicht geladen und die Verbindung zur DB konnte nicht hergestellt werden.
; Directory in which the loadable extensions (modules) reside.
; http://php.net/manual/en/ini.core.php
; extension_dir = “./”
; On windows:
extension_dir = “C:PHPv7.1ext”
Mac · 8. Oktober 2017 um 15:22
Hallo Damian
Per default verwendet PHP unter Windows den Unterordner “ext”, weswegen ich das nicht explizit angab. Evtl. fehlte die Umgebungsvariable “PHPRC” – die zwar den Speicherort der Konfiguration angibt, möglicherweise aber auch zur Lokation des PHP-Verzeichnisses und deren Unterordner genutzt wird – in den FastCGI-Einstellungen des IIS. Der Vollständigkeit halber habe ich deinen Hinweis in die Doku mit aufgenommen. thx
Mac
Damian · 29. September 2017 um 14:43
Vielen Dank für die tolle Anleitung. Habe alles Schritt für Schritt so eingerichtet.
Leider gibt es bei der Installation von WordPress folgenden Fehler bei mir
1. Server Error 500
2. Beim Reload erscheint folgende Meldung “ERROR: “Table Prefix” must not be empty.”
Das wp-config.php File wird nicht erstellt.
Was könnte das sein?