Rubrik-Archiv „Webwork“

MicroPHP: Darf es auch ein bisschen weniger sein?

13.01.2012 Webwork Kommentieren

Mit den etablierten PHP-Frameworks konnte ich mich noch nie so richtig anfreunden. Auf der einen Seite sind die fertigen und (hoffentlich) sauber implementierten Funktionen wirklich praktisch, will man aber nur eine kleine Anwendung bauen, dann wirken Exemplare wie zum Beispiel das Zend Framework wie die sprichwörtlichen Kanonen die auf Spatzen schießen.

Nun möchte ich aber auch keinen Chaoscode im 90er-Jahre-Stil produzieren, weshalb ein wenig Rahmenwerk doch eigentlich ganz hilfreich wäre. Es galt also immer ein schlankes Framework zu finden, das nur so viel wie gerade nötig vorgibt und gleichzeitig nicht zu viele Abhängigkeiten erzeugt. Das Problem ist allerdings, dass sich viele Frameworks da draußen als „schlank“ bezeichnen, sich bei näherer Betrachtung aber nicht als solches herausstellen.

Zwischenzeitlich schien ich mit dem Kohana Framework einen einigermaßen geeigneten Kandidaten gefunden zu haben. Ein massiver API-Wechsel zwischen dem 2er und dem 3er Entwicklungszweig hat mir dann aber schnell den Spaß an der Sache ziemlich verdorben. Was mich letztendlich auch dazu bewegt hat, mich wieder auf die Suche nach einer Alternative zu begeben.

Im letzten Jahr bin ich dann auf das, zu dem Zeitpunkt gerade „stable“ gewordene, Slim Framework gestoßen. Slim wird seinem Namen wirklich gerecht und kombiniert mit ein paar selbst gebastelten Skripten, die den Kern für meine Anwendungen darstellen, lassen sich damit auch recht entspannt etwas umfangreichere Webanwendungen umsetzen. Im Umfeld von Slim und ähnlichen Frameworks hat sich gerade eine Trend heraus kristallisiert, der unter dem Schlagwort „MicroPHP“ diskutiert wird und der die oben geschilderte Problematik aufgreift. Neben dem MicroPHP-Manifest, habe ich jetzt diesen lesenswerten Artikel zu dem Thema gefunden und ich hoffe das weitere Folgen und die dort aufgezeigten Entwicklungen an Fahrt gewinnen werden. Vielleicht wird PHP sogar irgendwann wieder sexy, wer weiß?

Passwortschutz und URL-Rewriting

07.07.2010 Webwork Kommentieren

Möchte man ein Verzeichnis – zum Beispiel ein einfaches Administrationsmenü – mit einem Passwortschutz versehen ohne dabei eine überdimensionierte ACL zu bemühen, bieten sich die meist mitgelieferten Möglichkeiten des Apache-HTTP-Servers an. Allerdings ist es durch den Einsatz von CMS, Frameworks und mod_rewrite mittlerweile fast der Regelfall, dass vermeintliche Verzeichnishierarchien im URL nicht mit einer „physischen“ Verzeichnisstruktur im Dateisystem des HTTP-Servers korrespondieren und somit nicht möglich einfach eine entsprechende .htaccess-Datei in ein Verzeichnis zu legen. Wie man einen derartigen Passwortschutz dennoch relativ einfach realisiert, möchte ich nachfolgend kurz beschreiben.

Der gute alte Passwortschutz

Möchte man den URL http://example.com/admin/ mit einem Passwortschutz versehen und das Verzeichnis existiert tatsächlich im Dateisystem, reicht es eine .htaccess-Datei mit dem folgenden Inhalt in diesem Verzeichnis anzulegen (Vorausgesetzt eine entsprechende Passwort-Datei existiert):

AuthType Basic
AuthName "Anmeldung erforderlich"
AuthUserFile /Pfad/zu/Passwort-Datei
Require valid-user

Dies ist eine leichte Übung und die Vorgehensweise lässt sich auch in der Dokumentation des Apache-HTTP-Servers nachlesen.

Zugriffs-URI-basierter Passwortschutz

Gibt es das vermeintliche Verzeichnis allerdings gar nicht im Dateisystem, sondern existiert dieses nur in Rewriting-Regeln, dann fehlt schlichtweg der Ort um die entsprechende .htaccess-Datei abzulegen. Dies ist aber auch nicht zwingend notwendig, da man den Apachen mithilfe des Moduls SetEnvIf trotzdem dazu überreden kann, das „Geisterverzeichnis“ über die Abfrage von Zugangsdaten zu schützen. Dazu legt man eine .htaccess-Datei mit dem folgenden Inhalt im Wurzelverzeichnis an, auf das http://example.com zeigt, bzw. ergänzt die gegebenenfalls schon Vorhandene:

AuthType Basic
AuthName "Anmeldung erforderlich"
AuthUserFile /Pfad/zu/Passwort-Datei
Require valid-user

SetEnvIf Request_URI "/admin" req_auth=1

Order Allow,Deny
Allow from all
Deny from env=req_auth
Satisfy any

Über die SetEnvIf-Direktive weist man den HTTP-Server zunächst dazu an, die Umgebungsvariable req_auth (diese kann auch anders genannt werden) zu setzen, sofern der Zugriffs-URI „/admin“ lautet. Im weiteren erlaubt man nun jedem den Zugriff (durch das Ablegen der .htaccess im Wurzelverzeichnis hätten wir sonst den Zugriff auf die komplette Website unterbunden) und verbietet den Zugriff, sofern die Umgebungsvariable req_auth gesetzt ist. Mit der abschließenden Satisfy-Direktive wird dafür gesorgt, dass es reicht, dass eine der beiden Bedingungen (req_auth nicht gesetzt oder angemeldeter Benutzer) erfüllt ist. Fertig. Freuen.

Browser-Update.org

25.03.2009 Netz und Web, Webwork Kommentieren

Browser-Update.org: Logo Peter Kröner weist in der 40. Ausgabe seiner wöchentlichen Linksammlung unter Anderem auf die Initiative Browser-Update.org hin. Ziel der Initiative ist es, per dezentem Hinweis und sachlichen Argumenten, Benutzer zum Update auf einen aktuellen Browser zu bewegen. Das entspricht ziemlich genau meiner – vor einem Jahr geäußerten – Vorstellung von einer Browser Upgrade Initiative. Gerade gestern hatte ich mit einer webseiten-spezifischen Implementierung dieser Idee begonnen. Die Gestaltung einer Infoseite zu den Nachteilen alter und den Vorteilen neuer Browser kann ich mir dank Browser-Update.org nun sparen.

IE 6: Während die Deutschen diskutieren
…

19.02.2009 Webwork 1 Kommentar


…lassen die norwegischen Webmaster grüne Boxen sprechen und an anderer Stelle wird zum IE Death March geblasen.

Vor fast genau einem Jahr schwappte mal wieder der Frust über den Internet Explorer 6 durch einige deutsche Blogs und entlud sich in einer kleinen Revolte. Auch wenn sich die meisten Webmaster darüber einig sind, dass man den IE 6 endlich los werden muss, wurde damals viel diskutiert. „Sollte man den Nutzer wirklich bevormunden?“, „Ist es nicht Aufgabe eines guten Webmasters, seine Seite möglichst kompatibel zu halten?“. Damals wie heute halte ich eine gezielte Aufklärungskampagne für eine sinnvolle Maßnahme.

Da es die aktuellen Aktionen gegen den IE 6 in den Heise-Newsticker geschafft haben, ist es vielleicht an der Zeit, auf den Zug auf zuspringen. Vielleicht schafft es das Thema ja aus der Webworker-Ecke heraus in eine allgemeinere Wahrnehmung? (Sicherheit und Datenschutz sind Stichworte, die in diesem Zusammenhang die Aufmerksamkeit erhöhen könnten.) Andererseits sollte man das vielleicht lieber nochmal ausführlich diskutieren…

Das große CMS-Dilemma

08.10.2008 Webwork 2 Kommentare

Die beiden Artikel von Gerrit und Peter sowie die jeweils daran anschließenden Diskussionen veranschaulichen wieder einmal das Dilemma im Zusammenhang mit der Auswahl und Nutzung von Content Management Systemen. Insbesondere bei kleineren Websites, die durch Benutzer (also nicht Entwickler oder Designer) mit Inhalten versehen werden sollen, driften die identifizierten Anforderungen und die durch die verfügbaren CMS realisierten Möglichkeiten oft stark auseinander. Erschwerend kommt hinzu, dass die schiere Menge der verfügbaren CMS jeden Normalsterblichen vor eine unlösbare Evaluationsaufgabe stellt.

Diskrepanz zwischen Anforderungen und Features

Generell soll das gesuchte CMS einfach zu bedienen sein, gleichzeitig aber genügend Freiheiten bieten um die geplante Struktur sowie Design und Layout der Website umsetzen zu können. Die verfügbaren CMS sind aber einerseits schwergewichtige und komplexe Gebilde mit vielfältigen, meist nicht benötigten Features, die auch gestandene Webentwickler abschrecken. Auf der anderen Seite existieren vielversprechende Ansätze mit übersichtlichen und einfach zu bedienenden Backends. Diese in der Regel schlanken Vertreter der Spezies CMS befinden sich allerdings meist in einem frühen Stadium der Entwicklung und weisen damit nicht alle benötigten Features auf oder sind noch nicht für den produktiven Einsatz geeignet. Hinzukommt dass sich bei jungen Projekten schlecht abschätzen lässt, wie aktiv diese in Zukunft gepflegt werden, was für einen langfristigen Einsatz ein K.O.-Kriterium darstellen sollte. Es stellt sich die Frage warum der Bereich der schlanken, leicht zu bedienenden und darüber hinaus ausgereiften CMS so dünn besetzt ist.

Vom schlanken Projekt zur überladenen Bloatware

Die Ursache für dieses Dilemma liegt meiner Meinung nach an dem Verlauf der Entwicklung eines CMS-Projektes. Initialzündung vieler in den letzten Jahren entstandener CMS-Projekte ist die Erkenntnis, dass die verfügbaren CMS viel zu überladen und die Backends zu umständlich sind. Die ersten und wichtigsten Features sind dann dank der Verfügbarkeit ausgereifter Frameworks schnell implementiert. Danach entscheidet sich dann ob das Projekt wieder einschläft oder aufgrund des Anklangs bei anderen Usern aktiv weiter entwickelt wird. Und genau hier liegt auch die Ursache des Dilemmas: Damit das Projekt erfolgreich bleibt, müssen die Entwickler auf die Wünsche der User eingehen, also Features die von einer Vielzahl der Nutzer gewünscht werden hinzufügen. Außerdem besteht bei einer aktiven Nutzerschaft ein Anreiz weiterzuentwickeln und möglichst regelmäßig neue Versionen herauszubringen, da dies verstärkt mit hoffentlich positivem Feedback belohnt wird. Letztendlich führt dieser Entwicklungs- und Implementierungsdrang aber dazu, dass das CMS immer komplexer wird. Diejenigen User, die die Entwicklung des CMS schon seit einem frühen Stadium mitgemacht haben, werden von der Komplexität nicht abgeschreckt, da sie sich mit dem System auskennen. Für die meisten anderen erscheint es jedoch im schlimmsten Fall wie überladene Bloatware. Dieser Trend zur „Featuritis“ bei zunehmendem Projektalter, lässt sich gerade bei populären CMS oder Blogsystemen – wie etwa WordPress – sehr gut beobachten.

Konsequente Beschränkung auf Kernfunktionalität

Diesem Problem ist sicherlich nur mit einer sehr disziplinierten Konzentration auf zuvor festgelegte Kernfeatures und einer konsequenten Modularisierung beizukommen. Wobei sich hier über die Kernfeatures sicherlich vortrefflich streiten lässt und zudem eine einfache Bedienbarkeit nicht automatisch aus der Beschränkung auf das Wesentliche resultiert. Darüber hinaus dürfte das eine oder andere CMS-Projekt mit genau diesen Vorsätzen an den Start gegangen sein. Die Tatsache, dass es das allseits beliebte leicht zu bedienende CMS (noch) nicht gibt, legt die Vermutung nahe, dass sich dem dargestellten Dilemma nicht entkommen lässt.

Wer möchte den Gegenbeweis antreten und der Welt das gefühlte milliardste CMS bescheren?

Wartungsmodus mit mod_rewrite

29.05.2008 Webwork Kommentieren

Gelegentlich ist es notwendig eine Webanwendung für umfassendere Arbeiten in eine Art Wartungsmodus zu versetzen. Dabei wird dem Besucher dann eine Seite mit einem freundlichen Hinweistext präsentiert, der über Grund und Dauer der Wartungsarbeiten unterrichtet. Bei einigen CM-, Blog-, Webshopsystemen etc. ist ein derartiger Modus bereits integriert und lässt sich einfach über das Admin-Menü aktivieren. Ist dies nicht der Fall, lässt sich eine temporäre Umleitung sehr einfach mit dem Rewrite-Modul für den Apache-Webserver realisieren:
RewriteEngine On
RewriteRule !wartung\.html$ /wartung.html [L]

Leider kann man mit dieser Variante selbst nun auch nicht mehr, etwa für Tests, mit einem Browser auf die Seiten zugreifen. Dies lässt sich ändern, indem die RewriteRule nur anwendet wird, wenn mit einer anderen als der eigenen IP-Adresse (im Beispiel 321.123.321.123) auf die Seite zugegriffen wird.
RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^321.123.321.123$
RewriteRule !wartung\.html$ /wartung.html [L]

Diese Lösung ist soweit ganz praktikabel. Bei dynamischen IP-Adressen muss die Bedingung allerdings sehr wahrscheinlich nach jeder Einwahl angepasst werden (sofern der Wartungsmodus überhaupt so lange aufrecht erhalten wird).

Eine weitere Variante bei der von einem Rechner aus, sowohl der Wartungsmodus, als auch die normale Ansicht der Seite (Testmodus) genutzt werden können, lässt sich wie folgt realisieren:
RewriteEngine On
RewriteCond  %{HTTP_USER_AGENT}  !.*-gEheIm$
RewriteRule !wartung\.html$ /wartung.html [L]

Hier werden alle Besucher auf die Wartungsseite umgeleitet, deren User-Agent-String nicht mit „-gEheIm“ endet. Beim Firefox lässt sich der User-Agent-String recht einfach ändern, indem man „about:config“ aufruft und dort den Schlüssel „general.useragent.extra.firefox“ ensprechend ergänzt. Alternativ lässt sich das auch mit Addons erledigen. Damit lässt sich nun verhältnismäßig einfach zwischen den beiden „Ansichten“ umschalten. Wesentlicher Nachteil dabei ist allerdings, dass der User-Agent-String an jede aufgerufene Webseite übertragen wird und damit nicht wirklich geheim ist. Man sollte also nicht gerade auf fremden Seiten surfen und eventuell sogar noch als Referrer den URL einer im Wartungsmodus befindliche Seite hinterlassen.

Linux für Webworker

01.05.2008 Linux, Webwork Kommentieren

Peter Kröner hat gerade eine Artikelserie gestartet, in der er darstellt, wie und mit welcher Software die üblichen Aufgaben beim Erstellen von Webprojekten unter Linux bewältigt werden können. Im ersten Teil geht er kurz auf die Entstehungsgeschichte ein, zeigt die Besonderheiten offener Software auf und nennt ein paar Argumente für und gegen die Nutzung von Linux. Die Hinweise auf die geplanten Themen der Artikelserie sehen recht vielversprechend aus. Insbesondere das Thema Bildbearbeitung und das damit verbundene Totschlagargument „Photoshop“ dürften recht interessant werden.

Green Markup – Green IT für Webseiten

05.03.2008 Allgemein, Webwork 1 Kommentar

Green IT ist bei der diesjährigen CeBIT zum zentralen Thema erkoren worden, nachdem der Begriff in den letzten Monaten immer wieder in den Medien auftaucht. So berichtete heise online zuletzt am Wochenende über den exponentiellen Anstieg des Energiebedarfs des Internets. Tausende Server in Rechenzentren rund um den Globus sind nach dem Bericht für ein Prozent des gesamten Weltenergiebedarfs verantwortlich. Die Internet-Infrastruktur und die anderen Kommunikationsnetze erhöhen den Anteil sogar auf drei Prozent.

Nun resultiert der Energiebedarf des Netzes ja aus der Übertragung von Daten in Form von Elektronen und Photonen die um die Welt geschickt werden, wenn E-Mails verschickt, Videos angesehen, VoIP-Gespräche geführt oder Webseiten in den Browser geladen werden. Auch wenn Videostreaming in letzter Zeit verstärkt für den Anstieg des Traffics verantwortlich ist, macht der Download von Webseiten, nach einer im Juni 2007 veröffentlichen Untersuchung, dennoch gut 20 Prozent des Traffic-Aufkommens aus.

Green Markup senkt den CO2-Ausstoß des Internets

Wie kann also der Energiebedarf des Webs gesenkt und damit die negativen folgen für das Weltklima abgeschwächt werden? Ganz einfach: Indem Webseiten mit – im doppelten Wortsinn – sauberem Markup erstellt werden. Schon vor fünf Jahren beschrieb Standards-Papst Jeffrey Zeldman in „Designing with Web Standards“ die Vorzüge von kompaktem Markup und gecacheden Stylesheets. Ging es damals nur um kürzere Ladezeiten, kommt heute noch der Umweltaspekt dazu.

Bezogen auf ein paar kleine Blogs und Firmenpräsenzen hört sich das vielleicht etwas komisch an, wenn man sich das aber bei hochfrequentierten Portalen vorstellt, dann kommen da sicher einige Terabyte im Jahr zusammen. (Mich würde mal interessieren, wieviel Watt pro Gigabyte für welche Strecke in welchem Medium benötigt werden.) Eine standardkonforme Variante der Google-Startseite könnte die Downloadgröße um 21 Prozent reduzieren. Wer weiß wieviel CO2 sich einsparen ließe, wenn Google sich endlich mal von seiner Font-Tag-Soup verabschieden würde. Es ist aber einfach medienwirksamer die Startseite für fünf Minuten mit einem schwarzen Hintergrund auszuliefern. Das merkt auch jeder DAU.

Neue Standards, grüneres Markup

Weiteres Einsparpotential steckt übrigens in neueren Versionen der Webstandards. Wenn man an die Möglichkeit von CSS3 denkt, mehrere Hintergründe für ein Element festzulegen zu können, dann kann man sich vorstellen, dass in Zukunft einige verschachtelte Box-Elemente weniger im Netz umher schwirren. Das Gleiche gilt für mehrspaltige Layouts. Selbstverständlich würde das den Einsatz aktueller Browser voraussetzen, was gleichzeitig noch die Notwendigkeit von speziellen Hacks und zusätzlichen Stylesheets für inkompatible Browser reduzieren würde.

Browser Upgrade Initiative

29.02.2008 Webwork 4 Kommentare

Regelmäßig bricht bei Webentwicklern der Frust über das leidige Thema der Webstandardkompatibilität von Browsern aus. In den meisten Fällen ist die Ursache für diesen Frust in der Interpretationsfreudigkeit älterer Versionen des Browsers eines großen amerikanischen Softwarekonzerns zu finden. In den letzten Tagen schlägt dieser Frust mal wieder kleinere Wellen in Form von drastischen Forderungen und Maßnahmen, die den Benutzer dazu bewegen sollen seinen Browser auf den neusten Stand zu bringen oder sogar den Browser zu wechseln.

Grundsätzlich halte ich eine derartige Beeinflussung für sinnvoll. Mit Sicherheit ist das Argument, dass der Benutzer selbst darüber entscheiden sollte welchen Browser er benutzt berechtigt. Allerdings habe ich Zweifel daran, dass diese Entscheidung von den meisten derjenigen die mit veralteten Browserversionen unterwegs sind, bewusst getroffen wird.

Was ich allerdings an den oben erwähnten Maßnahmen und der Diskussion dazu für wenig sinnvoll halte ist, dass sie sich explizit gegen eine Version eines Herstellers richten. Meiner Meinung nach sind aber nicht die Fehler der konkreten Version das Problem, sondern die Tatsache, dass veraltete Browser Web Standards und deren spezielle Features in der Regel schlechter unterstützen als neue Browser. Daraus resultiert, dass sich der„Hass“ der Webentwickler bei jeder Veröffentlichung einer neuen Browserversion jedes mal gegen die Vorgängerversionen richtet. Und genau das macht sehr drastische Maßnahmen unglaubwürdig und lässt den eigentlich wünschenswerten Effekt solcher Kampagnen verpuffen.

Meine Vorschlag wäre eine wiki-basierte Webseite zu schaffen, die auf der Startseite kurz und prägnant die wesentlichen Vorteile eines Browser-Upgrades zusammenfasst und Upgrademöglichkeiten aufzeigt. Zusätzlich können Unterseiten zu einzelnen Browserversionen und deren Schwachstellen eingerichtet und dort ausführlichere Informationen zum Nutzen eines Upgrades geliefert werden. Durchaus denkbar wären auch abgestufte Unterseiten ähnlich wie bei den unterschiedlichen Ausprägungen der Creative Commons-Lizenzen. Auf diese könnte man verweisen, wenn man zwar diverse Anpassungen für veraltete Browserversionen vorgenommen hat, man den Benutzer aber trotzdem auf die Vorteile eines Upgrades hinweisen möchte.

Ein absolutes Muss wäre auch eine Feedbackmöglichkeit, durch die Benutzer mitteilen können, warum Sie nicht upgraden wollen oder können. Webmaster und Webentwickler können diese Initiative unterstützen indem sie in einigermaßen unaufdringlicher Weise (z.B. wie die kleine gelbe Leiste beim Firefox, wenn ein PopUp geblockt wurde oder ein Plugin fehlt) auf sie verlinken und außerdem mit ihrem fachlichen Wissen zur Verbesserung der Wiki-Artikel beitragen. Somit könnte in konstruktiver Weise – auch von kommerziellen Webseiten aus – Aufklärungsarbeit geleistet und die Sensibilität der Benutzer für das Problem veralteter Browserversionen gefördert werden. Das Ergebnis wäre dann hoffentlich eine gesteigerte Upgrade-Freudigkeit.

Wenn ich nicht der Einzige bin, der einer derartigen Initiative etwas abgewinnen kann, dann ließe sich da doch bestimmt gemeinsam etwas auf die Beine stellen, oder?

Zum Seitenanfang