ScriptBlogger

Früher wurde alles noch manuell gemacht. Da haben wir Infos abgetippt oder bestenfalls kopiert und eingefügt. Bei einem Projekt zum Beispiel musste einmal in der Woche das Kinoprogramm auf den neuesten Stand gebracht werden. Die Daten kamen per Fax. :-O

Irgendwann hat's dann gereicht. 200 Zeilen PHP übernehmen nun den Job und "ziehen" sich die Daten automatisch von den offiziellen Kino-Websites. Ein Knopfdruck und keine 3 Sekunden später ist die Sache erledigt und das Kinoprogramm aktualisiert und online verfügbar.

Schon klar, das ist keine große Sache. Aber manchmal sind es die kleinen Dinge, die einem den Alltag angenehmer machen. ;-)

Ständig produzieren die Server von Domainfactory und Domaingo - Webspace und Managed Server - folgende Fehlermeldung:

Notice: session_start(): ps_files_cleanup_dir: opendir(/tmp) failed: Permission denied (13)

Lösungsvorschlag vom Support: Den Speicherort für die Session-Dateien per php.ini ändern oder Notices per error_reporting ausblenden. Beides wird sicherlich funktionieren, löst aber die Ursache des Problems nicht. :-(

Damit die eigenen Scripte heruntergeladen oder gekauft werden, braucht es interessierte Besucher. Und wo suchen Webmaster nach Scripten? In Script-Verzeichnissen. Es gibt hunderte davon. In unserer Datenbank befinden sich derzeit 106 Websites, in die wir unsere Scripte eintragen - mehr oder weniger.

Wenn man sich die Verzeichnisse genauer betrachtet und die Log-Dateien auswertet, lässt sich die Auswahl auf eine Handvoll lohnenswerter Kandidaten einschränken. In die Wertung flossen die Daten von GentleSource, STADTAUS.com und Schedule Organizer, erhoben über einem Zeitraum von drei Monaten ein.

Unser Kommentar-Script wurde vom Start weg gut angenommen und liegt hinter dem Schedule Organizer und dem Form Mail Script auf Platz drei der Beliebtheitsskala. Es stellt sich heraus, dass es noch viel beliebter ist, als wir dachten.

Auf der Seite PHP.HTML.it (Italienisch) hat man unserem Script eine siebenseitige Installationsanleitung gewidmet, komplett mit Screenshot und Beschreibung jeder einzelnen Funktion. Das Script wird mit sehr viel Wohlwollen und als "einfach und intuitiv zu installieren" beschrieben. :-)

Nach einer gewissen Zeit im Geschäft überraschen einen immer weniger Dinge. Für etwas Abwechslung in dieser Routine sorgte vor einigen Monaten ein neuer Kunde, dessen Projekt mit über 100 Datenbanktabellen daher kam.

Von Konfigurationstabellen mit weniger als zehn Datensätzen bis hin zu Log-Tabellen mit Millionen von Datensätzen war alles dabei.  Auf einem unserer Rechner (2 Ghz, 2 GB RAM) brauchte phpMyAdmin rund 15 Sekunden, um die Tabellenübersicht zu laden. :-o

Der Hostblogger plagt sich mit undankbaren Software-Entwicklern herum und den Kommentaren unter dem Beitrag lässt sich entnehmen, dass dies kein Einzelfall ist.

So ganz nachzuvollziehen ist die Einstellung solcher Entwickler tatsächlich nicht. Wenn jemand Zeit und Wissen investiert, ist es doch nur fair, den Code auch zu nutzen. Man kann die neue Option doch standardmäßig ausgeschaltet lassen.

Wir haben bereits jede Menge Code von unseren Kunden und Nutzern bekommen und auch verwendet [1]. Bei einem Fall allerdings waren die Anpassungen dermaßen umfangreich, dass das Übernehmen des Codes recht aufwändig gewesen wäre, beziehungsweise aufwändig sein wird. Noch ist die Sache nicht abgeschrieben und wir hoffen immer noch auf den Moment, dass die Zeitfee uns hold ist und uns ein paar Stunden für die Umsetzung schenkt. ;-)

Immer her also mit den Templates, Sprachdateien, Code-Schnipseln, Anleitungen etc. 

[1] Soweit wir uns erinnern können.

Domaingo schreibt heute in einem Newsletter an seine Kunden, dass es technische Einschränkungen beim E-Mail-System gab. Falls unsere Projekte betroffen waren, haben wir das allerdings gar nicht mitbekommen.

Von den Problemen abgesehen, die Kommunikation von Domaingo ist wirklich vorbildlich. Vorausgesetzt natürlich, die Angaben stimmen auch. ;-)

In dem Newsletter wird detailliert dargestellt, welche Funktion wann und warum nicht verfügbar war. Erfreulich auch, dass Klartext bezüglich der Ursache gesprochen wird, die "... nach aktuellem Kenntnisstand in den Bereich des menschlichen Versagens einzuordnen ist". Wenn sonst bei irgendeinem Anbieter Probleme auftreten, sind üblicherweise Hardware-Fehler, Software-Probleme oder Dritte schuld. ;-) Ausnahmen bestätigen die Regel.

Bleibt zu hoffen, dass die angekündigten strukturellen, organisatorischen und sonstigen Maßnahmen und Notfallplanänderungen auch umgesetzt werden.

Alles in Allem lässt sich jedoch sagen, dass Domaingo in der Vergangenheit immer ein verlässlicher und günstiger Webhoster war. Die Funktionsvielfalt und der Support sind gut bis sehr gut. Aufpassen muss man allerdings, wenn die Besucherzahlen der eigenen Website durch die Decke gehen. Domaingo hat da den Finger ganz fix am Ausschalter, um die eigenen Server vor Überlastung zu schützen.

Zugegeben, ich bin an der folgenden Geschichte nicht ganz unschuldig. Manch einer mag das sogar für eine Untertreibung halten. ;-)

Am 1. Dezember kam eine Bestellung für das Form Mail Script (19 EUR) per PayPal herein, die auch sofort von mir ausgeliefert wurde. Damit war die Sache eigentlich für mich erledigt.

Klingelt letztens das Telefon.

Anrufer: Ich habe Ihren Link auf meiner Seite und habe keine Ahnung wie der da hin kommt.

Ich: Dann geben Sie mir mal die Website-Adresse und ich sehe mir das an.

Auf der Seite angekommen leitet er mich zur Bildergalerie.

Ich: Ah, alles klar. Sie verwenden eines unserer PHP-Scripte. Sie benutzen die kostenlose Version. Deshalb wird auf der Seite ein Werbe-Link angezeigt, der zu einem unserer Projekte führt.

Er: Das ist ja frech.

Wie bitte?

Ich: Wieso ist das frech? Sie nutzen kostenlos unser Produkt und als Gegenleistung wird unser Werbe-Link angezeigt.

Er: Ich kläre das mit meinem Webmaster. Eventuell lasse ich das auch von meinem Anwalt prüfen.

Warum müssen die Leute eine Bagatellsituation ohne Not eskalieren lassen?

Ich: Wir haben Ihnen den Link nicht untergeschoben. Es steht auf unserer Website groß und breit, dass wenn man die kostenlose Version des Script nutzen möchte ein Werbelink angezeigt wird. Wir spielen hier komplett mit offenen Karten.

Er wurde an dieser Stelle kurz ruhig und meinte dann nochmal, er würde das mit seinem Webmaster klären.

Im Endeffekt ist die Situation ganz einfach. Da stimmt mal wieder die Kommunikation zwischen Website-Betreiber und Webmaster nicht. Besonders störend scheint der Link dann aber doch nicht zu sein. Der Anruf ist schon mehrere Wochen her, aber Link und Script sind immer noch online. B-)

Unser Wegwerf-E-Mail-Script ist prinzipiell dafür ausgelegt, auch mit größerem E-Mail-Aufkommen zurechtzukommen. In unseren Testfällen hat das auch immer gut funktioniert, aber grau ist alle Theorie.

Jetzt ergab sich mal wieder die seltene Möglichkeit, das Script auf einem fremden Server zu beobachten. Bei einem Kunden hatten sich während eines Server-Umzugs mehrere tausend E-Mails aufgestaut. Theoretisch müsste sich das Script nun zum E-Mail-Konto verbinden, eine bestimmte Anzahl (voreingestellt ist 200) an E-Mails herunterladen und auswerten, und dann die Verbindung trennen. Außerdem ist vorgesehen, dass dieser Zyklus dreimal durchlaufen wird. Sowohl die Zahl der E-Mails als auch die Zahl der Durchläufe ließe sich bei Bedarf übrigens anpassen.

Zu unserer Freude hat das Script genau das getan, was es sollte und hat die aufgelaufenen E-Mails brav abgearbeitet - eigenständig und ohne ins Schwitzen zu kommen. Schön zu wissen, dass das auch in der Wildnis und nicht nur unter "Laborbedingungen" funktioniert. :-)

Das phpBB ist nicht nur besonders beliebt, sondern konnte über die Jahre auch mit der einen oder anderen Sicherheitslücke aufwarten. Als 2005 das phpBB mal wieder in diesem Zusammenhang  von sich Reden machte und Weblogs und andere Medien darüber berichteten, habe ich mich gefragt, ob unsere Scripte möglicherweise ebenfalls mal auf einer Sicherheits-Mailing-Liste Erwähnung finden würden.

Ich kann nicht sagen, dass ich gewünscht hätte, es würde mal passieren. Schließlich würde jedermann sagen: Seht her, die Typen hier schreiben schlechten und gefährlichen Code - lasst bloß die Hände davon! Im schlimmsten Fall könnte es das Ende für eine Firma sein. Auf der anderen Seite würde es bedeuten, dass wir eine kritische Masse an Nutzern erreicht hätten und es sich lohnt, Exploits zu finden und auf einer Sicherheitsliste zu posten.

Im selben Jahr hatten wir das zweifelhafte Vergnügen, "endlich" auf Bugtraq erwähnt worden zu sein. Solange man allerdings nicht das phpBB oder ein anderer der "Big Players" ist, passiert herzlich wenig. Es strömen keine Hundertschaften von Bugtraq-Abonnenten auf die Website um zu pöbeln oder sich zu beschweren. Und unsere eigenen Nutzer lösten auch keine Welle an Support-Anfragen aus. Es blieb alles ruhig, so dass wir Ruhe den Bug zu beheben und ein Update herauszubringen konnten.

Vom technischen Standpunkt her war es ein eher kleineres Problem, das sich mit vier Zeilen Code lösen lies. Hat keinen halben Tag gedauert, bis wir die neuen Versionen für die drei Scripte draußen hatten. Hätte schlimmer kommen können.

Laut unseren Recherchen ist die Domain scriptblogger.de frisch und war bisher noch nicht in Benutzung. Die Domain ist bislang (Stand 10. Juli) nirgends verlinkt und nirgends eingetragen worden. Trotzdem waren bereits vier Tage nach Registrierung der Domain bereits GoogleBot und der Bot von archive.org da.

Für das Erscheinen des GoogleBot könnte als Erklärung dienen, dass wir den RSS-Feed zum Google Reader hinzugefügt haben. Eine andere Erklärung könnte sein, dass Google generell Domain-Registrierungen überwacht. Letzteres erscheint auch plausibel für den Bot von archive.org. Wie sollte der sonst Wind von dieser Website bekommen haben?

Es ist nicht notwendiger Weise ein schlechtes Zeichen, wenn ein Kunde gleich sechs E-Mails hintereinander schickt. Aber alle E-Mails innerhalb von 30 Minuten ist ebensowenig ein gutes Zeichen. Letzteres sollte sich bewahrheiten, als sich der Inhalt als recht unerfreulich erwies.

Es gibt mindestens zwei Gründe warum man seinen Webhoster bitten sollte, auf PHP 5 zu aktualisieren.

Als erstes wären die verbesserten Leistungsmerkmale zu nennen. PHP 5 verarbeitet Scripte schneller und stabiler als PHP 4.

Und zweitens: Seit 1. Januar 2008 wird PHP 4 nicht mehr offiziell weiterentwickelt. Es werden nur noch kritische Sicherheitslücken geschlossen und die auch nur noch bis zum 8. August 2008. Neue Funktionen und unkritische Bug-Fixes werden nicht mehr in PHP 4 einfließen.

Letzteres betrifft zum Beispiel unseren Schedule Organizer, wie mehrere Support-Anfragen gezeigt haben. Ein Fehler in der Funktion html_entity_decode() verursacht eine Warnmeldung beim Aufruf des Scripts. Der Fehler wurde in PHP/5 behoben, nicht jedoch in PHP 4.

Wenn also Ihr Script folgende Warnmeldung anzeigt, ist es Zeit für das Update auf PHP 5:

Warning:  cannot yet handle MBCS in html_entity_decode()! [...]

Hier noch die Meldung der PHP Group, dass PHP 4 nicht mehr weitergepflegt wird und sich eine Aktualisierung auf PHP 5 empfiehlt.

PHP 4 end of life announcement [13-Jul-2007]

Today it is exactly three years ago since PHP 5 has been released. In those three years it has seen many improvements over PHP 4. PHP 5 is fast, stable & production-ready and as PHP 6 is on the way, PHP 4 will be discontinued.

The PHP development team hereby announces that support for PHP 4 will continue until the end of this year only. After 2007-12-31 there will be no more releases of PHP 4.4. We will continue to make critical security fixes available on a case-by-case basis until 2008-08-08. Please use the rest of this year to make your application suitable to run on PHP 5.

For documentation on migration for PHP 4 to PHP 5, we would like to point you to our migration guide. There is additional information available in the PHP 5.0 to PHP 5.1 and PHP 5.1 to PHP 5.2 migration guides as well.

Appointmind - Online Terminreservierung

Appointmind ermöglicht den Kunden, Patienten oder Mandanten einer Firma, eines Arztes oder eines Beraters, Termine über deren jeweilige Website zu reservieren. Bei Appointmind mieten Sie sich ihren Terminkalender, statt ihn auf Ihrem Server zu installieren.

GentleSource

Erweiterungen für die Website wie zum Beispiel Abstimmung, Besucherzähler, Bildergalerie, Datei-Download, Gästebuch, Kontaktformular oder Wegwerf-E-Mail.