Artikel

Seltsamer Locale-Bug bei Magento

2. Juli 2014

Die letzten Tage hatte ich mit einem sehr seltsamen Phänomen in einem frisch aufgesetzten Magento 1.9-Shop zu tun, der sich im Backend wie folgt zeigte:

  • unter System / Konfiguration / Allgemein war das Standardland nach jedem Login wieder verstellt auf Bitte wählen
  • ebenso dort war die Zeitzone immer nach einem Login auf den ersten Wert eingestellt (AUS Central Standard Time)
  • nochmal dort: Die Lokalisierung war genauso immer verstellt auf den ersten Wert (Afrikaans)
  • nach einem Login im Backend war die Sprache immer Englisch, auch wenn vorher auf Deutsch eingestellt wurde
  • das Login-Fenster war auch immer Englisch

Bis hierhin schonmal sehr merkwürdig, aber mit Aoe_BackendDefaultLanguage erstmal in den Griff zu bekommen. Die o.g. Locale-Einstellungen konnte ich per Store einstellen – und dort wurde es sogar gespeichert. Nur der Global-Scope wollte eben nicht. In der Datenbank war aber scheinbar alles okay – zumindest die üblichen locale-Werte in der core_config_data-Tabelle waren richtig gesetzt und auch lückenlos schreibfehlerfrei vorhanden.

Als dann noch jemand mit einem Firefox-Browser einen Artikel im Backend bearbeiten wollte, hagelte es den Fehler No region found within the locale 'de'. Also nochmal genauer nachschauen, und tatsächlich: Der Fehler lag in der Datenbank: In der core_config_data-Tabelle gab es einen Eintrag mit dem Path general (ja, ohne jeglichen weiteren Wert, einfach nur general) und dem Value NULL. Nur, daß es sowas eigentlich gar nicht in Magento gibt. Also weggelöscht, getestet und alles lief hervorragend. Da soll man mal drauf kommen!

Artikel

keep-alive aktivieren bei Domainfactory Managed-Servern

27. April 2014

Situation: Bei der Performance-Optimierung einer Website mahnt Google PageSpeed an, daß keep-alive nicht gesetzt ist; der Hoster ist Domainfactory und es handelt sich um einen Managed Server. Im Internet findet man einige Seiten zu dem Thema, meist mit der Aussage (die direkt von Domainfactory kommt), daß man es aktivieren könne, wenn man mit der Technik Rücksprache hielte.

Man kann diese Option jedoch auch leicht selbst pro Website aktivieren, und zwar per Eintrag in die .htaccess-Datei:

<IfModule mod_headers.c>
Header set Connection keep-alive
</IfModule>

Schon wandert PageSpeed über 10 Punkte nach oben.

Artikel

Mehrere Git-Repositorys bei Uberspace

24. April 2014

Uberspace ist ja ein toller Hoster. Aber manchmal wünscht man sich doch etwas mehr Konfigurationsmöglichkeiten, so wie man sie von (virtual) dedicated Servern kennt. So wollte ich letztens™ neben der normalen Website (unter /var/www/virtual/username/html) noch ein paar Subdomains haben, in denen ich andere Projekte hoste. Natürlich alle mit Git verwaltet. Eigentlich kein Problem, zumindest wenn man das .git-Verzeichnis zusammen mit den öffentlich sichtbaren Dateien speichert. Also so:

/var/www/virtual/username/html/.git
/var/www/virtual/username/html/index.html
/var/www/virtual/username/html/bild.gif

Nun ist das aber nicht eben gerade die feine englische Art, das .git-Verzeichnis dort mit reinzuwerfen, denn das hat in einem öffentlichen Ordner nichts verloren. Auch die Absicherung per .htaccess gegen Zugriff auf diese Datei macht nur begrenzt Freude.

Also einfach das Verzeichnis eine Ebene höher legen. Blöd nur, daß dieses Verzeichnis ja immer .git heißt und dann spätestens beim zweiten Git-verwalteten Projekt zum Problem wird:

/var/www/virtual/username/html
/var/www/virtual/username/.git (.git-Ordner aus dem Verzeichnis html)
/var/www/virtual/username/subdomain.domain.tld
/var/www/virtual/username/.git (.git-Ordner aus dem Verzeichnis subdomain.domain.tld)

Und schon ist die Lösung hinfällig, denn 2 .git-Ordner im selben Verzeichnis sind schwierig zu vereinbaren.

Also was tun? Lange Rede, kurzer Sinn: Die Verzeichnisse müssen umbenannt werden – aber so, daß Git etwas davon mitbekommt und hinterher sein Working Tree wiederfindet (und umgekehrt). Wie das gehen soll, hat mir Christopher vom Uberspace-Support teilweise gezeigt, und den Rest war dann auch schnell getan:

  1. Neues Verzeichnis auf dem Uberspace erstellen. Ich habe im Home-Directory (also unter /home/username) den Ordner repos erstellt.
  2. Die .git-Ordner nacheinander erst umbenennen und dann in das unter (1) erstellte Verzeichnis verschieben. Beispiel:
    /home/username/repos/projekt1.git
    /home/username/repos/projekt2.git
  3. In die eben kopierten Verzeichnisse wechseln und dort die config-Datei bearbeiten. Unter [core] muss eine neue Zeile eingefügt werden, welche den Pfad zum Working Tree angibt. Beispiel:
    worktree = /var/www/virtual/username/html
    Somit weiß Git schonmal, wo der Working Tree ist. Umgekehrt weiß der Working Tree aber noch nicht, wo das Git-Repository ist.
  4. In den Working Tree wechseln und eine Datei .git anlegen. Inhalt ist eine einzelne Zeile mit dem Pfad zum Git-Repository. Beispiel:
    /var/www/virtual/username/html/.git (Dateispeicherort)
    gitdir: /home/username/repos/projekt1.git (Dateiinhalt)
  5. Fertig!

Nun konnte ich in das Verzeichnis /home/username/repos/projekt1.git wechseln und von dort wie gewohnt alle Git-Befehle ausführen, z.B. zum Test ein git log --oneline.

Natürlich hätte ich den ersten Schritt (extra Verzeichnis für alle Repositorys) auch weglassen können und das Repository einfach nur umbenennen und eine Ebene höher schieben können. Aber so ein zentraler Ort ist mir lieber.