This page intentionally left blank

Seite: 1 2 3 >>

39 Artikel insgesamt

Absolutes Randgruppenthema und ein exotisches noch dazu, aber da ich mir für die Lösung eines Problemes stundenlang die Finger wundgegoogelt hatte, hier mal ein Treffer mehr für die Google-Suche.

Was war das Problem?

Ich habe ein Tabelle mit Bestellungen verschiedener Shops, wie etwa vereinfacht jene hier

id shop datum
1 1 2022-12-01
2 1 2022-12-01
3 1 2022-12-02
4 2 2022-12-02
5 2 2022-12-02

Nun will ich je Shop und je Tag (und auch je Woche, je Monat, je Jahr) wissen, wie viele Bestellungen für Shop 1 und Shop 2 jeweils eingegangen sind. Das ganze auch grafisch in einem Diagramm darstellen.

Man möchte meinen, mit einem COUNT() und GROUP BY sei dies ja ganz einfach. Allerdings bekomme ich kein Ergebnis für die Tage/Wochen/Monate/Jahre, wo es bei einem Shop keine Bestellung gab.

SELECT COUNT(id) AS anzahl, shop, datum
FROM bestellungen
WHERE datum >= '2022-12-01' AND datum <= '2022-12-02'
GROUP BY shop, datum

anzahl shop datum
3 1 2022-12-01
1 1 2022-12-02
2 2 2022-12-02

Ich vermisse das Ergebnis "Shop 2 am 1.12.2022 Anzahl: 0"

Ich habe ein paar Websites (wie z.B. auch in so gut wie allen Fällen den phpMyadmin) per .htaccess abgesichert, so dass man nur von bestimmten IP-Adressen aus darauf zugreifen kann.

Beispiel:

order deny,allow
deny from all
Allow from 198.141.12.11
Allow from 198.141.12.12

Das funktioniert für den Zugriff vom Firmennetzwerk aus recht gut, von zu Hause aus allerdings nur für einen Tag, da sich bei mir zu Hause die IP täglich ändert und ich somit immer erst die .htaccess-Datei ändern muss, um zugreifen zu können.

Deshalb habe ich mir ein Skript geschrieben, welches in sämtlichen .htaccess-Dateien meine IP-Adresse aktualisiert.

Man dürfte meinen, dass so gut wie jede Website heutzutage Google Analytics nutzt. Trotzdem habe ich nirgends eine vollständige Anleitung gefunden, wie man im Jahre 2022 Google Analytics zu einer Website hinzufügt. Denn einerseits sieht Google Analytics jedes Mal, wenn ich es benötige (was ehrlich gesagt sehr selten ist), anders aus und andererseits muss man in Europa ja auch noch viel mehr drumherumbasteln, um nicht irgendwann Post vom Anwalt zu bekommen.

Ich möchte in diesem Zuge darauf hinweisen, dass apfel-z kein Google Analytics verwendet. Mir ist es relativ wurscht, wie viele andere Leute mit welchem Browser von wo aus wie lange auf meinen Wissensspeicher zugreifen.

Achtung: Ich lege nicht meine Hand dafür ins Feuer, dass die ganze Sache auch wirklich 100% gesetzeskonform ist und einem nicht trotzdem jemand an den Karren fahren kann.
Ich sage immer wieder: Um heutzutage Websites zu erstellen, müsste man eigentlich nicht Programmierer/Designer, sondern Advokat sein.

Außerdem kann alles im Folgenden Beschriebenen zu dem Zeitpunkt, wo dieser Artikel gelesen wird, schon wieder anders aussehen und funktionieren. Google ist nicht gerade durch seine Konsistenz bekannt.

Von einem Ubuntu-Webserver aus muss ich in PHP-Skripten auf eine Oracle SQL Datenbank zugreifen können (die auf einem anderen Server läuft).

Obwohl es doch einige Hürden zu überwinden gab, war ich positiv überrascht, dass ich schnell ans Ziel kam.

Natürlich gibt es die common.css und die common.js, um eignen CSS- respektive JavaScript-Code in die Wiki zu integrieren.

Allerdings bekam ich mit wachsender Anzahl von Modifikationen und wachsender Anzahl von Wikis Probleme, die beiden common.*-Seiten aller Wikis zu pflegen.

Sei es ein Verbund von drei Wikis, die auf einem Server installiert sind, um die Infos verschiedener Unter-Unternehmen abzugrenzen oder ein Verbund von 10 Wikis, die auf einem anderen Server installiert sind, (Tendenz steigend), um verschiedene Kundengruppen mit verschiedenen Informationen zu versorgen.
Sollen alle Wikis gleich aussehen und dann mal eine Farbe geändert werden, ist man eine Weile beschäftigt.

Deshalb habe ich mir Gedanken gemacht, wie ich den Code, der bei allen Wikis gleich ist, in eine separate Datei auslagere, auf die alle Wikis zugreifen können.
Weiteres Benefit: Den Code in der Textdatei zu ändern ist für mich schneller erledigt, als erst in der Wiki zur common.*-Seite zu gelangen und dort den Text zu bearbeiten.

Neulich wurde ich gefragt, wie man alle Artikel eines mediawikis in ein PDF packen könnte.
Über Sinn und Zweck kann man streiten, da sich die Sache aber schnell als schwieriger herausstellte, als ich anfangs annahm, war mein Ehrgeiz geweckt.

Bei mediawiki.org sind zwar mehrere Extensions gelistet, die zum PDF-Export dienen, allerdings galt für alle: Entweder sie funktionieren mit der aktuellen Version 1.37 nicht oder die Installation ist derart komplex mit zig Abhängigkeiten und zu installierenden Serverkomponenten, dass ich darauf erst gar keine Lust hatte (wieso npm installieren, um ein PDF zu erstellen? Geht's noch?)...denn wer weiß, ob die Extension nach der umfangreichen Installation überhaupt funktioniert.

Am Ende hatte ich ein kleines PHP-Skript geschrieben, welches auf die mediawiki-API zurückgreift.
Einzige Abhängigkeiten: htmldoc auf dem Server installieren (dafür ist ein Kommandozeilenzugriff erforderlich) und einen Bot-Zugang in der Wiki erstellen.

Vielleicht bin ich zu dumm dazu, aber nun stehe ich schon das zweite Mal vor dem Problem, wie ich von extern die Daten von Shopify abzapfen kann, bzw bei einer Bestellung im Shop die Daten der Bestellung (Produkte, Kunde) an eine externe Datenbank weiterleiten kann.

Ich bin zwar mal über "Shopify Flow" gestolpert, aber dies gibt es wohl nur in Verbindung mit "Shopify Plus". Ansonsten müsste es irgendwie eine Möglichkeit mit Hilfe der "Apps" geben (heutzutage sind drei Zeilen Code ja eine Ähpp)

Mal schnell zusammengefasst, was Shopify alles an Schnittstellen bietet:

Öffentliche Apps (das, was man so in Shopifys "App Store" findet)
Benutzerdefinierte Apps (Da bin ich noch nicht so wirklich hinter Sinn, Zweck und HowTo gekommen)
Private Apps (damit kann man schön was für sich selbst basteln, darauf gehe ich noch ein)
App-Entwürfe (keine Ahnung. Gibt's halt...steht in der Doku)
Webhooks (was ich suche, aber in den Dokus schwer zu finden: Shopify sendet aktiv bei bestimmten Ereignissen Daten an ein externes Skript)

Über Payments-API, Partner-API, Messaging-API, Storefront-API, AJAX-API, Liquid & Co will ich gar nicht erst reden...

Im Folgenden will ich mal schauen, was man mit ner "Privaten App" (ich nenne lieber "Simplen API-Zugriff") und den Webhooks so anstellen kann.

Neulich musste ich per PHP mit der CleverReach API sprechen.

Der API-Explorer ist cool, aber die Doku hat bei mir für die einen oder anderen Anfangsschwierigkeiten gesorgt.

Den fertigen PHP REST Client, den man auf der Doku-Seite herunterladen kann, brachte ich nicht zum Funktionieren. Irgendwie bin ich immer zu blöd, irgendetwas Fertiges zu verwenden, wenn es nicht komplett dokumentiert wurde.

Naja, habe ich meine CleverReach-REST-PHP-Class halt selbst geschrieben...

Ich fühlte mich für den 30. September 2021 gut gewappnet. Alles getestet, mein Server kommt mit dem ab jenem Tag abgelaufenen DST Root CA X3-Zertifikat von Let's Encrypt zurecht und spielt das neue ISRG Root X1 aus.

Allerdings musste ich just an dem Tag feststellen: Ich kann mit curl bzw. dessen Pendant innerhalb von PHP nichts mehr herunterladen. Certificate error

Ich sage nur immer wieder: Scheiß Zertifikate!

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

Seite: 1 2 3 >>

39 Artikel insgesamt