Ein Kunde betreibt einen Shop, in welchem er seine Pasta und noch andere italienische Produkte vertreibt. Nachdem bisher nur Trockenpasta verkauft wurde, sollte nun auch noch frische Pasta verkauft werden. Allerdings ist der Versand von frischer Pasta teurer, da Isolationsmaterial und Kühlmittel beigelegt werden müssen.

Keine große Sache, dachte ich mir. Verschiedene Versandtarife für verschiedene Produkte ist ja etwas, was alle möglichen Shops benötigen, also deckt das der verwendete Shopify-Shop sicher mit seinen Versandtarif-Einstellungen ab.
Die Einrichtung sah auch vielversprechend aus: Versandtarif hinzufügen, Produkte auswählen, die den teureren Versand erfordern (kleines Ärgernis, dass sich keine Gruppen/Kategorien auswählen lassen, sondern nur einzelne Produkte), speichern.
Test: Produkt in den Warenkorb, Versandkosten passen, top!

Die Freude war allerdings von kurzer Dauer: Legt man ein weiteres Produkt in den Warenkorb, welches nicht in diesem Versandtarif enthalten ist, werden beim Checkout die normale Versandgebühr plus die erhöhte Versandgebühr berechnet.

Da im Internet keine Lösung mit Bordmitteln zu finden ist, scheint es für diesen vermeintlich oft vorkommenden Fall wirklich von Shopify keine Lösung zu geben.
Diese Problemstellung ist nur mit zusätzlichen kostenpflichtigen "Apps" oder Eingriff in den Template-Code beizukommen.

Natürlich kommt in meinem Fall nur Letzteres in Betracht... ;-)

Da mir die tägliche Info-Mail, die man sich von einer Fritz!Box zusenden lassen kann, zu unpraktisch war, hatte ich erst mit dem Gedanken gespielt, diese von einem Server auswerten und umschreiben zu lassen, bin dann aber auf die TR-064-Schnittstelle gestoßen, die neuere Modelle bieten (welche nicht mehr via Telnet ansprechbar sind).

Im Folgenden ein Ansatz, per PHP auf Daten der Fritz!Box zugreifen zu können.
Ein anderer Ansatz, sich die Daten des Web-UIs abzugreifen, ist in diesem Artikel zu finden. Die beiden Ansätze ergänzen sich teilwese, weil ich über diese TR-064 leider nicht an alle gewünschte Daten rankomme.

Ich sperre schon lange einige meiner privaten und beruflichen Seiten mit Hilfe einer .htaccess-Datei.
Dazu wird – wie den meisten bekannt sein sollte – eine Textdatei mit dem Namen .htaccess in das Webserver-Verzeichnis, für welches (und dessen Unterverzeichnisse) die Beschränkung gelten soll.

Zugriff von außen sperren

Manches Private sollte eher privat bleiben.
Auf einem Webserver, auf den man auch vom Internet aus Zugriff hat, soll die eine oder andere Unterseite nur aus dem internen Netzwerk aufrufbar sein.
Die .htaccess-Datei dafür sieht in etwa so aus:

order deny,allow
deny from all
allow from 172.17.0.0/255.255.0.0

Hiermit haben nur Benutzer aus dem internen Netzwerk Zugriff, die eine 172.17.*.*er-IP-Adresse haben.

Erweiterte Schwierigkeiten durch Proxy

Dies hatte in der Firma einige Weile funktioniert, bis irgendwas an Proxy/Firewall umgestellt wurde.
Seitdem haben Zugriffe von außerhalb des Unternehmens-Netzwerkes eine IP, die so aussieht, als ob sie von innerhalb des Netzwerkes kommen würde (z.B. 172.17.60.10, was oben genannte Regel durchlässt).

Um herauszufinden, an Hand von was man Zugriffe von außerhalb und Zugriffe von innerhalb des Intranets unterscheiden kann, habe ich mir ausspucken lassen, was die $_SERVER-Variable in einem php-Testskript so alles beinhaltet, wenn man von außen zugreift. Gemeinsamer Nenner war HTTP_VIA, in welchem die IP 192.168.248.5 stand, wenn der Zugriff von außen erfolgte (und ansonsten leer war).
Somit konnte ich mein Problem nun mit einer RewriteRule in der .htaccess-Datei lösen.

Aus der Kategorie "warum einfach, wenn's auch kompliziert geht" hatte ich versucht, irgendwie via ODBC von einem Ubuntu-Server auf eine MS-SQL-Datenbank zuzugreifen. Was man dazu im Internet an (verschiedenen!) Anleitungen findet, ist faszinierend.

Nach etwas Trial und ziemlich viel Error musste ich festellen, dass es auch ganz einfach geht und es kein ODBC benötigt, wenn ich von PHP aus auf eine MS-SQL-Datenbank zugreifen möchte.

ZIP-Dateien lassen sich direkt mit PHP-Bordmitteln erstellen.

Im Folgenden ein paar Zeilen für "mein digitales Gedächtnis"...

Meine Intention: Auf einer Website soll man ein hochgeladenes Bild wie rechts abgebildet auf Wunsch beschneiden können. Das Resultat landet wieder als (neue) Bilddatei auf dem Webserver.

Die JavaScript-Funktionen, um den Beschneidungsbereich im Browser auswählen zu können, liefert hierbei die Bibliothek cropper.
Das beschnittene Bild wird dann im Hintergrund mit Hilfe von PHP erstellt (cropper bietet hier zwar eine direkte Lösung, allerdings muss der eingesetzte Browser hierfür HTMLCanvasElement.toBlob verstehen und das sind mir für meinen Geschmack zu wenige Browser, die das können).

Meine Intention: Auf einer Website soll man ein hochgeladenes Bild wie rechts abgebildet auf Wunsch beschneiden können. Das Resultat landet wieder als Bilddatei auf dem Webserver.

Die zwei Grundpfeiler der ganzen Geschichte sind zum einen die JavaScript-Bibliothek cropper und zum anderen der Befehl

 imagecopyresampled

der PHP-GD-Bibliothek.

Die PHP-API-Dokumentation ist für mich eigentlich das Top-Beispiel, wie eine Dokumentation aussehen müsste. Allerdings sind bei mir wohl durch die Beschreibung des Befehles

 imagecopyresampled

ein mehr an grauen Haaren hinzugekommen. Da waren auch die zahlreichen Codeschnipsel im unteren Teil der Seite keine Hilfe, bei denen immer gleich noch skaliert wurde.

Das jQuery FileUpload-Plugin ist eine feine Sache, welches ich inzwischen fast immer verwende, wenn ich auf einer Website eine Upload-Möglichkeit hinzufügen muss.
Mit jQuery FileUpload sind Uploads großer und vieler Dateien keine große Sache. Das Plugin hat nur ein Manko: Zur Dokumentation lässt sich sagen "Ja, ist vorhanden". Aber gerade wegen der vielen Optionen und Möglichkeiten ist sie leider nicht so übersichtlich, wie ein

php.net

oder

api.jquery.com

So beschäftige ich mich immer wieder Stunden damit, eine Lösung zu finden, nur weil bei einer neuen Implementierung eine Kleinigkeit anders sein soll.

Ich will im Folgenden mal meine Best Pracices mit dem jQuery FileUpload-Plugin unter dem Gesichtspunkt "Verwendung mit PHP" zusammenfassen.

Ein praktisches Feature von phpMyAdmin ist die Möglichkeit, "Ansichten" ("Views") zu generieren.
Eine Ansicht ist nichts anderes, als eine "Gespeicherte SQL-Abfrage". Führt man eine bestimmte Anfrage häufiger durch, so speichert man diese am besten als Ansicht und hat diese dann wie auch die eigentlichen Tabellen Datenbank-Baum griffbereit (im Beispiel rechts die Ansicht "falsche außen-sensorwerte").

Möchte man an so eine Ansicht allerdings einmal ändern, gestaltet sich das nicht so einfach, wie die Ansicht ursprünglich erstellt wurde.

All paar Monate greife ich mal wieder auf FPDF zurück und stolpere immer wieder über die etwas gewöhnungsbedürftigen Funktionen der Text-Platzierung.

In welcher Einheit sind die Einheiten? Welche zig Parameter muss ich der Methode übergeben und wie erstelle ich mehrzeiligen Text? Weiterlesen...

Während eine statische HTML-Site angezeigt wird per JavaScript im Hintergrund Abfragen machen – die Möglichkeit bietet JavaScript schon seit Jahren.
Allerdings werden immer zahlreiche Zeilen Code nötig, den XMLHttpRequest() einzurichten und die Antwort entgegenzunehmen.

Ich selbst kopiere mir meine dafür verwendete Funktion immer wieder aus einem anderen Projekt raus und will es nun lieber mal hier in meiner Sammlung hilfreicher Web-Tipps posten.

Ich hoste meine Websites bei Strato und empfehle Strato auch jedem, der sich für eigene Domains und/oder Webspace interessiert.
Inzwischen verwalte ich für mehrere Leute Websites, die jeweils bei Strato liegen. Was mich aber immer wieder nervt: Der Datenbankzugriff (wenn man mal kurz per phpMyAdmin nen Blick reinwerfen will):
Auf die Strato-Homepage gehen, von dämlichem Werbe-Stimmungsbild begrüßt werden, auf Login klicken, einloggen, zur Datenbankverwaltung (immerhin inzwischen zwei Klicks näher), nochmals auf "Verwaltung" klicken, dann ist man endlich im phpMyAdmin. Und macht man dort ein paar Minuten nichts, beginnt dieses Prozedere mehr oder weniger von vorne.

Eigentlich wollte ich separate phpMyAdmins bei mir lokal hosten, um auf die jeweiligen Datenbanken zugreifen zu können, aber wie es scheint, kommt man nicht auf die Datenbank, wenn von außerhalb eines Strato-Servers zugreift (ich konnte auch keine Sicherheits-Einstellung finden, die das möglich macht). Sicherheitstechnisch ja eigentlich nicht übel.

Dann halt so: phpMyAdmin für jeden Strato-Account im jeweiligen Webspace installieren.

Bis vor kurzem ging ich noch davon aus, dass es nicht all zu einfach wäre, mit PHP ein PDF zu erstellen. Da lag ich falsch: Mit FPDF existiert schon seit 2001 eine Klasse, um PDFs zu erstellen.

So steht der PDF-Erstellung auf der Website – sei es zur automatischen Erstellung der Rechnung oder Personalisieren von Druckdaten – nichts mehr im Wege.

Im Folgenden ein paar Kniffe für FPDF.

FPDF ist eine PHP-Library, mit Hilfe derer man relativ einfach direkt aus PHP heraus PDFs erstellen kann und definitiv einen Blick wert.

Im Rahmen eines Projektes wollte ich den Benutzern einen Klick sparen und direkt beim Anzeigen des gerade erstellten PDFs den Druck-Dialog des Systems öffnen lassen.

Die Jungs von FPDF haben eine interessante Erweiterung, die das Einbinden von JavaScript in das PDF erlaubt und den Druckdialog dann per (ins PDF eingebettete) JavaScript aufruft.
Aber eigentlich bietet das PDF-Format auch nativ die Möglichkeit, das Anzeige-Programm zum direkten Ausdruck zu drängen.

Für eine Website wollte ich ein Autocomplete-Inputfeld á la jQuery UI, allerdings mit noch ein paar erweiterten Eigenschaften, an denen ich mir einige Zeit lang die Zähne ausgebissen hatte.

Bei Eingabe einiger Zeichen sollte per AJAX eine Abfrage an den Webserver gestartet werden, das JSON-Ergebnis (wie auch im jQuery-UI-Beispiel) als Aufklappmenü dargestellt werden. Die fertige Lösung war für mich schon deshalb nicht ausreichend, da mein JSON-Ergebnis noch weitere Werte, als einfach nur Name und ID zurücklieferte, welche ich bei Auswahl im UI dann in weitere Formular-Felder schreiben wollte.
Falls sich das keiner vorstellen kann: Rechts ein kleines Diagramm dazu.

Probleme hatte ich allerdings dadurch, dass...

...ich bei der AJAX-Abfrage noch die Werte einiger anderen Formular-Felder mitgeben muss (und mir anfangs immer die Standard-Werte mitgegeben wurde, die das Formular zu dem Zeitpunkt hatte, als ich mein Autocomplete-Plugin initialisiert hatte)
...die Autocomplete-Felder flexibel zur Laufzeit entfernt und hinzugefügt werden können

Wer sich dafür interessiert: Im Folgenden die Lösungsansätze.