ScriptBlogger

Ein Anwender schrieb:

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

:-[]

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.

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.

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. :-)

Ein Kunde unseres Schedule Organizers hatte ein paar knifflige Fragen und schrieb dann abschließend:

Ansonsten - sie haben da ein geniales Tool auf die Beine gestellt - echt top!

:-)

Vor kurzem im Support-Forum aufgetaucht:

I have been using the short URL script for about two months on many posts. It has to be up there with some of the best systems I have encountered in several years. It works flawlessly, and of course, is very fast compared to the "Free Short URL Systems" on the internet. I am now master of of my URL's.

It is perfect.

:-)

Warum selbst machen, wenn andere es besser können. Prinzipiell kein schlechtes Motto. Außer vielleicht,  wenn man sein Können beweisen soll. Zum Beispiel als Informatikstudent.

Also if I wanted a be-spoke organiser from yourself based around this one how much would it cost? For example I would like a PHP script which makes appointments for a hairdresser, but it would need to look like a student create the PHP script. 

B-) 

Es gibt Situationen, da bietet sich die Nutzung des Telefon nicht nur an, sie zwingt sich sogar auf.

Ein Kunde von uns betreibt eine Website mit Informationen zum Thema Krankenversicherung. Besonders beliebt bei den Besuchern ist das Adressverzeichnis. Leider ist der Link zum Kontaktformular nicht weit und so passiert es nicht selten, dass sich die Leute mit Ihren Problemen an den Seitenbetreiber statt an ihre Krankenversicherung oder Krankenkasse wenden. Und das trotz eines deutlichen Hinweises oberhalb des Kontaktformulars.

So passierte es dann, dass kürzlich eine E-Mail eintrudelte, die mit EILT!!!!!!! eingeleitet wurde und im Wesentlichen erklärte, dass der Absender einen fünfstelligen Betrag an Krankenkassenbeiträgen doppelt überwiesen hatte. Mit Hinweis auf die "[...] fatalen Folgen für den weiteren Ablauf des Betriebes." bat man um Rücküberweisung.

Man kann nur hoffen, dass der Absender außer dieser E-Mail noch den Weg per Telefon und Post beschritten hat. Andernfalls...

Dass er sich in der Website vertan hat, ist in der Aufregung eventuell noch verständlich. Obwohl. Wer fünfstellige Beträge aus Versehen doppelt überweist... ;-)

Ein Nutzer unseres Gästebuch-Scripts erhielt eine erstaunliche E-Mail von seinem Webspace-Provider. Dieser schrieb ihm, dass die Datei sign.php des Gästebuch-Scripts Phishing-Material wäre:

We have received notification of phishing material in your account. Phishing files are usually placed through some type of exploit of out dated code, weak file and folder permissions. You must agree to remove this content and update any software that has resulted in security holes. To protect your account from further action you must agree to our request for compliance. Please respond to this message stating your intent to do so.

[...]

Failure to respond to this message within 72 hours will result in the suspension of the affected domain with us until such a time as this matter is resolved.

File path:

http://www.example.com/guestbook/sign.php*

Das ist ein ziemlich harter Ton, den der Provider dort anschlägt. Der Kunde bekommt nicht mal ansatzweise die Möglichkeit, eine Erklärung abzugeben oder die Ungefährlichkeit des Scripts zu versichern.

Das Script wird von Webmastern seit Jahren ohne Probleme auf unzähligen Servern installiert und läuft auf vielen auch heute noch. Erstaunlich ist, dass jetzt plötzlich jemand denkt, dass Script könnte für Phishing missbraucht werden. Man möchte meinen, dass bei über tausend Downloads jeden Monat irgendjemandem mal etwas aufgefallen wäre.

Eine Suche nach phishing "sign.php" ergab übrigens, dass es andere Scripte mit dem Namen sign.php gibt, die durch Sicherheitslücken für Phishing-Zwecke missbraucht werden können. Aber keine dieser Meldungen bezieht sich auf unser Gästebuch-Script.

Als Provider trotzdem gleich alle Scripte gleichen Namens von den eigenen Servern zu verbannen klingt nach Sippenhaftung. Oder Paranoia.

*) URL geändert

Nachdem es hier in letzter Zeit überwiegend positives Feedback von Kunden zu lesen gab, ist's mal wieder Zeit für ausgleichende Gerechtigkeit.

Letztes Jahr im Oktober hatte ein Kunde unser Form Mail Script gekauft. Nach anfänglichen Schwierigkeiten lief das Script dann auch. Abschließend hatte der Kunde noch den Wunsch, dass die E-Mails jeweils an mehrere Empfänger gesendet werden sollen. Wie genau er sich das vorstellte, war mir jedoch nicht ganz klar. Und irgendwie war es auch nicht möglich, mal einen Blick auf die Templates (HTML und Mail) zu werfen.

Nach einigem Hin und Her mit Tipps und Rückfragen waren mittlerweile zwei Monate ins Land gegangen. Nach einer solchen Zeitspanne besteht immer die Gefahr, dass entweder der Kunde die Geduld verliert oder dass die Angelegenheit hier untergeht.

Am 3. Januar schrieb der Kunde seine vorerst letzte E-Mail in der er wissen wollte, mit welchem Zeichen er am besten mehrere Empfänger im Bcc-Header voneinander trennt. Die richtige Antwort wäre das Komma gewesen. Leider habe ich seine E-Mail nie beantwortet.

Dass das keine gute "Idee" war, sollte sich jetzt im September, neun Monate später herausstellen.

Betreff: 10 Months and still trying to get some support

This is really becoming a pain in my ass. I PAID for a product (invoice attached) that I EXPECT to work like it says it should. I can’t even register for your damn forums as when I click the “I agree to the terms button” all it does is refresh the page. It won’t even allow me in to register.

Now, here is my problem again.

I need the freaking form to mail to multiple people, it don’t. Why and how do I fix it.

Ooops.

Es wäre allerdings ganz hilfreich gewesen, wenn der Kunde mal etwas früher nachgehakt hätte. Aber ich stehe dazu, dass die Schuld bei mir liegt und habe mich für den Fauxpas entschuldigt:

You're right. I should have answered your support questions a long while ago. It appears that your e-mail has been overlooked. There is no real excuse for that but I'm getting a lot of e-mails and I occasionally miss an e-mail.

Die Sache hat jedoch einen Haken. Ein rüder Ton mag vielleicht bei anderen ziehen, nicht aber bei mir. Deswegen enthielt meine E-Mail noch folgenden Zusatz:

Anyway, $19 might be a lot of money for some people, but it's not enough for me to read words like "ass" "damn" and "freaking" in an e-mail. Therefore, I'll go ahead and cancel your order and refund your money. There are plenty of other Form Mail Scripts so that you'll have something to fall back on.

Thanks anyway for considering my script in the first place.

Es trudelten hier dann noch eine Hand voll weiterer böser E-Mails ein.

Und was lernen wir aus dieser Geschichte? Leiste vernünftigen Support, sonst machen die Kunden Ärger. Was jetzt allerdings auch wirklich keine bahnbrechende Neuigkeit ist. ;-)

Mal sehen übrigens, ob der (Ex-)Kunde folgende Drohung wahr macht:

Believe me, I will now go out of my way to make posts and reviews on my sites, blogs, article directories and anywhere else that I can find to state what kind of crap you offer.

Eine Support-Anfrage sollte idealerweise in einem freundlichen Ton geschrieben sein, ausführlich das Problem beschreiben und als Sahnehäubchen noch einen Link zum nicht funktionierenden Script beinhalten. Soweit so gut.

Ein Konzept, das an folgendem Fragesteller jedoch komplett verloren gegangen ist:

your programme has given me problems for the past one week. i really need to vote but its jamming. I cant vote for reasons i don't know so please fix this problem because I really need to vote urgently!!!!!!!!!!!!!!!!!!!

;-)

Ein Nutzer unseres Datei-Download-Scripts liefert damit Filme aus. Die Dateien sind jeweils um die 10 GB groß und liegen deshalb auf einem extra Server mit günstigerer Bandbreite.

Der Nutzer äußerte nun den Wunsch, das Script auf dem Server mit der eigentlichen Website (Server A) zu installieren und auf die Filmdateien auf Server B zugreifen zu lassen. Er hätte gern alles unter einer einheitlichen Domain gehabt. Allerdings ist das Script dafür nicht ausgelegt, sondern kann nur Dateien ausliefern, auf die es über einen lokalen (Netzwerk-)Pfad zugreifen kann.

Für den Nutzer hat sich dieser Umstand jedoch als positiv herausgestellt, denn da gab es einen kleinen Denkfehler seinerseits. Wenn nämlich das Script auf Server A installiert ist und auf die Dateien auf Server B zugreift, werden die Dateien immer über Server A geschleust. Das Script liest dabei die gesamte Datei ein und gibt sie an den Browser aus. Und das kostet dann gleich zweimal Bandbreite - einmal auf Server B und einmal auf Server A. Das schien dann doch nicht so ganz im Sinne des Erfinders zu sein. Sah dann auch der Nutzer so:

Thanks a lot for your support! double bandwidth ..... grrhhhhh.nope!

Zumal man einfach eine Sub-Domain einrichten kann, welche dann auf Server B gerichtet ist.

Ein Kunde, der das Form Mail Script gekauft hatte, schrieb:

I just wanted to say thank you for your awesome script. I just purchased a license after I tested it out and modified it to do exactly what I want. There is nothing like this on the Internet that offers so many options and the ability to modify it like I have done.

Keep up the great work, and once again thank you. 

:-)

Erst die Einladung zum Drink und jetzt dies:

DICKES LOB!! Super Support!!

Wenn Sie mal eine Leiter oder ein Gerüst brauchen, ...einfach an mich wenden.

Hm. Erst mal nicht, aber trotzdem danke. :-)