Den W3-Validator lokal installieren

Inhalt

Notice

This installation guide for the W3C Validator on an Apache under Windows is also available in English. It is included in the actual release of the validator, see http://validator.w3.org/docs/install_win.html.

Motivation

Warum schreibe ich diesen Artikel?

Nun, eigentlich ganz einfach: Seit ein paar Jahren beschäftige ich mich mit HTML. Anfangs war es mehr ein "Schau mal, wie toll" und zum Teil JavaScript-Klickbunti-Zeug, das herauskam. Doch mit der Zeit wandelten sich die Ansichten bezüglich einer guten Website bei mir. So sehe ich nun unter anderem validen Quelltext als selbstverständlich an. Unverzichtbar für die Überprüfung ist dabei ein Validator, wie beispielsweise der Validator des W3C oder Validome. Schnell lernte ich den W3C-Validator zu bedienen und lieben.
Doch aufgrund meines Umzugs habe ich jetzt zu Hause kein Internet mehr. Jedes mal, wenn eine Seite wieder gewachsen ist alles mit in die Uni zu schleppen, dort übers Netz zu validieren und letztendlich die Daten auch wieder mit nach Hause zu schleppen ist doch recht unpraktikabel.

Irgendwann stieß ich dann auch einmal darauf, dass man sich den Validator lokal installieren kann. Hey, das klingt ja prima, dachte ich mir. So lud ich mir die Dateien herunter und versuchte ihn bei mir zum Laufen zu bekommen. Doch es war ein großer K(r)ampf, immer funktionierte etwas nicht, zeitweise wurde mir bei jeder Seite gesagt sie sei nicht valide (ohne Näheres zum DocType zu sagen) obwohl sie 100% korrekt war.

Also durchsuchte ich das Netz nach Anleitungen, fand aber nur die von Björn Höhrmann, die aber leider schon längere Zeit nicht mehr aktuell ist. So suchte ich weiter, fand einige minimale Tipps.

Da ich es nun aber doch geschafft habe, den Validator bei mir richtig zum Laufen zu bekommen, möchte ich allen Interessierten meine Schritte aufschreiben und ihnen so Gleiches ermöglichen.

Benötigte Programme

Damit der Validator läuft benötigt man natürlich erst einmal einen Webserver. Ich selbst habe auf meinem PC einen Apache in der Version 2.0.49 am Laufen. Die Erklärung bezieht sich auch auf diese Version (die Vorgehensweise ist bei älteren Versionen (1.3) die gleiche).

Auf seine Installation und grundlegende Konfiguration gehe ich hier nicht ein. Jedoch empfehle ich den Artikel erst einmal komplett zu lesen um die Verzeichnisstruktur zu überblicken und kein wildes "Drauf-los-Installieren" zu beginnen.

Das Validator-Script selbst ist in Perl geschrieben. Also wird auch dies benötigt. Ich verwende bei mir ActivePerl 5.8. Dank eines Installers ist die Installation auch hier nicht schwer.

In dieser Version des Validators soll angeblich auch das Apache-Modul "mod_perl" anstelle vom ActivePerl als Perl-Interpreter möglich sein. Dies habe ich jedoch (noch) nicht getestet und kann daher keine Installationshilfe geben.

Dann wird natürlich der Validator selbst benötigt. Als tar-Archiv gepackt kann man ihn sich unter http://validator.w3.org/validator.tar.gz (~330KB) herunterladen. Aktuell ist die Version 7.

Neben dem Validator wird natürlich auch eine Sammlung von DTDs benötigt. Diese ist z.B. unter http://validator.w3.org/sgml-lib.tar.gz (~3MB) zu bekommen.

Für das Parsen der Dateien ist ein SGML-Parser zuständig. Hierfür wird das Programm OpenSP 1.5 empfohlen. Auf der verlinkten Seite waren lange Zeit nur die Source-Dateien bereitgestellt, das Kompilieren unter Windows bereitete aber nur Probleme. Das OpenSP-Projekt schlief eine lange Zeit, soll nun aber wieder auferweckt werden. Im Zuge dessen sollen auch fertige Windows-Binaries zum Download angeboten werden.

Zur Zeit gibt es Binaries (download, ~600KB) von Björn Höhrmann, der sich nun auch an der Weiterentwicklung des Programms beteiligt. Sollte es aber schon neuere Binaries auf der OpenSP-Website geben, so sind diese der hier verlinkten Version vorzuziehen.

Der Validator benötigt einige Perl-Module. Unter http://ppm.activestate.com/ befindet sich eine Liste aller verfügbaren Module. Ebenso kann man dort erfahren ob ein Modul "Core" (also standardmäßig mitgeliefert) ist oder ob es gezippt zum Download zur Verfügung steht.
Ich benötigte die folgenden Module:

Man kann sie sich einzeln bei ActiveState herunterladen; ich habe sie aber auch fertig zur Installation in einem zip-Archiv zum Download bereitgestellt.

Als letztes ist wohl noch etwas Ruhe und Geduld erforderlich, ich brauchte auch einiges davon ;) Für eine komplette Installation des Validators (inklusive Apache und Perl) sollte man, wenn man wenig Erfahrung hat, ruhig eine Stunde einplanen.

Verzeichnisstruktur

Es sollte schon etwas überlegt werden, wie und wohin die einzelnen Programme installiert werden. Ein einfaches "Weiter"-Klicken in allen Installationsroutinen ist eher unschön.

Auf meinem PC habe ich ein Verzeichnis C:\www, in dem alle Programme die etwas mit dem Server zu tun haben, installiert sind (natürlich in entsprechende Unterordner). So liegt der Apache in C:\www\Apache2, Perl in C:\www\perl, OpenSP in C:\www\opensp, die DTD-Sammlung in C:\www\sgml-lib, der Validator selbst in C:\www\validator. Die Zusatzmodule für Perl sollten auch in ein eigenes Verzeichnis entpackt werden; bei mir ist dies C:\www\ppm.
Im Folgenden gehe ich immer von den Pfaden meiner Installation aus.

Installation der Programme

Nun werden nacheinander die Programme installiert. Als erstes sollte der Apache installiert und zum Laufen gebracht werden. Wie schon erwähnt gehe ich darauf nicht näher ein; das Netz ist voll von Anleitungen. Zum Glück gibt es ja auch noch die Dokumentation zum Server. Einzig sei vielleicht erwähnt, dass bei der Installation automatisch ein Unterordner Apache2 eingefügt wird. Wählt man also als Installationsverzeichnis C:\www, so wird er tatsächlich nach C:\www\Apache2 installiert.

Danach ist Perl an der Reihe. Dies sollte auch kein Problem darstellen. Es muss jedoch darauf geachtet werden, dass während der Installation auch ppm3 mitinstalliert wird. Dieses Programm wird später zum Hinzufügen von Perl-Modulen benötigt.

Das Generieren der HTML-Dokumentation kann einige Zeit in Anspruch nehmen, möchte man sich aber ein wenig mehr mit Perl beschäftigen, so ist sie durchaus hilfreich.

OpenSP liegt in einem zip-Archiv vor, dies muss nur in den entsprechenden Ordner extrahiert werden.

Gleiches gilt für die DTD-Sammlung, den Validator selbst sowie, falls heruntergeladen, die Perl-Modulsammlung von mir. Zu beachten ist, dass das Archiv der DTD-Sammlung selbst noch einige Unterordner erstellt. Diese sind aber nicht unbedingt geeignet, also werden die Ordner verschoben. Der letzte Unterordner, der vom Archiv erstellt wird, heißt sgml-lib; er muss nach C:\www verschoben werden. Die anderen nun leeren Ordner können daraufhin gelöscht werden. Existiert nach dem Entpacken und Verschieben eine Datei sgml.soc im Verzeichnis C:\www\sgm-lib, so sind die DTDs am richtigen Ort.

Einbindung der Perl-Module

Nun kommt ein etwas komplizierter Schritt: Die Perl-Module müssen zu Perl hinzugefügt werden. Dazu wird das Programm ppm3 verwendet (ppm steht für "Programmer's Package Manager"). Es lässt sich über Start -> Ausführen... -> ppm3 starten. Das ganze sieht dann in etwa so aus:

Text-Konsole von ppm3

Gibt man dort rep ein, so bekommt man als Ausgabe die (in)aktiven Repositories. Dies sind gewissermaßen Speicherorte für Module, aus denen man sich die benötigten (falls dort verfügbar) herunterladen und installieren kann.

Die Einbindung kann wie bereits angesprochen auf zwei Arten geschehen: entweder liegen die Module lokal vor (beispielsweise aus dem zip-Archiv) oder sie werden direkt von zum Beispiel dem ActiveState-Server geladen.

Im Folgenden stelle ich recht ausführlich die erste Variante vor; grundlegend gleicht sie jedoch auch der zweiten. Es empfiehlt sich also, diesen Abschnitt in jedem Fall zu lesen.

Einbindung aus einem lokalen Repository

Ist ppm3 gestartet, so muss ihm als erstes mitgeteilt werden, dass sich ein solches Repository auf der Festplatte, genauer unter C:\www\ppm, befindet. Dazu wird nun rep add local c:\www\ppm eingegeben. Danach existiert unter dem Namen local ein solches Archiv, wie auch die Ausgabe zeigt.
Allerdings sind nun vielleicht noch andere Repositories aktiv. Dies lässt sich an der dann vorhandenen Zahl in dem Kästchen davor erkennen. Damit aber auch wirklich nur nach Modulen aus dem lokalen Archiv gesucht wird, werden die anderen einfach deaktiviert. Dies geschieht über rep off 1 (wobei hier die 1 für ein anderes Repository steht). Danach sollte nur noch "local" eine 1 haben, die anderen nichts. Es müsste also folgendes Bild zu sehen sein:

Das PPM3-Fenster mit den Eingaben

Nun sollen endlich die Module installiert werden. Durch die Eingabe von s * wird nun local durchsucht und natürlich alle fünf vorhandenen Module gefunden. Tippt man nun install 1, so wird das erste Gefundene installiert. Analog verfährt man nun für die anderen vier, also zum Beispiel install 3.

Das Ganze sollte dann wieder in etwa so aussehen:

PPM3 nach der Installation eines Moduls

Sollte die jeweils letzte Meldung nicht Successfully installed... lauten, so ist etwas mit der Installation schief gegangen und es muss erneut versucht werden.
Nach Abschluss aller Installationen wird das Programm durch die Eingabe von exit einfach beendet.
Nun sollten alle Module korrekt installiert und funktionsfähig sein.

Es sind jetzt zwar alle Programme vorhanden, doch "arbeiten" sie noch nicht zusammen. Zuvor müssen erst noch einige Konfigurationen vorgenommen werden.

Einbindung aus einem entfernten Repository

Die Installation von einem anderen Repository verläuft größtenteils analog. Zuerst wird wieder per rep überprüft, welche Repositories aktiv sind. Jedoch werden nun keine neuen hinzugefügt oder das aktive auf off geschaltet. Danach ist die Vorgehensweise identisch: Durch s * kann man wieder die komplette Sammlung durchsuchen. Jedoch ist es noch etwas schwer, die benötigten Module aus dieser langen Liste zu finden. Also wird die Suche eingegrenzt. Dies geschieht dadurch, dass man nicht nach "*", also allen Modulen, sucht sondern gezielt nach den benötigten. Es empfiehlt sich, jeweils die Anfangsbuchstaben des zu suchenden Moduls einzugeben, also beispielsweise s Conf. Sind es weiterhin zu viele Module, so können einfach weitere Buchstaben hinzugefügt werden.
Das Suchergebnis ähnelt dem der lokalen Variante. In der Ergebnisliste wird nun das Modul gesucht (Sollte es mehrere Versionen geben, so ist man mit der aktuellsten meist auf der sicheren Seite). Durch install 5 (wobei die 5 stellvertretend für die Nummer des richtigen Suchergebnisses ist) wird das Modul heruntergeladen und installiert.

Hat man alle Module hinzugefügt, so wird ppm3 durch exit beendet.

Konfiguration des Apache

Als erstes wird die Konfiguration des Apache ergänzt. Alle Änderungen werden in der httpd.conf, der zentralen Konfigurationsdatei des Apache, gemacht. Ein leichtfertiges Herumspielen kann also schlimmstenfalls dazu führen, dass der Apache nicht mehr laufen will.

Die Validator-Seiten werden mittels SSI zusammengesetzt. Dafür muss der Apache als erstes einmal dieses Modul laden. In der "Section 1: Global Environment" werden die verschiedenen Module geladen. SSI verbirgt sich hinter "mod_include". Die Zeile

LoadModule include_module modules/mod_include.so

muss also auskommentiert (die Raute am Zeilenanfang entfernen) oder ergänzt werden, sofern das Modul nicht schon geladen wird.

Im Folgenden wird ein Virtual Host eingerichtet. Er dient dazu, dass der Validator in seinem zuvor angelegten Verzeichnis arbeiten und auch dort erreicht werden kann und logisch vom normalen Webserver getrennt ist.
Dafür müssen nur die folgenden Zeilen an das Ende ("Section 3: Virtual Hosts") der httpd.conf kopiert werden:

NameVirtualHost 127.0.0.2:80

<VirtualHost 127.0.0.2:80>
    ServerName validator.david.tibbe

    DocumentRoot "C:/www/validator/htdocs"
    ErrorLog logs/error_validator.log
    CustomLog logs/access_validator.log common

    ScriptAlias /cgi-bin "C:/www/validator/httpd/cgi-bin"
    ScriptAlias /check "C:/www/validator/httpd/cgi-bin/check"

    AddType text/html .html
    AddOutputFilter INCLUDES .html

    <Directory "C:/www/validator/htdocs">
        Options          ExecCGI Includes Indexes MultiViews
        AllowOverride    None
        Order deny,allow
        Allow from localhost
    </Directory>

    <Directory "C:/www/validator/httpd/cgi-bin">
        Options          ExecCGI Includes Indexes MultiViews
        AllowOverride    None
        Order deny,allow
        Allow from localhost
    </Directory>
</VirtualHost>

Ausführlich werde ich die einzelnen Zeilen nicht erklären, wen es interessiert, was dort gemacht wird, der kann ja einfach ins Manual des Apache schauen oder sich den Feature-Artikel von Christoph Schnauß zur Serverkonfiguration ansehen. Nur so viel: In den ersten Zeilen wird der Name eingestellt, danach werden die Logfiles angegeben, danach Kurzbefehle für das eigentliche Validator-Script check und das cgi-bin angegeben. Danach wird gesagt, dass alle html-Dateien auf SSI geparst werden sollen. Als letztes werden noch Zugriffsrechte für Verzeichnisse gesetzt.

Die im Verzeichnis C:\www\Apache2\logs liegenden Log-Files für den Validator-Host, error_validator.log und access_validator.log, werden über alle auftretenden Fehler und alle Zugriffe Buch führen und bei Problemen wichtige Hinweise geben.

Nun muss der Apache noch neu gestartet werden, damit die Änderungen aktiv werden. Dies geht bequem über das Startmenü; in der Programmgruppe des Apache gibt es in der Untergruppe Control Apache Server den Punkt Restart. Nun sollte kurz eine Dos-Konsole erscheinen, nach ihrem Verschwinden ist der Apache fertig gestartet.

Wird nun im Browser http://127.0.0.2/ aufgerufen, so sollte die von http://validator.w3.org/ bekannte Seite zu erkennen sein.
Zwar wurde in der Konfiguration des Virtual Hosts der ServerName validator.david.tibbe, jedoch wird dieser nicht erkannt. Damit dies funktioniert muss nun noch die hosts-Datei angepasst werden.

Anpassung der hosts-Datei

Die angesprochene hosts-Datei befindet sich im Verzeichnis C:\windows\hosts unter Win9x und im Verzeichnis C:\Windows\system32\drivers\etc\hosts unter WinXP. Es kann sein, dass die Datei hosts nicht vorhanden ist, wohl aber eine hosts.sam. In diesem Fall muss sie einfach nur umbenannt werden.

Öffnet man die Datei mit einem Editor, so befindet sich ein einleitender Kommentar darin sowie die Zeile

127.0.0.1       localhost

Das bedeutet, dass, wenn man im Browser http://localhost/ aufruft, diese Anfrage an http://127.0.0.1/ weitergeleitet wird. Nun habe wird diese Datei wie folgt geändert:

127.0.0.1       localhost
127.0.0.1       www.david.tibbe
127.0.0.2       validator.david.tibbe

Nach dieser Änderung ist der Server wie bisher unter http://localhost/ aber jetzt auch unter http://www.david.tibbe/ erreichbar. Zudem werden nun auch die Anfragen auf http://validator.david.tibbe/ zu http://127.0.0.2/ weitergeleitet.

Die Serverkonfiguration ist somit abgeschlossen.
Möchte man aber eine Seite validieren lassen, so wird es wahrscheinlich einen "Internal Server Error" geben. Das liegt daran, dass das check-Script noch nicht konfiguriert wurde.

Konfiguration des Validators

Im Verzeichnis C:\www\validator\htdocs\config liegt eine Datei namens validator.conf. Diese kann mit einem beliebigen Editor geöffnet und bearbeitet werden. Dabei sind die Zeilen mit einer Raute am Anfang Kommentare. Die einzelnen Optionen sind eigentlich selbsterklärend und werden deshalb nur wenn nötig weiter beschrieben.

Mit der Option Base wird der Pfad zum Wurzelverzeichnis angegeben. Dazu wird diese Option entkommentiert (also das # davor entfernt) und auf C:/www/validator/ gesetzt.

Unter SGML Library wird c:/www/sgml-lib/ angegeben. Zu beachten ist, dass im Pfad einfache Slashes verwendet werden, nicht die von Windows gewohnten Backslashes.

Der SGML Parser ist bei mir unter c:/www/opensp/onsgmls.exe zu finden.

Home Page wird auf die URI des Validators geändert, bei mir also http://validator.david.tibbe/.

Der letzte Punkt, Allow Private IPs = { yes | no }, muss auf yes gestellt werden. Andernfalls kann man die Dateien nicht vom lokalen Rechner aus validieren lassen und erhält nur einen Zugriffsfehler aus Sicherheitsgründen.

Die vollständige Konfigurationsdatei sieht danach in etwa so aus:

#
# Main Configuration File for the W3C Markup Validation Service.
#
# $Id: install_win.html,v 1.3 2005/08/08 01:12:33 ot Exp $
#
# See 'perldoc Config::General' for the syntax, and be aware that the
# 'SplitPolicy' is 'equalsign', ie. keys and values are separated by '\s*=\s*',
# and that 'InterPolateVars' is in effect.
#

#
# Base Path for Markup Validator files.
#
# You MUST set these unless you use the default locations for the files.
# e.g. the config files in "/etc/w3c/" and everything else in
# "/usr/local/validator/".
#
# Make sure all file paths below do NOT end with a slash

<Paths>
    #
    # Base path. Defaults to the value of the W3C_VALIDATOR_HOME environment
    # variable or /usr/local/validator if the variable does not exist.
    Base = C:/www/validator
    
    #
    # Location of template files
    Templates = $Base/share/templates
    
    <SGML>
        #
        # The SGML Library Path.
        Library = $Base/htdocs/sgml-lib
        
        #
        # The SGML Parser to use. Defaults to /usr/bin/onsgmls.
        Parser = C:/www/opensp/onsgmls.exe
    </SGML>
</Paths>

#
# This controls whether the debugging options are allowed to be enabled.
Allow Debug = yes

#
# This lets you permanently enable the debugging options. Can be overridden
# with CGI options (unlike "Allow Debug" above).
Enable Debug = no

#
# Whether private RFC1918 addresses are allowed.
Allow Private IPs = yes
#

# Whether the (highly experimental!) SOAP support should be enabled.
Enable SOAP = no

#
# Whether the validator will check its own output.
# 0 means it will refuse to check its own output, 1 means it will but it will
# refuse to check the results of it checking itself. Etc.
Max Recursion = 0

#
# Protocols the validator is allowed to use for retrieving documents.
# The default is to allow http and https.
<Protocols>
    Allow = data,http,https
</Protocols>

#
# Email address of the maintainer of this service.
Maintainer = mail@validator.david.tibbe

#
# The "Home Page" for the service. Make sure this ends with a slash.
Home Page = http://validator.david.tibbe/

#
# Base URI for the Element Reference.
Element Ref URI = http://www.htmlhelp.com/reference/html40/

#
# Mapping tables etc...
#

#
# Maps element names to URLs (cf. "Element Ref URI" above).
<Elements>
    Include eref.cfg
</Elements>

#
# Main document Type Registry; contains all information on the types
# of documents we support and how they are processed.
<Types>
    Include types.conf
</Types>

#
# Mapping of charset names to their IANA names and how iconv(3) knows them.
<Charsets>
    Include charset.cfg
</Charsets>

#
# Map MIME Media Type to Parse Mode mapping.
<MIME>
    text/xml               = XML
    image/svg              = XML
    image/svg+xml          = XML
    application/smil       = XML
    application/xml        = XML
    text/html              = TBD
    text/vnd.wap.wml       = XML
    application/xhtml+xml  = XML
    application/mathml+xml = XML
</MIME>

#
# Source for the "Tip of The Day" blurbs.
<Tips>
    Include tips.cfg
>/Tips<

Nun ist der Validator schon einmal konfiguriert. Dennoch arbeitet er nicht, da noch ein paar Zeilen am Validator-Script selbst geändert werden müssen.

Anpassung des 'check'-Scripts

Ja, nun sind es nur noch wenige Zeilen bis zum laufenden Validator. Also, auf geht's.
Die folgenden Änderungen am Script sind deswegen nötig, da es für einen Unix-Server geschrieben wurde, dort jedoch ein paar Kleinigkeiten anders sind als unter Windows.

Das Script check aus dem Verzeichnis C:\www\validator\httpd\cgi-bin wird nun mit einem beliebigen Editor geöffnet. In den folgenden Anweisungen gebe ich bewusst keine Zeilennummern an, da sich diese in zukünftigen Versionen verschieben können. Es ist aber jeweils ein Hinweis auf die Zeilen davor oder danach gegeben anhand derer man sich orientieren kann.

Direkt die erste Zeile muss in

#!c:/www/perl/bin/perl.exe

geändert werden. Dies ist der Pfad zu dem Perl-Interpreter, bisher steht er dort nur in Unix-Form. So muss er also auf Windows angepasst werden. Ebenso wird dabei der Parameter "-T" entfernt.

Als nächstes wird nun dem Script mitgeteilt, wo die Konfigurationsdatei liegt. Dies geschieht nach dem Kommentar in diesen Zeilen

#
# Read Config Files.
eval {
  my %config_opts = (
     -ConfigFile => ($ENV{W3C_VALIDATOR_CFG} || '/etc/w3c/validator.conf'),

Sie müssen auf

#
# Read Config Files.
eval {
  my %config_opts = (
     -ConfigFile => ('C:/www/validator/htdocs/config/validator.conf'),

geändert werden.

Ein Stück weiter im Script werden Kommandozeilenparameter für OpenSP definiert:

# Note: if you feel the urge to remove -R from here, please understand that
# doing so opens a potential security hole. Don't do that; instead just
# make sure you're running OpenSP 1.5 or later.
my @spopt = qw(
               -R
               -wvalid
               -wnon-sgml-char-ref
               -wno-duplicate
              );

Daraus muss die Option -R gelöscht werden, sodass also nur noch

# Note: if you feel the urge to remove -R from here, please understand that
# doing so opens a potential security hole. Don't do that; instead just
# make sure you're running OpenSP 1.5 or later.
my @spopt = qw(
               -wvalid
               -wnon-sgml-char-ref
               -wno-duplicate
              );

dort steht.

Nun muss das Script nur noch einmal abgespeichert werden. Danach kann über http://validator.david.tibbe/ wie bisher über http://validator.w3.org/ gearbeitet werden.

Der eigene Validator ist installiert!

Hinweise

Mit dieser Validator-Version wurden ebenfalls neue Perl-Module verwendet; in neuen Versionen werden vielleicht erneut weitere Module benötigt. Diese lassen sich aber wie oben beschrieben mit ppm3 herunterladen und installieren. Welche das wären, ist gegenebenfalls einfach zu erkennen. Die vom Script erzeugte Fehlermeldung wird automatisch an den Browser gesendet. Sie lautet dann beispielsweise:

Can't locate Config/General.pm in @INC (@INC contains: C:/www/perl/lib C:/www/perl/site/lib .) at C:/www/validator/httpd/cgi-bin/check line 46.
  BEGIN failed--compilation aborted at C:/www/validator/httpd/cgi-bin/check line 46.

Es ist nicht schwer zu sehen, dass das Modul "Config General" fehlt und nachinstalliert werden muss.

Mit neueren Perl-Versionen sollte es meiner Meinung nach keine Probleme geben. Die bisherigen Funktionen werden sicher nicht aus dem Sprachumfang genommen werden.

Ein Updaten der SGML-Dateien ist auch kein Problem. Die Dateien im sgml-lib-Verzeichnis werden dann einfach durch die Neuen ersetzt.

Unter Umästnden kann es passieren, dass Windows XP mit installierem Service-Pack 2 Probleme mit den Loopback-Adressen (127.0.0.2 u.Ä.) hat. Das Problem und Lösngen dafür werden bei MicroSoft auf einer Seite beschrieben: http://support.microsoft.com/default.aspx?kbid=884020.

Schlussbemerkungen & Dank

Diese Anleitung habe ich nach meiner erfolgreichen Installation geschrieben. Ich kann nicht garantieren, dass es auf allen anderen Systemen genauso funktioniert, es sollte aber kein Problem sein.

Falls ich in meiner Anleitung einen Fehler gemacht haben sollte oder deswegen eine eigene Installation scheitert, so stehe ich gerne per Mail (david@tibbe-online.de) für Fragen bereit. Fragen wie Wie installiere ich den Apache werden hingegen ignoriert und gelöscht.

Für Anregungen, Lob und Kritik bin ich natürlich auch offen und erwarte sie gerne. Sollte diese Anleitung geholfen haben, so würde ich mich über eine Verlinkung freuen.

 

Das hier Beschriebene habe ich nicht alles von alleine hinbekommen. Auf meiner Suche waren mir folgende Personen besonders hilfreich, sodass ich diesen hier gerne ein Danke sagen möchte:
Dies wären zum einen Björn Höhrmann für die ersten Tipps zur Installation und einige weitere Hinweise und Carsten Protsch für einige Tipps im Zusammenhang mit den Perl-Modulen sowie seiner alten Validator-Version.

Nun wünsche ich aber allen viel Spaß beim Validieren.

last update: 2007/04/04
best view with a Browser