ScriptBlogger

Die Community ist in Aufruhr. Steffan Esser hat auf Grund der Diskussionen um den Namespace-Separator PHP geforkt.

:-D 

Hintergrund: Vor ein paar Tagen haben die PHP-Entwickler entschieden, statt Doppeldoppelpunkt, den Backslash als Trenner für Namensräume zu verwenden. Dagegen sträubt sich jedoch der eine oder andere. Erinnert angeblich zu stark an Windows-Pfade.

Ich persönlich hätte ebenfalls die Doppelpunkte favorisiert. Nüchtern betrachtet, macht's jedoch keinen Unterschied.

Ein Kunde unseres Kurz-URL-Scripts schrieb uns, dass sein Script einen Server-Fehler verursacht. Auf den ersten Blick schien jedoch alles zu funktionieren. Testweise "asdfasdf" in das URL-Feld des Scripts eingegeben und auch korrekterweise den Hinweis zum fehlerhaften URL-Syntax erhalten. Beim Eingeben einer korrekten URL in das Formular des Scripts meldete Apache allerdings einen Fehler.

Hm. Hin und her probiert und nach einer Weile ließ sich ein gewisses Muster erkennen. Der Server ließ es generell nicht zu, dass "http://" per POST oder GET an den Server übertragen wurde. Wir haben das mit einem einfachen Test-Script bestätigen können. Parameter wie ftp:// und https:// funktionierten interessanterweise.

Antwort vom Kunden:

It was due to the mod_Security rule set on server.

Ah ja.

Seit heute haben wir Kunden im Nirgendwo. Hier der Auszug aus der Bestellbenachrichtigung:

PLZ + Stadt      = Nowhere, NJ 34567
Land             = USA
Staat / Provinz  = New Jersey

:-o

Jeder Software-Entwickler oder Support-Mitarbeiter kennt solche Typen. Erst den hohen Preis bemängeln und dann mit jedem kleinen Problem den Support belästigen, statt die Anleitung zu lesen.

Um die geht es jetzt aber nicht.

Vor zwei Wochen kam eine Bestellung für den Schedule Organizer inklusive Installationsservice herein. Der Fragebogen ging noch am selben Tag an den Kunden. Da wir allerdings auch nach knapp zwei Wochen keine Antwort erhalten haben, hakten wir vor ein paar Tagen nach. War wohl 'ne gute Idee:

Thank you for following up! I really do appreciate that!!!

Außerdem schrieb der Kunde, dass er das Script bereits installiert hat. Er versprach aber, den Fragebogen ausgefüllt zurückzusenden. Na gut, bleibt uns dann wenigstens noch die Konfiguration und die Layout-Anpassung. Außerdem schrieben wir dem Kunden noch:

We hope we can do enough for you to earn the money you've spent for the installation service.

Und es schien sich tatsächlich eine Möglichkeit dafür aufzutun. Der Kunde wollte nämlich bestehende Daten in die Datenbank importiert haben. Wir boten ihm an, das für ihn zu übernehmen. Wir teilten ihm das gewünschte Format mit und erhielten kurz darauf die Daten.

Leider waren wir nicht flink genug.

I've already got the data into the database, but thank you for offering to do it!

Hallo? Das wollten wir doch machen.

Wenigstens blieb dann noch ein Problem mit den Konfigurationsdateien und der Kunde versprach, dass wir uns darum kümmern dürften:

I do need help with my customized config file though. It is giving me some wierd results.

Can I send it to you, along with how I need it set up and can you tell me where I have messed up?

Das las sich vielversprechend. Doch wie groß war später die Enttäuschung.

I've also figured out where I made mistakes on the config files and have corrected those and now ready to publicly deploy! Thanks for the support you offer and have given!

Wieder nix mit Support. Außerdem schrieb er noch:

No problem... it was just an opportunity for me to learn how. Always a good thing to learn more! The more I see how this application is built and configuration, the more I really like it and the doctors I'm setting it up for will really like it also!

Die Auszeichnung "Kunde des Jahres" ist hiermit offiziell verliehen. Die Messlatte für 2009 liegt jetzt ziemlich hoch. 

Es gibt mittlerweile für wohl fast jedes Anwendungsgebiet eines oder mehrere Scripte. Manche sogar kostenlos oder Open Source. Da lohnt es kaum noch, selbst etwas zu entwickeln, richtig? Nun ja.

Kaum ein Programmierer arbeitet gern mit dem Code von jemand anderem. Es dauert seine Zeit, bis man sich mit dem Stil und dem Inhalt vertraut gemacht hat. Und mancher Stil und Inhalt zwingt einen geradezu, alles neu zu schreiben.

Ähnlich sieht es aus, wenn ein Kunde eine derart individuelle Version benötigt, dass bestehende Lösungen nicht in Frage kommen. Und es gibt Scripte, die einfach nicht dafür geschaffen sind, mal eben eine neue Funktionalität hinzufügen.

Die größte Bedeutung für uns hat jedoch folgender Punkt: Wenn man in der Lage ist, selbst ein gutes und nützliches Script zu erstellen, warum sollte man das nicht auch tun? Auf diese Weise kann man als Software-Unternehmen sein Portfolio erweitern und sorgt so langfristig für Umsatz.

Da hat jemand nach einer "inoffiziellen Demo-Version" unseres Schedule Organizer gesucht und ist in diesem Blog gelandet. Und falls derjenige da draußen wirklich fündig wird: Was nützt ihm eine alte Version und kein Support im Fall eines Problems?

Wir arbeiten seit über zehn Jahren im und mit dem Internet. Die meisten geschäftlichen Absprachen betreffen selten größere Beträge und erfolgen formlos per E-Mail. Die Sache ist ja auch meist klar. Kunde schickt seine Liste mit Anforderungen, wir antworten mit Kostenvoranschlag, Kunde bezahlt, und wir erbringen die Leistung. Einfacher geht’s kaum noch.

Ab und zu tauchen in E-Mails dann jedoch merkwürdig deplatzierte Sätze wie diese auf.

Könnten Sie mir noch ein rechtsverbindliches Angebot auf Ihrem Geschäftspapier zukommen lassen?

Ein anderer schloss seine E-Mail, die einige Fragen zu einem Script beinhaltete, mit folgenden Worten ab:

Besten Dank für Ihre ausführliche Stellungnahme.

Wird Zeit, dass die Leute im Hier und Jetzt ankommen. 1950 ist schon etwas länger vorbei.

Ein Anwender schrieb:

My hosting service (network solutions) doesn't allow chmod 777. Do you have a work around?

:-[]

Phpinfo() ist nützlich. Phpinfo() erfüllt keinen anderen Zweck, als nützlich zu sein. Warum ein Server-Betreiber phpinfo() manipuliert und unter anderem die Anzeige der Umgebungsvariablen verhindert, wird wohl für immer ein Rätsel bleiben.

Im vorliegenden Fall war der Grund für den Griff nach phpinfo(), dass der Aufruf von getenv('REQUEST_URI') folgendes produzierte:

/www;example.com/beispiel/pfad/datei.php

Der Domain-Name im REQUEST_URI? Ein Semikolon im Domain-Namen? Da ist ja wohl alles falsch.

$_SERVER['REQUEST_URI'] im Gegenzug hat den korrekten Wert angezeigt.

/beispiel/pfad/datei.php

Zum Glück war es nur eine Stelle im Script, die geändert werden musste.

Antwort vom Kunden:

I got Lycos as provider. They somethimes got very strange methodes. The first time i also got problems with oscommerce.

Ein Kunde schrieb soeben:

My Comment Script stopped working and I had to re-install the whole thing.

Großartig. Es wäre eventuell hilfreich gewesen, mal einen Blick auf das Problem werfen zu können.

Was lange wehrt... Nachdem PHP 5 seit Jahren verfügbar und auf vielen Servern parallel zu PHP 4 installiert war und ist, bietet den Aussagen Parallels zufolge Plesk ab Version 9 die Möglichkeit, mehrere PHP-Versionen nebeneinander zu betreiben.

PHP over Fast CGI

Site applications based on PHP implementation will now be executed faster and safer with PHP running in the Fast CGI mode. This enhancement allows running several PHP versions simultaneously.

Großartig. Für die Kombination PHP 4/ PHP 5 kommt das Ganze zu spät, aber PHP 6 wirft ja bereits seine Schatten voraus. Bleibt noch die Frage, wie einfach oder wie aufwändig es sein wird, die zwei PHP-Versionen auf den Server zu bringen. Wir werden sehen.

Verwandter Artikel: Plesk 9 ist verfügbar - halbwegs

Der Anteil funktionaler Analphabeten in Deutschland liegt dem Bundesverband Alphabetisierung und Grundbildung zufolge bei geschätzten 5%. Vom funktionalen Analphabetismus spricht man dann, wenn jemand zwar Buchstaben erkennen und seinen Namen und ein paar weitere Wörter schreiben kann, das Verstehen längerer Texte ihm aber Mühe bereitet.

Im Gegensatz zu den Analphabeten gibt es eine Sorte Menschen, die zwar lesen können, es aber anscheinend nicht wollen. Das sind Menschen, die völlig ignorant gegenüber Hinweistexten und Anleitungen sind. Menschen, die Fragen stellen, zu denen es bereits haufenweise Antworten in Support-Foren gibt und FAQ-Listen gibt.

Da fragt man sich, wozu man bei einem Kundenprojekt folgenden Text überhaupt noch einbaut, ...

Hinweis: Wir betreiben diese Website als ein von Krankenkassen und Krankenversicherungen unabhängiger Anbieter. Bitte richten Sie deshalb Anfragen, insbesondere solche mit vertraulichen Daten und Informationen, direkt an Ihre Krankenkasse oder Krankenversicherung. Nutzen Sie nicht dieses Formular dafür.

... wenn trotzdem ständig E-Mails eintreffen, mit denen niemand außer der Versicherung oder der Krankenkasse etwas anfangen kann. Da werden Versicherungen gekündigt, Adressen geändert, um Informationen gebeten. Zuweilen ist es schon erstaunlich, was Leute alles für Informationen in Formulare auf einer Website eingeben. Die Themen reichen von Sterbehilfe und Krebsvorsorge bis zu Geschlechtsumwandlung - alles dabei.

Aber möglicherweise liegt das Problem ja in der Formulierung des Textes. Für Vorschläge, wie der Text klarer und deutlicher gemacht werden kann, wären wir wirklich dankbar.

Auf die Bitte um Zusendung der FTP-Daten für einen Server antwortete eine Kundin:

I cannot provide you with FTP access, I do not have it set up on my machine. From what I have read it requires full username and password access to all of my box. From what I do understand FTP and even SFTP is not secure. The password and username is not encrypted and is sent in the clear over the internet. [...] I know a lot of people use it but until there is a secure FTP solution I will not use it.

Die Sicherheit von FTP zu hinterfragen ist sicherlich richtig, denn Benutzerdaten und Dateien werden in der Tat unverschlüsselt übertragen. Wenn man dann auch noch SFTP (SSH File Transfer Protocol) als nicht sicher betrachtet, bleiben da nicht mehr viele Möglichkeiten übrig. Bei der Kundin ist's:

Fixed link. The server is right next to me.

Das heißt dann mal wieder Fernwartung per stiller Post.

Drei Möglichkeiten, um zu verhindern, dass Suchmaschinen Seiten mit angehängter PHP-Session-ID in ihren Index aufnehmen:

ini_set() im PHP-Script

ini_set('session.use_trans_sid', false);

.htaccess

php_flag  session.use_trans_sid off

robots.txt

User-agent: *
Disallow: /*PHPSESSID  

Nachtrag:

Die erste Methode per ini_set funktioniert nur bis PHP 4.2.3. Bei späteren PHP-Versionen funktioniet es nur per .htaccess oder, wenn PHP als CGI installiert ist, per php.ini. Letztere kommt in das entsprechende Verzeichnis auf dem Server und hat folgenden Inhalt:

session.use_trans_sid = 0

Wenn ein Script nicht funktioniert, steht man ohne FTP-Zugang so gut wie auf verlorenem Posten. Man kann kein phpinfo() ausführen. Man kann nicht nachsehen, ob die Dateien und Ordner vollständig sind. Man kann die Datei- und Verzeichnisrechte nicht überprüfen. Man kann keine Dateien auf Änderungen prüfen. Deshalb sind Antworten wie diese äußerst unbefriedigend:

I can't give you the login cos my company server got no ftp open to pubic.

Großartig. Fernwartung per E-Mail.

Das Hauptproblem war, dass statt einer aussagekräftigen Fehlermeldung des Scripts, eine Fehlermeldung von PHP angezeigt wurde. Anscheinend ein Bug im System-Modul, welches aussagekräftige Fehlermeldungen anzeigen soll. Ironie des Schicksals.

Der Bug war schnell gefixt und die Datei per E-Mail an den Kunden geschickt. Nach der Rückmeldung durch den Kunden Seite erneut geladen, weiteren Fehler in anderer Datei gefunden, Fehler behoben und neue Datei zum Kunden geschickt. Das Ganze hat sich dann noch ein drittes Mal wiederholt.

Es war dann augenscheinlich, dass die Installationsroutine die Datenbanktabellen nicht erstellt hatte. Haben wir also die Installation nochmals von vorn ausgeführt. Und siehe da. Spuckt unser System-Modul folgende Fehlermeldung aus:

Install File Not Found

../include/sql/install.sql

Es erschließt sich von selbst, dass die Datenbanktabellen nicht erstellt werden können, wenn der entsprechende SQL-Code dafür fehlt. Da hat wohl beim Hochladen der Dateien durch den Kunden irgend etwas nicht funktioniert. Ein paar Tage später hat der Kunde dann die Dateien vervollständigt und siehe da: Installation und Script funktionieren. :-)