git: svn:externals-Äquivalent

Vorab: Ich bin git-Anfänger.

Wenn man nach einem git-Äquivalent zu svn:externals sucht, liest man von zwei Optionen:

  • Subtree merges: “very easy on other users, because it is automatically included when the repository is checked out or cloned”
  • Submodules: “all users have to manage the submodules, which are not automatically included in checkouts”

Die Zitate sind aus dem verlinkten Beitrag, aber die Tendenz “Submodules will man nicht” liest man auch an anderer Stelle [1, 2]. Meiner Meinung nach ist es genau andersrum:

Bei Subtree merges werden die externen Sourcen in das aktuelle Projekt gelegt – und nicht nur verlinkt! Das heißt, man pusht die (vermeintlich) externen Sourcen in das aktuelle Projekt. Ja, dadurch klont sie ab dem Moment auch jeder automatisch (vgl. Zitat oben), trotzdem entspricht das nicht dem Sinn und Zweck.

Darüber hinaus hatte ich zeitweise das Problem, dass Dateien aus dem externen Projekt gleich benamte lokale Dateien überschreiben wollten (bei README.md, composer.json, .gitignore, make, … durchaus ein Problem!). Das mag aber ein Anwenderfehler gewesen sein; nachdem mir Problem #1 klar wurde, habe ich Subtree merges nicht weiter verfolgt.

Submodules erfordern zwei zusätzliche Schritte beim Klonen (git submodule init, git submodule update), sowie einen beim Update, wenn sich das Submodule ebenfalls geändert hat (git submodule update). Dafür sind die externen Sourcen nun “nur” verlinkt, also wie bei SVN Externals. Dumm: Wenn sich das externe Projekt ändert, muss man den “Link” auf den entsprechenden neuen Hash zeigen lassen, und das auch commiten. Passt jemand nicht auf und commitet nun wieder den alten Link, revertet er dadurch die Änderung.

Das spricht aber nicht gegen Submodules als Externals-Ersatz – es spricht höchstens gegen git, wo alles “ein wenig” komplizierter ist, als es sein sollte :-/ PS dazu: Ich habe mein Glück die meiste Zeit auf der Kommandozeile versucht, erst später zeigte Tobi mir Sourcetree. Damit sollte das leichter sein.

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.