Slow Movie Player: PHP controlled

Um meinen Slow Movie Player via PHP zu “steuern” (aka den Service ein- und auszuschalten erst mal nur), bedurfte es eigentlich nur einer Änderung: Ich musste dem entsprechenden User (hier: www-data) das Recht geben, den Service per systemctl zu starten und zu stoppen: $ sudo visudo, dann

Achtung: Die Zeile muss an das Ende der Datei!

Dann ist das ziemlich einfach:

Achtung: systemctl ist hier in /usr/bin, nicht in /bin!

Zwischendurch habe ich zum Debuggen

  • den User www-data zu sudo hinzugefügt: sudo usermod -aG sudo www-data (und dann aber wieder entfernt: sudo gpasswd --delete www-data sudo)
  • dem User www-data eine Shell (und ein Home-Verzeichnis und ein Passwort) zugewiesen, damit er sich einloggen kann (und dann wieder entfernt)

PS, zum Einsatz kommt PHP 8.2, mittels Umweg über sury.org.

MicroPython vs. HTTP Response Headers

Der Raspberry Pi Pico W ist pure Magie. Ein Microcontroller, in Python zu steuern, mit WLAN on board 😍 Super einfach, damit irgendwas im Netz zu machen – essentiell für IoT, looking at you, Arduino.

(Aber man muss|Außerdem kann man) viel über MicroPython lernen. Zum Beispiel, wie urequests Response-Header parst: Als Key/Value. Das ist uncool, da es durchaus Header gibt, die doppelt kommen können und sollen:

The optional replace parameter indicates whether the header should replace a previous similar header, or add a second header of the same type. By default it will replace, but if you pass in false as the second argument you can force multiple headers of the same type. For example:

Sagt PHP (replace Parameter).

The Set-Cookie HTTP response header is used to send a cookie from the server to the user agent, so that the user agent can send it back to the server later. To send multiple cookies, multiple Set-Cookie headers should be sent in the same response.

Sagt Mozilla.

Imho nicht unbedingt unseriöse Quellen, aber für MicroPython ist das trotzdem kein schlagendes Argument; Header duplicates werden weiterhin nicht unterstützt werden. Siehe meine längliche Diskussion ab hier.

Es gibt aber einen Workaround, und der ist imho nicht offensichtlich: Man kann nämlich urequests.post() mit einem Parameter parse_headers aufrufen, der erstmal ein Boolean ist – aber auch eine Callback-Funktion sein kann:

Das Fragment (ich hoffe, ich habe auf die Schnelle nichts vergessen) printed alle Cookies. HTH.

Composer: Von git importieren

Am Beispiel von serbanghita/Mobile-Detect:

Im Code dann:

Learnings hier:

  • Repo-Type ist “vcs” (“git” ist veraltet)
  • Als Repository-URL genügt die oben genannte – Groß-/Kleinschreibung ist egal, .git nicht nötig
  • Der “require”-Name ergibt sich nicht von selbst – insbesondere ist es nicht das “serbanghita/Mobile-Detect” aus der Repo-URL! Um an den korrekten Namen zu kommen, guckt man entweder in die composer.json auf Git (sofern vorhanden), oder man ruft composer update -v auf (“-v” für “verbose”)
  • Ist kein Namespace definiert, darf der Slash vor “Mobile_Detect” trotzdem nicht fehlen

Symfony: Übersetzungen nachträglich setzen

Mehrsprachigkeit läuft in Symfony intern so ab, dass alle Texte separiert nach Sprache (bzw. pro “Locale”, dieselbe Sprache kann in mehreren Ländern gesprochen werden) von einer Translator-Klasse “geladen” werden. “Geladen” heißt: Diese Texte können auch aus einem Array kommen, das muss keine Datei sein.

Und man kann die Texte auch nachträglich laden: Dazu gibt es die Funktion addResource, der man die Art der Daten (Array, CSV, …), die Daten an sich, die Locale und die Domain übergibt:

Nun ist es aber so, dass addResource erst mal nur die Daten “bekannt” macht, indem es sie intern in ein “resources”-Array schreibt. Die Daten werden nicht fixiert, und insbesondere nicht in den Symfony-Cache geschrieben. Man kann das allerdings erzwingen, indem man eine (nicht zwingend existente) Übersetzung für diese (neue!) Locale anfragt:

Die letzte Zeile ist wichtig, sonst passiert es unter bestimmten Umständen, dass man mit “leeren” Übersetzungen dasteht!

Für die Akten, diese Umstände sind folgende:

Meine Anwendung unterstützt de_COM und en_COM. en_COM ist default_locale und Fallback für de_COM. Beide Sprachen werden initial (d.h., wenn sie lokal noch nicht vorliegen) von extern geholt. Der Fehler tritt nun auf, wenn ich erst de_COM aufrufe. Dann wird en_COM als Fallback in die catalogue.de_COM.php geschrieben – aber als leeres Array, denn en_COM liegt lokal noch nicht vor. Rufe ich jetzt (erst) en_COM auf, wird die catalogue.en_COM.php nicht auf Basis der externen Daten geschrieben, sondern auf Basis des leeres Arrays aus catalogue.de_COM.php. Dabei liegen die Daten für en_COM durchaus vor, sie werden/wurden nur nicht in eine lokale Datei geschrieben, und deshalb beim Schreiben der catalogue.de_COM.php nicht berücksichtigt. Die o.g. Zeile erzwingt das Schreiben der Datei und alles ist tutti.

So: Das war das erste Problem 🙂 Das zweite ist, dass ein mal gecachte “Catalogue”-Dateien nicht aktualisiert werden, wenn sich die Quelle dazu ändert. Die Doku sagt, man muss den Cache dann leeren. Falls das nicht gewünscht wird (etwa, weil man im Zuge eines automatisierten Preview-Prozesses dynamisch Änderungen veröffentlichen können muss), bleibt einem nur das Deaktivieren des Translation-Caches.

Dazu bietet Symfony\Bundle\FrameworkBundle\Translation\Translator die Option “cache_dir”. Auf null gesetzt ist der Cache deaktiviert. Leider kann man diese Option nicht von außen setzen m( Aber man kann seine eigene Translator-Klasse als default definieren, und dort die Option setzen – im Folgenden direkt konfigurierbar implementiert:

config.yml:

Acme\ProjectBundle\DependencyInjection:

Acme\ProjectBundle\Translation\AcmeTranslator:

HTH

Symfony: “ResourceNotFoundException” mit custom error page

Folgendes Phänomen:

Wenn ich einen internen Fehler in einem Bundle provoziere (bsplw. durch Referenzieren eines nicht existenten Partials in einem Template), wird mir mein Error Template angezeigt.

Wenn ich allerdings eine nicht existente Route öffne (bsplw. http://example.com/does/not/exist), bekomme ich eine ResourceNotFoundException und eine NotFoundHttpException. Die NotFoundHttpException kann man ignorieren, so lange die ResourceNotFoundException noch da ist – das Internet schickt einen hier gerne auf den falschen Pfad und verweist auf Routingprobleme. Die ResourceNotFoundException tritt aber im Twig auf, wenn ein Template nicht gefunden wird. Dann stürzt alles ab, und die NotFoundHttpException kann nicht abschliessend behandelt werden.

Zum Debuggen kann man sich Symfony\Bundle\TwigBundle\Controller\ExceptionController.findTemplate() ansehen. Wenn das Template dort korrekt gefunden wird, sollte man sich dieses Template ansehen, wenn es von einem anderen Template erbt, muss auch dieses auffindbar sein.

Generell würde ich für custom error pages von der Beerbung von Bundle-Templates abraten.

Composer vs. CamelCase

Composer legt Bundles in lowercase benannten Ordnern ab:

Namespaces möchte man aber in CamelCase (hier: “Acme”) haben:

Was man jetzt wissen muss: Trägt man das Bundle in einen PSR-0-Autoloader ein, dann geht das nicht:

, da PSR-0 die Datei unter einem Dateipfad sucht, der dem Namespace entspricht (deploy/vendor/server/Acme/LocaleBundle), “Acme” aber zu “acme” wird. Unter OS X kein Problem, wenn das Dateisystem caseinsensitive ist (scheint der default zu sein? Kann mich da irren), auf einem Server aber schwierig 🙂 Lösung:

1. Lowercase namespaces

Will man nicht.

2. Unterverzeichnisse nutzen

mit

in der composer.json. Kann man machen, bläht aber die Verzeichnis- (und damit die Projekt-) Struktur unnötig auf.

3. Einen eigenen Autoloader schreiben

🙂

4. PSR-4

Kurz vor Redaktionsschluss noch reingekommen: PSR-4 mit

Vorteil von PSR-4, wenn ich’s richtig verstanden habe: Die Dateien können irgendwo liegen; der Namespace wird unabhängig vom Verzeichnisbaum nur durch die Angaben im PHP-Code vorgegeben. Empfehlenswert ist aus Übersichtsgründen eine Struktur, die sich trotzdem am Namespace orientiert, aber man muss zumindest auf den Case keine Rücksicht mehr nehmen.

PHP auf der Kommandozeile

PHP auf eine andere Version (bsplw. die des MAMP) umbiegen (in der .bash_profile):

Wo liegt die php.ini?

Wo liegt das Verzeichnis für Erweiterungen?

Alle geladenen Module:

Ist ImageMagick verfügbar?

To be completed!

Composer: Erste Learnings

Ich versuche gerade, ein Composer-Package zu definieren und aus dem SVN zu installieren, bekomme aber immer die Meldung

Your requirements could not be resolved to an installable set of packages

Es wird nicht ganz klar, ob das an der packages.json im SVN liegt, an der lokalen composer.json, oder irgendwo dazwischen (zB an der Verbindung zum SVN). Leider liefert composer install auch im verbose Modus keine hilfreiche Informationen, aber

hilft. Es zeigt Informationen (zB die description) aus der packages.json (also scheint die Verbindung zum SVN zu klappen), als Version aber nur “dev-trunk”. Offenbar zählt die in der externen composer.json angegebene Version nicht, sondern allein die Tatsache, dass das Package im trunk liegt. Folgendes funktioniert schließlich:

externe composer.json:

lokale composer.json:

Wichtig dabei: “url” enthält nicht “trunk”, und alles hinter “trunk” wandert aus der URL nach “package-path”. So kann man mehrere Packages in einem SVN-Projekt ablegen.

Update “Versionierung”

Eine packages.json wird im externen Package ebensowenig benötigt, wie eine Versionsnummer in der externen composer.json! Die Versionsinformationen ergeben sich implizit aus Tag-/Branchnamen (oder halt “dev-trunk”), was ja auch Sinn macht, denn natürlich enthält das Repository alle Versionen.

Eine ganz bestimmte Revision kann man wohl mit

angeben (Quelle)

Update “SVN”

Mit dem oben beschriebenen Vorgehen muss man für jedes “require” Package ein eigenes Repository definieren. Das ist übrigens unabhängig davon, ob alle Packages in einem SVN-Projekt liegen, oder jedes Package sein eigenes Projekt hat – so lange man nicht jedem Package sein eigenes SVN-Repository geben möchte, kommt man da nicht drumrum. IMHO eine Designschwäche; Composer ist halt sehr auf git fixiert.

Anyway: Eine Möglichkeit, die “repositories” in der lokalen composer.json zu begrenzen, wäre der Einsatz von Satis:

[Satis] can be used to host the metadata of your company’s private packages, or your own.
[…]
You don’t need to copy all your repositories in every project anymore. Only that one unique repository that will update itself.

*Notwendig* ist das nicht, aber es macht die Sache übersichtlicher.

Update “SVN”/2.

Ohne Satis sind “verschachtelte” Abhängigkeiten nicht möglich (siehe), die unschöne “Lösung”: Alle Abhängigkeiten im Root-Projekt definieren (Quelle) 🙁

PS: Composer – und folglich auch Satis – laufen auf uberspace 🙂

Symfony: Multiple Twig Extensions

Bei der Verwendung von mehreren Twig Extensions mit jeweils eigenen Funktionen bekommt man schnell eine Fehlermeldung à la

The function “my_function” does not exist in mytemplate.html.twig at line 42

Meine erste Idee war, dass das an der Art der Registrierung in den Extensions liegt:

– vielleicht überschreibt ja jeder Aufruf von getFunctions() das vorherige Array? Mein Ansatz: Statt der Rückgabe eines Arrays in getFunctions() lieber jede Funktionen (hier: im Konstruktor der Extension) separat adden:

Leider lag es gar nicht daran. Stattdessen hatte ich einfach in der zweiten, neuen Extension nach dem Copy&Paste vergessen, den Namen zu korrigieren:

Der fungiert offenbar als eine Art Namespace, in dem sie die Arrays vermutlich tatsächlich überschrieben haben 🙂 Anyway: Die alternative Methode der Definition von Funktionen mag noch mal hilfreich sein.