Schlagwort-Archive: Xampp

Besser als XAMPP: Docker-basierte Entwicklungsumgebung

Traditionelle lokale Entwicklungsumgebungen wie XAMPP sind seit Jahren beliebt, da sie einfach einzurichten und zu verwenden sind. Allerdings stoßen sie schnell an ihre Grenzen, wenn es um Platzersparnis, Geschwindigkeit und Flexibilität geht. Hier kommt eine Docker-basierte Lösung ins Spiel, die XAMPP in vielerlei Hinsicht überlegen ist.

Platzersparnis und Geschwindigkeit

Mit Docker können Entwicklungsumgebungen schlank gehalten werden. Der gesamte Stack – bestehend aus Apache, MariaDB und Mailhog – wird in einem einzigen Container betrieben. Das spart nicht nur Speicherplatz, sondern sorgt auch für eine bemerkenswerte Steigerung der Geschwindigkeit. Der Start der gesamten Umgebung dauert nur wenige Sekunden, im Gegensatz zu den längeren Ladezeiten bei XAMPP.

Einfachheit des Buildings

Das Building eines Docker-Containers ist einfach und schnell erledigt. Mit einem einzigen Befehl wird der komplette Stack erstellt und konfiguriert. Im Gegensatz zu XAMPP müssen keine zusätzlichen Softwarepakete heruntergeladen und installiert werden. Eine Datei (dockerfile) regelt alle notwendigen Installationen und Konfigurationen:

FROM debian:latest

RUN apt-get update && apt-get install -y apache2 mariadb-server mailhog supervisor
COPY supervisord.conf /etc/supervisor/conf.d/supervisord.conf
COPY init.sh /usr/local/bin/init.sh
RUN chmod +x /usr/local/bin/init.sh

CMD ["/usr/bin/supervisord"]

In diesem Dockerfile werden die Anweisungen zum Erstellen eines Docker-Containers beschrieben, der auf einem Debian-basierten Betriebssystem läuft und verschiedene Dienste wie Apache, MariaDB und Mailhog enthält. Hier ist eine Erklärung, was in jedem Schritt passiert:

1. FROM debian:latest

  • Beschreibung: Legt das Basis-Image fest, auf dem der Container aufbaut. In diesem Fall wird die neueste Version des Debian-Betriebssystems verwendet.

2. RUN apt-get update && apt-get install -y apache2 mariadb-server mailhog supervisor

  • Beschreibung: Führt zwei Befehle in einer Zeile aus:
  1. apt-get update: Aktualisiert die Liste der verfügbaren Pakete und deren Versionen.
  2. apt-get install -y apache2 mariadb-server mailhog supervisor: Installiert die Pakete apache2 (Webserver), mariadb-server (Datenbankserver), mailhog (E-Mail-Testing-Tool) und supervisor (Prozesssteuerungstool). Der Schalter -y bestätigt automatisch alle Aufforderungen zur Installation der Pakete.

3. COPY supervisord.conf /etc/supervisor/conf.d/supervisord.conf

  • Beschreibung: Kopiert die Datei supervisord.conf aus dem lokalen Verzeichnis in das Verzeichnis /etc/supervisor/conf.d/ im Container. Diese Datei enthält Konfigurationen für Supervisor, um die Dienste zu steuern, die im Container ausgeführt werden sollen.

4. COPY init.sh /usr/local/bin/init.sh

  • Beschreibung: Kopiert das Skript init.sh in das Verzeichnis /usr/local/bin/ im Container. Dieses Skript wird später zur Initialisierung der Dienste verwendet.

5. RUN chmod +x /usr/local/bin/init.sh

  • Beschreibung: Ändert die Berechtigungen der Datei init.sh, um sie ausführbar zu machen. Dies ist notwendig, damit das Skript später im Container ausgeführt werden kann.

6. CMD ["/usr/bin/supervisord"]

  • Beschreibung: Legt den Standardbefehl fest, der ausgeführt wird, wenn der Container gestartet wird. In diesem Fall wird supervisord ausgeführt, um die in supervisord.conf definierten Dienste (wie Apache, MariaDB und Mailhog) zu starten und zu überwachen.

Zusammengefasst erstellt dieses Dockerfile einen Container, der auf Debian basiert, die benötigten Pakete installiert, Konfigurationsdateien kopiert und Supervisor verwendet, um die verschiedenen Dienste im Container zu verwalten.

Schnelleres Deployment

Mit Docker wird das Deployment zur Leichtigkeit. Es ist möglich, die gesamte Umgebung in kürzester Zeit auf einem anderen System zu replizieren. Es genügt, den Container auf einem anderen Rechner zu starten, und die Entwicklungsumgebung ist sofort einsatzbereit – ohne zusätzliche Installationen und Konfigurationen. Die Dateien build-container.bat und start-container.bat sorgen für einen nahtlosen Startprozess.

Den Build starten

Die build-container.bat Datei ist ein Batch-Skript für Windows, das verwendet wird, um das Docker-Image zu erstellen. Hier ist eine Erklärung, was in dieser Datei passiert:

Inhalt von build-container.bat

docker build -t my-fullstack-app .
Erklärung
  • docker build -t my-fullstack-app .
  • docker build: Dieser Befehl erstellt ein Docker-Image aus einem Dockerfile.
  • -t my-fullstack-app: Mit dem -t (Tag) Flag wird ein Name und optional ein Tag für das erstellte Image angegeben. In diesem Fall wird das Image als my-fullstack-app benannt.
  • .: Der Punkt gibt das Verzeichnis an, in dem das Dockerfile liegt. In diesem Fall ist es das aktuelle Verzeichnis.

Das Skript baut ein Docker-Image namens my-fullstack-app aus dem Dockerfile im aktuellen Verzeichnis. Sobald dieser Befehl ausgeführt wird, durchläuft Docker die Schritte im Dockerfile, um das Image zu erstellen. Dieses Image kann dann verwendet werden, um Container zu starten.

Gleichzeitige Entwicklung und Testing

Ein weiterer Vorteil der Docker-basierten Umgebung ist die Möglichkeit, lokale Änderungen in Echtzeit zu verfolgen. Die Daten werden direkt von einem lokalen Verzeichnis in den Container gemountet:

docker run -d -p 8080:80 my-fullstack-app

Damit werden Änderungen sofort übernommen, ohne dass der Container neu gebaut werden muss. Das bedeutet effizienteres Arbeiten und schnelleres Testen von neuen Funktionen.

Vorteile der Verwendung einer Batch-Datei für docker run

Die Verwendung einer Batch-Datei für den docker run Befehl bietet mehrere Vorteile, insbesondere für Entwickler, die sich einen effizienteren und konsistenteren Workflow wünschen:

  1. Wiederholbarkeit: Mit einer Batch-Datei können Sie den Container jederzeit mit den exakt gleichen Parametern starten. Das verhindert Fehler, die bei der manuellen Eingabe des Befehls passieren können.
  2. Zeitersparnis: Anstatt sich jedes Mal an alle notwendigen Parameter und Optionen zu erinnern, können Sie den Container mit einem einzigen Doppelklick oder einem kurzen Befehl im Terminal starten. Das spart wertvolle Zeit.
  3. Konsistenz: Durch die Automatisierung des Startvorgangs stellen Sie sicher, dass der Container immer in der gleichen Umgebung läuft, was für die Entwicklung und Fehlersuche sehr wichtig ist.
  4. Leichteres Deployment: Wenn Sie den Container auf einem anderen System starten möchten, können Sie die Batch-Datei einfach weitergeben. Der Empfänger muss lediglich die Datei ausführen, ohne sich um die genauen Details des docker run Befehls kümmern zu müssen.

Aufbau der start-container.bat

Die Batch-Datei start-container.bat enthält den folgenden Befehl:

@echo off
docker run -d -p 8080:80 -p 3306:3306 -p 8025:8025 -p 1025:1025 -v %cd%/src:/var/www/html my-fullstack-app
Was passiert hier?
  • Automatischer Start des Containers: Der docker run Befehl startet den Container my-fullstack-app. Durch das -d Flag wird der Container im Hintergrund ausgeführt.
  • Port-Mapping: Mit den -p Optionen werden die Ports des Hostsystems mit denen des Containers verknüpft. Dadurch werden der Webserver, die Datenbank und Mailhog korrekt verfügbar gemacht.
  • Direkter Zugriff auf den Quellcode: Das -v Flag sorgt dafür, dass das lokale Verzeichnis ./src in den Container gemountet wird. Dadurch werden Änderungen an den Dateien in ./src sofort im Container sichtbar, was die Entwicklungszeit verkürzt.
  • Einfache Ausführung: Durch die Batch-Datei muss man sich nicht die genauen Befehle und Parameter merken. Ein Doppelklick auf die Datei reicht, um den Container mit allen benötigten Einstellungen zu starten.

Die Batch-Datei vereinfacht und beschleunigt den Entwicklungsprozess erheblich. Sie ermöglicht es, den Docker-Container mit einem einzigen Klick oder Befehl im Terminal zu starten und stellt sicher, dass der Container immer mit den korrekten Einstellungen ausgeführt wird. Dies ist besonders praktisch, wenn Sie mehrere Projekte oder Umgebungen verwalten und immer wieder die gleichen Schritte ausführen müssen.

Einfache Einarbeitung

Die Einarbeitung in Docker ist genauso einfach, wenn nicht sogar einfacher, als der Einstieg in XAMPP und andere lokale Entwicklungsumgebungen. Mit gut dokumentierten Dateien wie init.sh, die sich um die automatische Konfiguration von Diensten wie Apache und MariaDB kümmert, wird der Einstieg erleichtert:

#!/bin/bash

# bind-address ändern auf 0.0.0.0, um remote Zugriff zu ermöglichen
sed -i 's/^bind-address\s*=.*$/bind-address = 0.0.0.0/' /etc/mysql/mariadb.conf.d/50-server.cnf

# Starte MariaDB
service mariadb start

# Warte darauf, dass MariaDB bereit ist
until mysqladmin ping &>/dev/null; do
  echo "Warte auf MariaDB..."
  sleep 1
done

# Erstelle Datenbank und Benutzer
# erstellt User: user1 mit Passwort: Geheim123
mysql -e "CREATE USER IF NOT EXISTS 'user1'@'%' IDENTIFIED BY 'Geheim123';"
mysql -e "GRANT ALL PRIVILEGES ON *.* TO 'user1'@'%';"
mysql -e "FLUSH PRIVILEGES;"

# Apache Konfiguration automatisch anpassen
sed -i 's/DirectoryIndex .*/DirectoryIndex index.php index.html/' /etc/apache2/mods-enabled/dir.conf

# Apache neu starten, um die Änderungen zu übernehmen
service apache2 restart

Der Supervisor-Dienst

Die supervisord.conf Datei konfiguriert den Supervisor-Dienst, der im Container verwendet wird, um mehrere Prozesse gleichzeitig zu starten und zu überwachen. Supervisor ist ein Prozesssteuerungswerkzeug, das hilfreich ist, um sicherzustellen, dass Dienste wie Apache, MariaDB und Mailhog kontinuierlich im Container laufen.

[supervisord]
nodaemon=true

[program:apache2]
command=/usr/sbin/apache2ctl -D FOREGROUND
autostart=true
autorestart=true
stdout_logfile=/var/log/apache2.log
stderr_logfile=/var/log/apache2_err.log

[program:mariadb]
command=/usr/bin/mysqld_safe
autostart=true
autorestart=true
stdout_logfile=/var/log/mariadb.log
stderr_logfile=/var/log/mariadb_err.log

[program:mailhog]
command=/usr/local/bin/MailHog
autostart=true
autorestart=true
stdout_logfile=/var/log/mailhog.log
stderr_logfile=/var/log/mailhog_err.log

Erklärung der Abschnitte
  1. [supervisord]:
    • nodaemon=true: Führt Supervisor im Vordergrund aus, was in einem Docker-Container erforderlich ist, damit der Container nicht sofort beendet wird.
  2. [program:apache2]:
    • command=/usr/sbin/apache2ctl -D FOREGROUND: Startet den Apache-Webserver im Vordergrundmodus.
    • autostart=true: Startet Apache automatisch, wenn der Container gestartet wird.
    • autorestart=true: Startet Apache automatisch neu, falls es unerwartet beendet wird.
    • stdout_logfile und stderr_logfile: Speichert die Standardausgabe und Fehlerausgabe von Apache in Log-Dateien.
  3. [program:mariadb]:
    • command=/usr/bin/mysqld_safe: Startet den MariaDB-Dienst im sicheren Modus.
    • Die anderen Optionen sind ähnlich wie bei Apache und sorgen dafür, dass MariaDB automatisch gestartet und überwacht wird.
  4. [program:mailhog]:
    • command=/usr/local/bin/MailHog: Startet den MailHog-Service, der zum Testen von E-Mails verwendet wird.
    • Die weiteren Optionen entsprechen denen für Apache und MariaDB und sorgen für den automatischen Start und Neustart von MailHog.

Durch die Verwendung von Supervisor wird sichergestellt, dass alle drei Dienste (Apache, MariaDB, und MailHog) im Container parallel laufen und überwacht werden. Wenn einer dieser Dienste abstürzt, wird er automatisch neu gestartet, was die Zuverlässigkeit des Containers verbessert.

Die Dateien in der Übersicht

Hier ist eine Übersicht der Verzeichnisstruktur und Dateien:

/project-directory
│
├── build-container.bat
├── dockerfile
├── init.sh
├── start-container.bat
├── supervisord.conf
├── src/
│   └── (die Webanwendungsdateien)
  • build-container.bat: Skript zum Bauen des Docker-Containers.
  • dockerfile: Definiert die Container-Umgebung und installierte Software.
  • init.sh: Initialisierungsskript, das während des Container-Starts ausgeführt wird.
  • start-container.bat: Skript zum Starten des Docker-Containers mit den benötigten Ports und Volumes.
  • supervisord.conf: Konfigurationsdatei für Supervisor, um Dienste wie Apache, MariaDB und Mailhog zu verwalten.
  • src/: Verzeichnis, das die Quellcodes deiner Webanwendung enthält.

Fazit

Im Vergleich zu XAMPP bietet eine Docker-basierte Entwicklungsumgebung zahlreiche Vorteile. Sie ist platzsparender, schneller im Start und Betrieb, einfacher zu konfigurieren und erleichtert das Deployment. Die Investition in die Einarbeitung lohnt sich, denn sie ermöglicht effizienteres Arbeiten und schnellere Entwicklungsprozesse.

ESLint zum Testen von JavaScript in Symfony-Projekten mit npm unter XAMPP installieren

Diese Anleitung beschreibt, wie ESLint in einem Symfony-Projekt verwendet werden kann, um JavaScript-Code zu testen. Die Schritte umfassen die Installation von npm unter Windows mit XAMPP und die Integration von ESLint in ein Symfony-Projekt.

Schritt 1: Node.js und npm unter Windows installieren

  1. Node.js-Installer herunterladen:
  • Besuche die Node.js-Website.
  • Wähle die LTS-Version (Long Term Support) für eine stabilere Umgebung.
  • Lade den Installer für Windows herunter.
  1. Node.js installieren:
  • Führe die heruntergeladene .msi-Datei aus.
  • Folge den Anweisungen des Installationsassistenten. Node.js und npm werden automatisch installiert. Die Default-Einstellungen sind ausreichend.
  1. Installation überprüfen:
  • Öffne die Eingabeaufforderung (Cmd) oder PowerShell.
  • Überprüfe die Node.js-Version mit node -v.
  • Überprüfe die npm-Version mit npm -v.

Schritt 2: Integration von npm in ein XAMPP-Projekt

  1. Projektverzeichnis auswählen:
  • Öffne die Eingabeaufforderung oder PowerShell.
  • Navigiere zum Projektverzeichnis unter C:\xampp\htdocs\dein-projekt.
  1. npm-Projekt initialisieren:
  • Führe npm init aus, um ein neues npm-Projekt zu initialisieren. Eine package.json-Datei wird erstellt.
  • Die Standardeinstellungen können durch Drücken der Eingabetaste akzeptiert werden.
  1. ESLint als Entwicklungsabhängigkeit installieren:
  • Installiere ESLint mit dem folgenden Befehl: npm install eslint --save-dev
  • ESLint wird im node_modules-Ordner des Projekts installiert.

Schritt 3: ESLint konfigurieren und verwenden

  1. ESLint konfigurieren:
  • Führe den Befehl npx eslint --init aus, um ESLint in deinem Projekt zu konfigurieren.
  • Beantworte die Fragen, um die Konfiguration den Projektanforderungen anzupassen. Eine .eslintrc.json-Datei wird erstellt.

Inhalt der eslint.config.mjs

import globals from "globals";
import pluginJs from "@eslint/js";


export default [
  {files: ["**/*.js"], languageOptions: {sourceType: "script"}},
  {languageOptions: { globals: globals.browser }},
  pluginJs.configs.recommended,
];

Zusammenarbeit mit jQuery

Um überflüssige, genauer gesagt „falsche“ Fehler zu beheben, muss in der ESLint-Konfiguration angegeben werden, dass jQuery verwendet wird. Ansonsten gibt es gleich Hunderte von „error ‘$’ is not defined“ Meldungen, weil ESLint nicht weiß, dass $ aus der jQuery-Bibliothek stammt.

import globals from "globals";
import pluginJs from "@eslint/js";

export default [
  {
    files: ["**/*.js"],
    languageOptions: {
      sourceType: "script",
      globals: {
        ...globals.browser,
        $: "readonly",
        jQuery: "readonly",
      },
    },
  },
  pluginJs.configs.recommended,
];

  1. JavaScript-Code mit ESLint überprüfen:
  • Verwende den folgenden Befehl, um JavaScript-Dateien im Projekt zu überprüfen: npx eslint path/to/yourfile.js
  • ESLint überprüft die Datei auf mögliche Fehler und gibt entsprechende Meldungen aus.
  • Ich selbst nutze am liebsten folgenden Befehl, um alle Javascript-Dateien auf einmal zu prüfen:
npx eslint .\public\js\
  1. Automatische Korrektur von Fehlern:
  • Fehler können automatisch korrigiert werden, indem --fix an den Befehl angehängt wird: npx eslint path/to/yourfile.js --fix

Schritt 4: ESLint in den Entwicklungsworkflow integrieren

  1. npm-Skripte für ESLint erstellen:
  • In der package.json können npm-Skripte definiert werden, um ESLint leicht im Entwicklungsprozess zu verwenden. Zum Beispiel: "scripts": { "lint": "eslint . --ext .js,.jsx", "lint:fix": "eslint . --ext .js,.jsx --fix" }
  • Diese Skripte können dann mit npm run lint oder npm run lint:fix ausgeführt werden.

Mit diesen Schritten ist ESLint in ein Symfony-Projekt integriert und kann verwendet werden, um JavaScript-Code zu überprüfen und zu verbessern. Die Verwendung von ESLint sorgt für sauberen, fehlerfreien Code, der den Best Practices entspricht.

Quick: SquirrelMail und XAMPP lokal installieren und testen

Quick: SquirrelMail und XAMPP lokal installieren und testen

Wer Applikationen programmiert, die auch Mails verschicken, möchte dies natürlich auch lokal testen. Dazu lohnt es sich, den Webmail Client »SquirrelMail« zu installieren. Dieser Artikel ergänzt mein XAMPP-Tutorial.

1. laden http://squirrelmail.org/download.php

2. entpacken nach »c:\Programme\xampp\htdocs\squirrelmail\« und anlegen von »c:\Programme\xampp\htdocs\squirrelmail\attach\«

3. kopieren der Konfigurationsvorlage »c:\Programme\xampp\htdocs\squirrelmail\config\config_default.php« nach »c:\Programme\xampp\htdocs\squirrelmail\config\config.php«

4. editieren von »c:\Programme\xampp\htdocs\squirrelmail\config\config.php«


$domain = 'localhost';

$data_dir = 'c:\\Programme\\xampp\\htdocs\\squirrelmail\\data\\';

$attachment_dir = 'c:\\Programme\\xampp\\htdocs\\squirrelmail\\attach\\';

$imapServerAddress = 'localhost';

$smtpServerAddress = 'localhost';

5. Testen

User anlegen in Mercury. In der Admin-Oberfläche: Configuration|Manage Local Users…|Add einen User anlegen. User in Mercury meint die eigentlichen Mail-Empfänger.

Einwählen: http://localhost/squirrelmail/src/login.php

Name: Username (ohne @localhost)

Passwort: (wie festgelegt)

Mail zusenden: http://localhost/xampp/mailform.php (Adressat=Ihr neuer Nutzer PLUS @locahost). Die Mail müsste augenblicklich in SquirrelMail erscheinen, eventuell müssen Sie noch »Check mail« klicken.

WordPress und XAMPP tunen

XAMPP ist lokal und in der Standardausführung nicht sehr schnell. Daher lohnt es sich, Hand anzulegen.

Zunächst müssen wir wissen, wie langsam (oder schneller) unser System läuft. Dazu editieren Sie die WordPress Template Datei »footer.php«:

Direkt über </body> fügen Sie Folgendes ein:

<?php echo $wpdb->num_queries; ?> database queries in <?php timer_stop(1); ?>

Spielen Sie am besten ein bisschen herum, um ein Gefühl für »gute« Werte und Zeiten zu erhalten.

Laden und aktivieren Sie verschiedene Plugins, um zu prüfen, wie unterschiedlich sich die Werte entwickeln.

Bei besonders vielen SQL-Statements (auch Queries genannt), lohnt es sich, die Plugins schrittweise zu deaktivieren und zu prüfen, ob schlecht programmierte Plugins mit zu vielen Datenbankabfragen nicht durch Alternativen ersetzt werden können
Besonders verdächtig sind meiner Erfahrung nach Plugins, die die letzten Kommentare oder vergleichbare Artikel anzeigen, da diese bei jedem Aufbau der Seite generiert werden (wenn kein Cache läuft).

Testen Sie auf alle Fälle ein Cache-Plugin (ich empfehle wegen der einfachen Wartbarkeit wp-supercache). Ein Cache-System speichert bereits generierte HTML-Seiten in einen Zwischenspeicher ab, so dass diese nicht immer wieder neu generiert werden müssen.
Für Entwickler empfehle ich noch das Plugin »Debug Queries«. Dieses listet alle generierten SQL-Statements auf der Frontend-Seite auf. Dazu muss noch in der Datei »wp-config.php« was angepasst werden:



define(‚SAVEQUERIES‘, true);

Empfohlene Einstellungen

php.ini

Ort: C:\Programme\xampp\php\php.ini


memory_limit = 1024M

my.ini

Ort: C:\Programme\xampp\MySQL\bin\my.ini



key_buffer = 256M

max_allowed_packet = 16M

table_cache = 512

sort_buffer_size = 4M

read_buffer_size = 4M

read_rnd_buffer_size = 8M

net_buffer_length = 2M

innodb_buffer_pool_size = 256M

Wenn Sie merken, dass der Server langsam ist, können Sie in phpMyAdmin unter »Status« überprüfen, welche Parameter momentan Probleme bereiten. Diese werden rot hinterlegt. Anschließend sollte der Speicherplatz dafür erhöht werden.

Zur gezielteren Analyse muss man natürlich WP-Supercache zumindest für Admins deaktivieren, weil die Ergebnisse sonst verfälscht werden.

Und nicht vergessen: Es klappt nur, wenn man Apache und/oder MySQL nach jeder Änderung neu startet.

Zum Nachschlagen

XAMPP – Entwicklungsumgebung für Apache, MySQL, PHP auf Windows – Tutorial

XAMPP ist eine Distribution von Apache, MySQL, PHP und Perl, die sich (fast) per Knopfdruck installieren und wenig Wünsche übrig lässt.

Ich zeige hier eine kleine Anleitung, die ich selbst auch nutze bei Neuinstalationen. Den Abschluss bildet eine Sammlung von Links Hinweisen zu nützlichen Ergänzungen.

Schritt 1 – Installation

Xampp-Home Xammp-Windows

Ich empfehle die EXE-Datei. Wir können beruhigt nach c:\programme\xampp installieren. Es ist nicht notwendig, dass C-Verzeichnis vollzumüllen. Alle Programme und zusätzliche »Addons« laufen dort problemlos: Eine Fehlermeldung (»xampp component status check failure«) beim Aufruf des XAMPP Control Panel kann ignoriert werden. Wen diese Meldung nervt, kann Folgendes tun:

  1. Registry Editor starten und den Schlüssel
  2. HKEY_LOCAL_MACHINE\SOFTWARE\xampp\Install_Dir aufrufen
  3. Den dort eingetragenen Wert ändern zu: »C:\xampp«. Damit sollte die unglückselige Fehlermeldung nicht mehr auftauchen.

Die Meldungen der Firewall sollten sie akzeptieren, sonst tauchen Sie immer wieder auf. Warum die Firewall von Microsoft Zugriffe auf den eigenen Rechner unterbindet, kann wohl nur Bill Gates selbst erklären.

Schritt 2 – Es geht los

Wir starten das XAMPP Control Panel. Die Funktionen dort sollten selbsterklärend sein. Wenn man die wichtigsten Komponenten Apache und MySQL gestartet hat, kann man das Control Panel in den Hintergrund bzw. in die Systray wegklicken.

Die Konfiguration von XAMPP und seinen Komponenten erfolgt in verschiedenen Konfigurationsdateien. Eine Auflistung findet sich weiter unten.

Wir prüfen jetzt, ob alles erstmal geklappt hat. Dazu starten wir Apache, MySQL und Mercury. Mercury ist ein Mailserver, den man nicht unbedingt braucht, aber die Funktionsfähigkeit sollte wenigstens einmal getestet werden.

Nehmen Sie ihren Browser und laden Sie die URL »http://localhost«. »Localhost« ist eine Abkürzung für ihren eigenen Rechner bzw. für die Adresse ihres eigenen Rechners. Sie können auch »http://127.0.0.1« eingeben.

Wenn der erste Aufruf erfolgreich war, dann würde ich jetzt einige Änderungen in der php.ini (der Konfigurationsdatei für den PHP-Interpreter) vornehmen. Die Datei befindet sich unter »C:\Programme\xampp\php\php.ini«.

Passen Sie dort an bzw. entkommentieren folgendes:

  • short_open_tag = On
  • extension=php_curl.dll
  • variables_order = “EGPCS”
  • error_reporting = E_ALL

Damit die Änderungen Wirkung zeigen, muss Apache natürlich neu gestartet werden. Das erledigen Sie über das Control Panel.

Sie sollten auch nicht vergessen, den Sicherheitscheck auszuführen. Die Punkte dort sind selbsterklärend. Im Allgemeinen sollte es aber reichen, wenn Sie für MySQL einen root-Nutzer anlegen.

Schritt 3 – Warm werden mit XAMPP

Einige wichtige Standardprogramme bzw. Webapplikationen werden schon mitgeliefert. Am Anfang dürfte das wichtigste wohl phpMyAdmin sein. Hierbei handelt es sich um den am weitesten verbreiteten Web-Client zur Verwaltung von MySQL-Servern. Bei XAMPP wird er gleich mit ausgeliefert http://localhost/phpmyadmin/.

Den »root«-Nutzer sollte man tunlichst nur nehmen, um Datenbanken oder neue Nutzer anzulegen. Für neue Projekte, bspw. WordPress, erzeugt man einen Nutzer und wählt die Option »Erstelle eine Datenbank mit gleichem Namen und gewähre alle Rechte«.

Schritt 4 – Einrichtung des Mailserver Mercury

Diesen Mailserver kann man nutzen, wenn man Applikationen schreibt, die Mails verschicken, z.B. Newsletter. Allerdings ist dieser Server – wie das gesamte XAMPP-Projekt auf Windows – nur für Entwicklungsumgebungen ausgelegt. Auf Produktivsystemen sollte man m.M. nach lieber auf Linux bzw. LAMPP zurückgreifen.

Bei richtiger Programmierung sollte man ohne Probleme alle Skripte in PHP auf allen System, egal ob Windows mit Internet Information Server (IIS) oder Linux mit Apache nutzen können.

Den Admin-Bereich von Mercury erreicht man über den Admin-Button in XAMPP Control Panel. Hier gehen wir folgende Schritte durch:

  1. Mercury-Webserver deaktivieren: Mercury|Configuration|Protocol Modules|MercuryB HTTP Haken entfernen und Mercury Neu starten
  2. Configuration|Mercury Core Modul|General Internetname for this system: localhost
  3. local mailbox directory path: C:\PROGRAMME\XAMPP\MERCURYMAIL\MAIL\~N
  4. Username of Postmaster: Admin
  5. Configuration|Mercury Core Modul local domains: localhost, localhost.net, localhost.com, localhost.org
  6. Configuration|Mercury Core Modul|General: Suppress validation of »FROM« field (Haken setzen)
  7. Configuration|MercuryS SMTP Server|General: Listen on TCP/IP Port:25
  8. IP-Interface to Use: 127.0.0.1
  9. Configuration|MercuryS SMTP Server|Connection Control: Add restriction: Allow Connections 127.0.0.1-127.0.0.1 (keine Haken setzen)
  10. Configuration|MercuryS POP Server|General: Listen on TCP/IP Port:110
  11. IP-Interface to Use: 127.0.0.1
  12. Configuration|MercuryS POP Server|Connection Control: Add restriction: Allow Connections 127.0.0.1-127.0.0.1 (keine Haken setzen)
  13. Configuration|MercuryI IMAP4 Server|General: Listen on TCP/IP Port:143
  14. IP-Interface to Use: 127.0.0.1
  15. Configuration|MercuryI MAP4 Server|Connection Control: Add restriction: Allow Connections 127.0.0.1-127.0.0.1 (keine Haken setzen)

Auch wenn Mercury nicht danach verlangt, sollte man nach Änderungen in der Konfiguration den Server nochmal neu starten.

Damit nun über XAMPP auch tatsächlich Mails verschickt werden können, muss man in der php.ini noch etwas nachtragen.

Suchen Sie nach »[mail function]« und ergänzen folgendes:

  • SMTP=localhost
  • smtp_port=25
  • sendmail_from = admin@localhost

Schritt 5 – Wohin mit den Dateien?

Wenn Sie ein neues Web-Projekt starten, dann legen Sie einen neuen Ordner in »c:\Programme\xampp\htdocs\« an und kopieren dorthin alle ihre Dateien.

Anhang

Wichtige Programme

  • Notepad++ – Ein sehr guter  Gratis-Editor mit Projektverwaltung
  • HeidiSQL – Ein Desktop-Client der ein schnelleres Arbeiten mit MySQL-Datenbanken ermöglichkeit als phpMyAdmin
  • mysqldumper – Skriptsammlung zum Sichern und Einspielen kompletten MySQL-Datenbanken

Die wichtigsten Konfigurationsdateien

Den genauen Standort der einzelnen Dateien finden Sie auch unter http://localhost/xampp/phpinfo.php

  • \xampp\apache\conf\httpd.conf – Apache Konfiguration
  • \xampp\MercuryMail\mercury.ini – Mercury Konfiguration
  • \mysql\bin\my.ini – MySQL Konfiguration
  • \xampp\php\php.ini – PHP Konfiguration
  • \xampp\phpMyAdmin\config.inc.php – phpMyAdmin Konfiguration
  • \xampp\sendmail\sendmail.ini – Sendmail, als alternative zu Mercury

Die wichtigsten Pfade

  • \xampp\htdocs
  • \xampp\MercuryMail\MAIL
  • \xampp\mysql\data

Fehlersuche

Es empfiehlt sich – wie überall – die Logfiles zu checken. Nützlich ist dabei eine Software wie mtail, die Logfiles beobachtet und nur die Änderungen in Echtzeit anzeigt.

Die wichtigsten Logfiles

  • \xampp\apache\logs\error.log
  • \xampp\FileZillaFTP\Logs
  • \xampp\MercuryMail\LOGS\
  • \xampp\mysql\data\mysql.err
  • \xampp\sendmail\sendmail.log

Wenn es noch Fragen gibt, immer her damit.