Wie ich in diesem Artikel vorgestellt habe, produziert das populäre Plugin Contact Form 7 so wie es ist nicht barrierefreie Formulare, da die Label-Tags fehlen und mühsam per Hand eingepflegt werden müssen. Aber Abhilfe ist in Sicht!
Das Erweiterungs-Plugin Contact Form 7: Accessible Defaults liefert neue Templates, in denen die Labels für die Formularfelder bereits korrekt definiert sind. Leider können bereits bestehende Formulare damit nicht aktualisiert werden, die Templates wirken nur für neu erstellte Formulare. Der Autor empfiehlt eine Installation seines Plugins vor der Installation von Contact Form 7, wo das nicht möglich ist sollte man dann nur noch die neuen Templates benutzen, um barrierefreie Formulare zu erzeugen. Aber immerhin – CF7 Accessible Defaults erspart einem viel mühsame Handarbeit – das geht schon in die richtige Richtung!
Ich bin wahrlich kein Microsoft-Fan, aber Microsoft Access ist meiner Ansicht nach das am meisten unterschätzte fantastische kleine Datenbankpaket auf dem Markt. Es begleitet mich seit Mitte der 80er Jahre und hat sich seitdem nicht grundlegend geändert. Warum auch, denn die zugrundeliegende Datenbankengine Jet ist ein vollwertiges SQL-Paket mit allem drum und dran und hat sogar einige Features, von denen sich das heute allgegenwärtige MySQL eine Scheibe abschneiden könnte. Ich nenne hier nur beispielhaft Kreuztabellen (Pivot-Tabellen) und voll integrierte referentielle Integrität, das kann MySQL nicht bzw. nur mit den umständlichsten Verrenkungen.
Eine der ersten Windows-Datenbanken
Microsoft Access war eine der ersten Datenbanken mit einer voll grafischen Windows-Oberfläche und damit damals wirklich bahnbrechend, man war ja noch dBase für DOS und Clipper gewohnt. Und da kam Access mit einer anschaulichen und intuitiven Bedienoberfläche und machte damit die bisher so exklusive Kunst der Datenbankerei auch für Endanwender zugänglich.
Bedienkomfort und Funktionalität
Was war – und ist – so toll an der Windows-Oberfläche? Drei Module finde ich auch heute noch ungeschlagen in Funktionalität und Bedienkomfort:
den Abfrageeditor
die Beziehungsverwaltung
den Formulardesigner
Dazu kommt eigentlich noch die integrierte Programmiersprache VBA(Visual Basic, die Microsoft-Makrosprache), aber es kommt wirklich ganz, ganz selten vor dass man in Access etwas programmieren muss, die meisten Aufgaben lassen sich über die grafische Oberfläche lösen.
Wieso rede ich hier ständig von der Oberfläche?
Weil MySQL sowas nicht hat. MySQL per se ist eine „nackte“ Datenbank, und wenn man z.B. ein Formular haben möchte um Daten benutzerfreundlich optisch aufbereitet anzuzeigen, muss man sich eins in PHP und HTML programmieren. Sicher, es gibt Entwicklungsumgebungen und jede Menge Tools, die einem da das Leben leichter machen, aber einen integrierten Formulardesigner wie ihn Access hat – nee nee, den sucht man bei MySQL vergeblich.
Der Abfrage-Editor
Das gleiche gilt für den Abfrage-Editor. So etwas wie ein SQL-Editor ist zwar sehr rudimentär im phpmyadmin enthalten, aber meilenweit entfernt von der ausgefeilten grafischen Oberfläche, wie es Access hier bietet. Mit ein paar Klicks bindet man in Access seine Tabellen ein, definiert Beziehungen, wählt Felder und Bedingungen aus, gruppiert und sortiert Daten nach Belieben – und das ohne eine einzige Zeile SQL schreiben zu müssen.
Und wissen sie, was das allergeilste (‚tschuldigung) daran ist? Wenn man mit dem Abfrageergebnis zufrieden ist, kann man in den SQL-Modus schalten, sich das Statement herauskopieren und ohne großartige Änderungen in MySQL weiterverwenden. Meistens muss man nur ein paar einfache oder doppelte Hochkommata austauschen, und das Jet-SQL läuft auf der MySQL-Datenbank genau so fehlerlos wie es auf Access gelaufen ist. Das nenne ich Arbeitserleichterung allererster Sahne!
Die Beziehungsverwaltung
Mehrfache Joins über vier, fünf, zehn Tabellen? Hab ich in ein paar Minuten zusammengeklickt. m:n-Beziehungen mit Zwischentabelle? Ebenso. Visualisierung der Beziehungen innerhalb der Datenbank? Erstklassig, das kann man per Screenshot rauskopieren und sich gerahmt an die Wand hängen, so übersichtlich ist die grafische Oberfläche des Beziehungseditors. Ich zeig mal ein Beispiel mit importierten WordPress-Tabellen:
beziehungen in access
Das nenne ich übersichtlich! Sowas kann man auch mit zum Kunden nehmen, oder in Arbeitsbesprechungen mit den Kollegen als visuelle Gedächtnisstütze verwenden. Von sowas kann MySQL nur träumen!
Ja aber – unsere Daten stecken doch in MySQL!
Wo ist das Problem? Export der Tabellen als CSV im phpmyadmin, Import externer Daten nach Access, Beziehungen zusammenklicken und durchstarten, fertig und aus die Maus. Oder man geht gleich via ODBC direkt auf die mySQL-Tabellen, geht auch einwandfrei.
Gerade bei so unübersichtlichen Tabellenkonglomeraten wie sie in WordPress zusammengeschustert worden sind, ist Access mein Mittel der ersten Wahl, um den Überblick zu behalten.
So, jetzt habe ich aber genug geschwärmt. Access ist mein Arbeitspferd und zuverlässiger Entwicklungshelfer, wann immer es um Datenbanken geht, und ich kann ihnen nur ans Herz legen, sich auch mal damit zu befassen, es spart nämlich unheimlich Zeit und Nerven.
Wenn Access so toll ist, warum ist es dann nicht weiter verbreitet?
Weil Microsoft mit dem rasend erfolgreichen MS SQL-Server die Konkurrenz im eigenen Haus forciert, und weil Access nicht wirklich für Mehrbenutzer-Umgebungen geeignet ist. Aber am Einzelarbeitsplatz als Entwicklertool, da ist es einsame Spitze!
Ich habe im vorigen Artikel schon ausführlich darüber gesprochen, wie wichtig die Besucherzahlen einer Internetseite für SEO-Zwecke sind. Jetzt möchte ich ein bißchen näher beleuchten, wie diese Besucherzahlen überhaupt zustande kommen.
PHP-Skripte für Besucherzähler
Besucherzähler gibt es wie Sand am Meer, vom einfachen PHP-Snippet bis zum ausgefeilten Plugin mit allen statistischen Schikanen. Ich gehe hier mal nicht näher auf die technischen Feinheiten ein, sondern erkläre nur mal das Prinzip, wie so ein Besucherzähler überhaupt funktioniert.
Woher weiß die Webseite, daß sie jemand besucht?
Ganz einfach, wenn man eine Internetseite im Browser aufruft, wird am Webserver der Seite eine neue Session für den neuen Besucher erzeugt. Diese Session enthält allerhand interessante Informationen über den Besucher, aber dazu später mehr. Im einfachsten Fall kann man also die Anzahl der Sessions in einem bestimmten Zeitraum zählen und hätte schon mal einen groben Überblick, etwa Sessions pro Tag oder pro Woche. Das ist aber statistisch noch nicht sehr aussagekräftig, weil nicht unterschieden werden kann, ob jetzt X verschiedene Besucher die Seite jeweils einmal aufgerufen haben, oder ob es im Extremfall nur ein Besucher war, der die selbe Seite X mal aufgerufen hat. Deswegen gibt es:
Besucherzähler mit IP-Sperre
Die meisten modernen Besucherzähler arbeiten mit sogenannter IP-Sperre, damit realistischere Besucherzahlen erhoben werden können. Der Knackpunkt dabei ist, daß anhand der IP-Adresse der Besucher genau unterschieden werden kann, ob es denn wirklich viele verschiedene Besuchersessions waren oder immer nur ein und der selbe.
Woher weiß das PHP-Skript meine IP-Adresse?
Die ist in der Session als sogenannte Superglobale Variable abrufbar. Da gibt es übrigens noch mehr interessante Informationen über sie, etwa welchen Browser sie benutzen, von welchem Server aus sie die Seite aufrufen und vieles mehr. Das ist den meisten Internetbenutzern nicht bewußt, viele denken, wenn man nur im Internet herumsurft und sich nirgendwo mit Paßwort und Username anmeldet, sei man anonym. Das ist ein gründlicher Irrtum, aber dazu wird es später noch einen Beitrag geben.
Jedenfalls ist per PHP die IP-Adresse abrufbar, und so kann man unterscheiden, wie viele verschiedene Benutzer die Seite besucht haben. Paßt aber auch noch nicht so ganz:
Und wenn ich am nächsten Tag die Seite wieder besuche?
Dann haben sie immer noch die gleiche IP-Adresse, und das Skript würde sie nicht als neuen Benutzer registrieren, weil sie ja mit der selben IP-Adresse schon mal da waren.
Ein Kompromiss: Cookie mit Timeout
In der Praxis macht man es oft so: beim Start der Session setzt man auf ihrem Rechner ein Cookie, in dem eine Timeout-Zeit vorgegeben wird. Dann wird nicht nur ihre IP-Adresse abgefragt, sondern zusätzlich noch, ob die in dem Cookie festgelegte Zeitspanne schon abgelaufen ist oder nicht.
Die Cookie-Timeout-Zeit wird meistens zwischen ein und drei Stunden festgelegt, weil man allgemein annimmt, daß das eine gute durchschnittliche Verweildauer innerhalb einer Session ist. Das heißt mit anderen Worten: wenn die Timeout-Zeit des Cookies noch nicht abgelaufen ist, wird der Besucherzähler aufgrund ihrer IP-Adresse nicht hochgezählt. Erst wenn die festgelegte Zeit vorbei ist und sie die Seite nochmal ansurfen, zählt es als neuer Besuch, der Besucherzähler schaltet um eins hoch.
Besucherzähler zählen also nur ungefähr
Hab ich das verständlich ausgedrückt? Ich hoffe schon, denn hier passiert etwas ganz Wichtiges. Man muß sich darüber im Klaren sein, daß ein Besucherzähler niemals ganz exakte Werte liefern kann, das hängt immer von vielen Faktoren ab. Die Cookie-Timeout-Zeit ist genau genommen ein willkürlich festgelegter Wert und spiegelt keinesfalls die Realität exakt wieder. Es handelt sich immer nur um ungefähre Werte, je nachdem mit welcher Methode der Besucherzähler programmiert ist und wie die Programmparameter gesetzt sind.
Man darf die Besucherstatistiken auf Internetseiten nicht als wissenschaftlich exakt miss-interpretieren, und ich setze sie zwar auf meinen eigenen Seiten auch ein, aber ich überbewerte ihre Zahlen nicht. Sie sind ein ungefährer Anhaltspunkt, und nicht das Maß aller Dinge!
Ich möchte hier als Schlußwort gerne eins meiner Lieblings-Sprichwörter zitieren: Trau keiner Statistik, die du nicht selbst gefälscht hast!
