Was habe ich mir über die API der mediawiki schon den Kopf zerbrochen und geflucht...

Im aktuellen Fall will ich einige Artikel meines Wikis in einem anderen System anzeigen, ohne dass jeder Benutzer des anderen Systems einen Wiki-Zugang benötigt. (Und natürlich soll die Wiki auch nicht öffentlich sein)
So lassen sich prima in der Wiki Arbeitsanweisungen pflegen, die dann im Arbeitssystem der Benutzer angezeigt werden können.

Bis ich aber mal dahinter kam, wie ich das, was auf https://www.mediawiki.org/wiki/API:Parsing_wikitext steht, letztendlich produktiv nutzen kann...

"Befüllt die Datenbank erst mit Einträgen, wenn ihr euch sicher seid, dass ihr alles genau so haben und nichts mehr ändern wollt" hatte ich gesagt. Aber ne...wir wollen jetzt sofort dutzende Einträge reinhauen und nachher zum Entschluss kommen, dass die beim speichern vergebenen Ticketnummern doch irgendwie blöd sind.

Wie nummeriere ich alle vorhandenen Einträge nochmals neu durch, ohne auf die ID oder ähnliches zurückzugreifen?
Die Leute wollen in einem Feld eine Ticketnummer haben, die mit "R_2024_" anfängt und dann eine fortlaufende Zahl hintendran hat. 3stellig mit führenden Nullen.

Das geht mit folgendem SQL-Befehl (die erste Zahl ist hierbei eine 1):

Ich hatte für einen Verein ein Mediawiki aufgesetzt und ein Verwaltungstool für diverse Tätigkeiten erstellt.
Da es den meisten Mitgliedern schon schwer fällt, sich Passwort und URL des Verwaltungstools zu merken, wollte ich von dort aus zur Wiki verlinken und den Benutzer auch gleich einloggen, denn ohne Login kann man in jener Wiki keine Artikel lesen.

Das Ganze ist gar nicht so einfach, obwohl es eine API für Logins gibt. Jene ist allerdings mit solchen Fallstricken verbunden, dass man sie an sich gar nicht verwenden kann.
Jedenfalls fand ich nirgends ein funktionierendes Praxis-Beispiel hierfür.

Im Folgenden mein Workaround, um von Seite A mit einem Klick auf Button/Link XY zur Wiki zu gelangen und dort automatisch eingeloggt zu werden.

PH-803W ist wohl ein Wasserqualitäts-Sensor, den ein Freund von mir in Verwendung hat und in seine IP Symcon-Heimautomation einbinden möchte.

Allerdings hat der Sensor keine offene API, sondern sendet seine Werte an eine Handyapp.
Für den IOBroker hatte jemand eine Lösung auf GitHub veröffentlicht und hier fand' ich noch ein python-Skript, um an die Werte zu kommen.

Allerdings wäre für IP Symcon ein PHP-Skript notwendig, also musste ich ran.
Zum Glück hatte der Entwickler der IOBroker-Lösung auch noch eine gute Dokumentation beigelegt, welche HEX-Werte zu senden sind und wie die Antworten zu interpretieren sind, so dass die Sache kein großes Problem war.

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:

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.

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

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.

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

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.