So schöne Dinge man mit Flash machen kann: Beim Einsatz ist immer wieder Vorsicht geboten!

Wir haben z.T. sehr schlechte Erfahrungen mit dem Verhalten verschiedener Browser gemacht, wenn es darum geht, zwischen Seiten mit praktisch identischem Layout zu wechseln. Da in einem solchen Szenario viele Objekte im Browser gecached werden können, hofft man bei solchen Seiten auf einen sanften Übergang – also ohne viel Flackern beim Rendern der neuen Seite. Objekte die beim Seitenwechsel statisch bleiben, sollen auch im Browser statisch erscheinen.

Wichtig wird dies dann, wenn man auf einer Firmenseite viele einzelne Seiten hat, die im Hintergrund und in anderen Bereichen praktisch gleich aussehen. Hier möchte man als Betrachter einen ruhigen Wechsel ohne störende Reloads und ohne Neuzeichnen des Hintergrunds bzw. der statisch bleibenden Seitenelemente erleben. Nur veränderte Inhaltsbereiche sollen sich bei Rendern visuell sichtbar ändern.

Gerade dann, wenn die HTML-Seiten Flash-Objekte beinhalten, wird diese Erwartungshaltung an eine flackerfreies Browserverhalten aber oft genug nicht erfüllt. Im Gegenteil beeinträchtigt z.T. deutliches und wirklich störendes Flackern den Seitenaufbau. Zumal man hierfür als Betrachter keinen Grund erkennen kann und dies von Seiten ohne Flash-Inhalt auch nicht gewohnt ist.

Wir haben das “Redraw”-Verhalten von verschiedenen Browsern unter Linux und Windows ein wenig getestet. Hier unser Ergebnis, das wir auch an die Entwickler von Opera und Firefox weitergeleitet haben.

Unter Linux muss man feststellen, dass die von uns verwendeten Browser “Konqueror Firefox und Opera” generell den Bereich des Flashobjektes beim Wechsel zwischen nahezu gleichen Seiten neu zeichnen.

U.U. werden aber auch andere Objekte neu gerendert bzw. nachgeladen – gerade Firefox spielt hierbei eine unrühmliche Rolle! Dieser Browser zeichnet generell Layer (DIVs und ihren Inhalt) sowie Images neu, sobald die Seiten auch nur ein einziges (identisches) Flash-Objekt beinhaltet. Auch wenn sämtliche Elemente der Seiten gecached wurden. man muß allerdings festhalten: Das geschieht ausschließlich beim Wechsel zwischen Seiten, die Flashobjekte beinhalten. Hier kommt es – selbst bei 99% identischem Layout – zu deutlichen sichtbaren Beeinträchtigungen beim Bildaufbau. Interessanterweise zeigt die Windows-Version von Firefox dieses Verhalten nicht !

Dass es unter Linux auch viel besser geht, zeigen dagegen Konqueror und Opera. Beide Browser zeichnen nur den Flashbereich neu, wenn der Inhalt der Seiten zwischen denen gewechselt wird, praktisch identisch ist.

Überraschenderweise bietet Opera unter Windows das schlechteste Verhalten an. Hier wird alles neu gezeichnet, sogar der Hintergrund (bzw. die Hintergrundsfarbe) einer Seite. Resultat ist ein massives Flackern beim Seitenaufbau, da immer auch die Standardfarbe des Hintergrunds – nämlich Weiß – kurz sichtbar wird. Damit wird ein Wechsel zwischen Seiten mit einer Mischung aus HTML- und Flash-Content zu einem Erlebnis der besonderen, wenn auch negativen Art.

Das beste Verhalten bei unseren Tests zeigte der IE 7 unter MS Windows – allerdings auch nur, wenn die Seiten keinen komplizierten Layeraufbau mit vertikaler Schichtung aufwiesen. Mit vertikal geschichteten Layern kann der IE unserer Erfahrung nach beim Seitenwechsel insgesamt nur schlecht umgehen – im Gegensatz zu Firefox (solange kein Flash im Spiel ist).

Entfernt man die Flashinhalte aus Testseiten, so reduzieren sich die Flackereffekte, die mit dem Rendervorgang beim Seitenwechsel auftraten, sehr deutlich. Daraus ist zu schließen, dass das Zusammenspiel zwischen Flash-Plugin und der jeweiligen Browser-Engine in den betrachteten Browser-Varianten unterschiedlich gelöst wurde.

Deutliches Verbesserungspotential besteht unserer Meinung nach beim Firefox (Linux) und Opera (Windows).

Mehr und detailliertere Informationen sowie ein Testszenario findet man im Anhang (s.
nachfolgender Link).

Test zum Redraw Verhalten von Browsern beim Wechsel zwischen Seiten mit Flash-Content

Testdateien bitte per Mail vom Verfasse anfordern!

Einführung
Bei der Erstellung von Websites – auch kleineren Umfangs – kommt von Kunden immer häufiger die Anforderung eine kleine Suchmaschine zu integrieren, die zu einem oder einigen wenigen Suchbegriffen die relevanten Seiten der Website findet.

Da dies eine Standardaufgabe ist, hofft man als Entwickler, im Internet nicht nur fertige und freie OpenSource Suchmaschinen sondern auch Hinweise darauf zu finden, wie man einen solchen Service evtl. selbst programmiert. Interessanterweise liefert eine Internetrecherche im nichtkommerziellen Bereich gar nicht so viele passende Treffer. Fast verschwindend ist die Anzahl brauchbarer Anleitungen zum Eigenbau mittels PHP. Der oft zu findende Hinweis, man möge doch bitte die Volltextindizierung von MySQL benutzen, nützt einem ohne entsprechendes Hintergrundswissen zunächst auch nicht so viel.

Eine an und für sich gelungene Einführung von Daniel Solin
http://www.onlamp.com/pub/a/php/2002/10/24/simplesearchengine.html?page=1

leidet darunter, dass sich die Ausführungen auf eine Beispielmaschine beschränken, die genau einen Suchbegriff zulässt.

Da wir selbst in einem unserer letzten Aufträge eine Suchmaschine implementieren mussten, möchten wir mit einigen Tipps und Programmhinweisen die Diskussion von Daniel Solin erweitern und ergänzen.

Zielsetzung ist dabei Folgendes:

1. Eine kurze Diskussion einer möglichen Strategie zur Bestimmung der “Relevanz” einer getroffenen Seite. Eine solche Diskussion fehlt im Artikel von Solin; die Relevanz einer getroffenen Seite wird aber immer wichtiger, wenn bei der Suche mehr als ein Suchbegriff verwendet wird.
2. Eine Darstellung des Programmablaufs zur Erstellung der Datenbank.
3. Eine Darstellung des Programmablaufs für den Suchvorgang selbst, wenn genau ein Suchbegriff eingesetzt wird.
4. Erweiterung der Suche auf mehrere Suchbegriffe, wobei die Begriffe in exakter Schreibweise gefunden werden sollen.
5. Erweiterung des Programmablaufs für eine unscharfe Suche.

Wir werden diese Punkte in einzelnen Blog-Artikeln aufgreifen und hoffen, damit dem einen oder anderen Webseiten-Entwickler, der den Einsatz von PHP nicht scheut, eine Hilfestellung zu leisten.

Einführung
Will man die Opensource Software “MediaWiki” beim Provider 1&1 installieren, so gibt es einige kleinere Hürden zu überwinden. Voraussetzung für die aktuellen MediaWiki-Versionen ist in jedem Fall ein Webhosting-Paket, das eine MySQL-Datenbank (am besten MySQL 5) und einen PHP5-Interpreter beinhaltet. Die Standardeinstellungen bzgl. des nutzbaren Speichers für PHP-Prozesse sind bei 1&1 ausreichend (40 MB; gefordert sind 32MB).

Wir folgen mit der nachfolgenden Beschreibung in Teilen einem Blog-Artikel von Johan Cyprich
(http://www.cyprich.com/2007/08/17/installing-mediawiki-on-11/#),
auf den wir als grundlegende Lektüre verweisen. Zur generellen Einführung in MediaWiki und dessen Installation ist (trotz einiger Schwächen) vielleicht das Buch “MediaWiki Administrators’ Tutorial Guide” von M. Rahman, PACKT Publishing, 2007, geeignet.

Es sind vor allem folgende drei Punkte, die bei der Installation im Rahmen eines 1&1 Webhosting-Pakets zu beachten sind:

• Während der Installation von MediaWiki muss das Installationsprogramm lokale Einstellungen in ein bestimmtes Verzeichnis “config” schreiben. Hierzu muß die Schreibberechtigung für das Verzeichnis gesetzt sein. Zudem muss im Zuge der Installation eine Datei “/config/index.php” gefunden werden, was ohne weitere Maßnahmen misslingt.
• Normalerweise wird das PHP5 – Modul des Web-Servers bei 1&1 nur dann gezogen, wenn die entsprechende PHP-Datei die Endung .php5 aufweist. Dies kann und sollte man für die Wiki-Seiten ändern.
• Die Zugangsdaten zur Datenbank sollten zur Sicherheit in einem für Benutzer nicht zugänglichen Verzeichnis außerhalb der Wurzelverzeichnisse der angebotenen Websites hinterlegt und zur Laufzeit in die PHP-Skripts eingebunden werden. (Hier unterscheidet sich unser Vorgehen übrigens von der Beschreibung von Cyprich.)

——————————————————————————–

Schritt 1: Anlegen oder Auswahl der Datenbank
MediaWiki kann seine Tabellen in einer bereits vorhandenen Datenbank anlegen. Zur Unterscheidung von Tabellen anderer Applikationen kann man während der Installation einen Prefix für die Tabellennamen definieren. Hat man mehrere Datenbanken zur Verfügung, so lohnt es sich ggf. allein aus Platzgründen, für MediaWiki eine separate Bank zu reservieren. Das Erstellen von Backups vereinfacht sich dann zudem.

Die Anlage einer spezifischen Datenbank erfolgt nach dem Kundenlogin bei 1&1 über die Auswahl des Punktes “MySQL-Datenbank” unter der Leiste “Homepage/Anwendungen”. Das aufgehende Fenster gibt eine Übersicht über bereits angelegte Banken und bietet zudem die Möglichkeit, eine neue Bank zu initialisieren. Die Dialoge sind leicht verständlich. Wir gehen hier nicht weiter darauf ein. Als Version der Bank wähle man trotz der Warnhinweise MySQL 5. Nach der Anlage der Datenbank erhält man die Informationen zum Datenbankserver, zum Datenbanknamen, zum Datenbanknutzer und zum Passwort durch Anklicken des entsprechenden Buttons “Bearbeiten” in der Übersicht zu den vorhandenen Datenbanken.

Schritt 2: Anlegen einer PHP-Include Datei mit den Zugangsdaten für die Datenbank
Dieser Schritt ist wie Schritt 10 optional; wir raten aber dazu, ihn aus Sicherheitsgründen auszuführen.
Bei 1&1 bekommt man pro Vertrag typischerweise einen einzigen zusammenhängenden Verzeichniszweig für seine Dateien auf einem Server zugewiesen. Das Wurzelverzeichnis dieser Ordnerstruktur sollte man typischerweise nicht als Wurzelverzeichnis seiner Website oder seiner Websites definiert haben. Vielmehr weist man die Webdomainen definierten Verzeichnissen unterhalb der Wurzel der eigenen Verzeichnisstruktur zu.

Hat man etwa 2 Domainen “mydomain.de”
und “mydomain.com” reserviert, so wird man typischerweise Verzeichnisse “/de” und “/com” definieren, unter denen man die Index- und sonstigen Webdateien der jeweiligen Site platziert. (Die Zuordnung der Domaine zum jeweiligen Verzeichnis erfolgt bei 1&1 unter dem Punkt “Domainverwaltung”). Dieses Vorgehen hat den Vorteil, dass man außerhalb der Verzeichnisse für die Inhalte der Webdomainen weitere Verzeichnisse definieren kann, die für Besucher der Websites nicht direkt sichtbar oder zugänglich sind. Damit kann man insbesondere beim Einsatz von PHP oder PERL die Sicherheit etwas verbessern; man kann etwa sensible Dateien in genau solchen nicht sichtbaren Verzeichnissen unterbringen und diese zusätzlich durch “.htaccess”-Dateien weiter gegen unbefugte Zugriffe absichern.

Wie man seine MediaWiki-Seiten in der zugänglichen Verzeichnisstruktur aufhängt, ist ein wenig Geschmackssache. Sinnvoll ist ggf. die Definition einer Subdomaine. Wir gehen nachfolgend davon aus, dass die (Installations-) Dateien für MediaWiki in einem speziellen Verzeichnis – das also als lokale Wurzel für den Wiki-Bereich fungieren soll – abgelegt wurden. In unserem Beispiel etwa im Verzeichnis: “/de/mywiki”.

Nun definiert man mit Hilfe eines FTP-Tools auf oberster Ebene der eigenen Verzeichnisstruktur ein Verzeichnis mit beispielsweise dem Namen “mywiki_include” (Pfad: /mywiki_include) und legt darunter eine PHP-Datei – beispielsweise “db_access.php” – mit folgendem Inhalt an:

<?
$wgDBserver = “dbxxxx.1und1.de”;
$wgDBname = “dbxxxxxxxxx”;
$wgDBuser = “dboxxxxxxxxx”;
$wgDBpassword = “xxxxxxxxx”;
?>

Man ersetze dabei die xxx-Platzhalter durch die eigenen Access-Daten für die in Schritt 1 gewählte Datenbank.

Das Verzeichnis “mywiki_include” kann man danach noch mit einer “.htaccess-Datei” schützen. Wir gehen hier nicht weiter auf den “.htaccess”-Mechanismus ein, verweisen aber auf die Möglichkeit, einen solchen Schutz bei 1&1 unter der Rubrik “Zugänge” über den Punkt “Geschützte Verzeichnisse” zu aktivieren. Man legt dabei zunächst eine Zugangskennung fest und ordnet diese und ein zugehöriges Passwort dann dem zu schützenden Verzeichnis (hier “mywiki_include”) zu.

Schritt 3: Kopieren der MediaWiki-Installationsdateien in das Verzeichnis für den Wiki-Bereich
Die aktuellen MediaWiki-Dateien holt man sich (als tar-Archiv) am besten von folgender Website: http://www.mediawiki.org/wiki/Download/de.
Die Dateien kopiert man dann in unserem Beispiel in das Verzeichnis “/de/mywiki”.

Schritt 4: Erzeugen einer htaccess-Datei zur Änderung des Dateityps für PHP5
Das Wurzelverzeichnis zum Wiki (hier: /de/mywiki) ergänze man um eine Datei “.htaccess” oder erweitere eine evtl. bereits vorhandene .htaccess-Datei) mit folgendem Inhalt:
AddType x-mapp-php5 .php
Nun werden auch Dateien mit der Endung .php (soweit sie aus diesem Verzeichnis stammen) durch den PHP 5 Interpreter verarbeitet.

Schritt 5: Umbenennen und Ersetzen des “config”-Verzeichnisses
Man bennene nun (per FTP-Tool) das “config”-Verzeichnis (/de/mediawiki/config) um in “configure”. Danach erzeuge man ein neues Verzeichnis “config” (/de/mywiki/config) und erteile (per FTP) einen temporären Schreibzugriff auf dieses Verzeichnis (z.B. die UNIX-Rechtekombination “757” ).

Schritt 6: Starten der Installation
Man rufe im Browser seiner Wahl (z.B. Firefox) die Seite “index.php” oder die Seite “index.php5” im Wiki-Verzeichnis auf.
Das sollte etwa so aussehen: “http://www.mydomain.de/mywiki/index.php5”. Auf der dann im Browser angezeigten Seite klickt man den Punkt “set_up wiki” an.
Bei der nachfolgenden Fehlermeldung ersetzt man in der angezeigten Adresszeile des Browsers “config” durch “configure” und drückt die Enter-Taste, um die geänderte
Adresse
“http://www.mydomain.de/mywiki/configure/index.php”
aufzurufen.

Schritt 7: Ausfüllen des MediaWiki-Installationsformulars
Wir nehmen an, dass im oberen Bereich der nun angezeigten Seite keine Fehlermeldungen erscheinen. Man sollte danach alle erforderlichen Angaben im Formular ausfüllen – im Besonderen auch die Angaben zum Datenbankaccess. (Wir werden die entsprechenden Zeilen später in der zugehörigen PHP-Datei identifizieren und ersetzen).

Schritt 8: Verschieben der Datei LocalSettings.php
Nach der Abschlußmeldung zur Installation verschiebe man (per FTP) die Datei “LocalSettings.php” vom “config”-Ordner in das Hauptverzeichnis des Wiki-Bereichs. In unserem Fall also von “/de/mywiki/config/LocalSettings.php” nach “/de/mywiki/LocalSettings.php”. Danach ist das WIki bereits lauffähig und man kann einen ersten Blick darauf werfen, indem man im Browser “http://www.mydoman.de/mywiki” als Adresse angibt.

Schritt 9: Entfernen der in Schritt 5 vergebenen Schreibberechtigung auf dem Verzeichnis “config”
Bitte setzen Sie die Zugangsberechtigungen auf dem Verzeichnis “config” wieder auf die Standardwerte (keine Schreibberechtigung).

Schritt 10: Ersetzen der Datenbank-Zugangsdaten in der Datei “LocalSettings.php”
Die eben in Schritt 8 verschobene Datei “LocalSettings.php” lädt man sich per FTP auf den lokalen Rechner zuhause, macht sich zur Sicherheit eine Kopie davon, und editiert dann die Datei. Man identifiziere die Einträge zum Datenbankzugang der Form

$wgDBserver = “dbxxxx.1und1.de”;
$wgDBname = “dbxxxxxxxxx”;
$wgDBuser = “dboxxxxxxxxx”;
$wgDBpassword = “xxxxxxxxx”;

Man lösche diese 4 Zeilen (!!!!!! nicht aber die Zeile mit dem Inhalt $wgDBtype = “mysql”;) und ersetze Sie durch eine Include-Anweisung (require_once) mit einer relativen Pfadangabe zur Datei “db_access.php” aus Schritt 2. In unserem Beispiel sähe die Zeile dann so aus:

require_once( “../../mywiki_include/db_access.php”);

Die so modifizierte Datei “LocalSettings.php” speichert man nun und lädt sie per FTP auf den Webserver bei 1&1 in das Verzeichnis “/de/mywiki/” (Überschreiben der vorhandenen Datei – letztere ggf. vorab zur Sicherheit umbenennen und als Sicherheitskopie ablegen).

Abschließend sollte man im Browser erneut in das nun fertig installierte Wiki gelangen können. Nun kann man sich entspannt den erforderlichen Administrationsaufgaben widmen oder die ersten Wiki-Seiten anlegen.