Wer liest mit im SVN?

@andreas.schempp: Andreas, ganz großes Kino! Dank Deines Vorschlags ließ sich die Funktion wie folgt zusammenfassen:

PHP-Code:

---

protected function getRootIdFromUrl()
{
    $host = $this->Environment->host;
    $accept_language = $this->Environment->httpAcceptLanguage;
    $time = time();

    // Find the matching root pages
    $objRootPage = $this->Database->prepare("SELECT id, dns, language, fallback FROM tl_page WHERE type='root' AND (dns=? OR dns=? OR dns='')" . ((count($accept_language) > 0) ? " AND (language IN('". implode("','", $accept_language) ."') OR fallback=1)" : "") . (!BE_USER_LOGGED_IN ? " AND (start='' OR start<$time) AND (stop='' OR stop>$time) AND published=1" : "") . " ORDER BY dns DESC" . ((count($accept_language) > 0) ? ", language='". implode("' DESC, language='", $accept_language) ."' DESC" : ""))
                                  ->limit(1)
                                  ->execute($host, 'www.'.$host);

    return $objRootPage->numRows ? $objRootPage->id : 0;
} 


---

Die komplette Logik kann so auf DB-Ebene abgearbeitet werden. Und außerdem haben wir endlich einen Workaround für FIND_IN_SET(). Wirklich sensationell! :)

Zitat:

---

Zitat von leo

Die komplette Logik kann so auf DB-Ebene abgearbeitet werden. Und außerdem haben wir endlich einen Workaround für FIND_IN_SET(). Wirklich sensationell! :)

---

Ist auf jeden Fall eine coole Lösung - auch wenn es zu einem Mega-SQL-Ausdruck ausartet (für Contao-Verhältnisse ;) ).

PS: Wer kommt eigentlich auf die Idee language=en DESC auszuprobieren? language DESC ist mir bekannt, aber nur zu sagen das ein Wert als erstes kommen soll und die Sortierung der restlichen Werte einem egal ist... muss man erst einmal wissen ;)

Ich glaube bei der changelanguage-Erweiterung wollte ich nach IDs IN () sortieren und deshalb ziemlich lange gegoogelt bis ich das gefunden habe...

Hallo,

in der r528 erhalte ich beim Speichern der "System-Einstellungen" folgende Warnung

Code:

---

Warning: html_entity_decode() expects parameter 1 to be string, array given in C:\xampp\htdocs\contao\system\drivers\DC_File.php on line 416

#0 [internal function]: __error(2, 'html_entity_dec...', 'C:\xampp\htdocs...', 416, Array)
#1 C:\xampp\htdocs\contao\system\drivers\DC_File.php(416): html_entity_decode(Array, 2, 'UTF-8')
#2 C:\xampp\htdocs\contao\system\modules\backend\DataContainer.php(290): DC_File->save('a:9:{i:0;s:2:"u...')
#3 C:\xampp\htdocs\contao\system\drivers\DC_File.php(268): DataContainer->row()
#4 C:\xampp\htdocs\contao\system\modules\backend\Backend.php(234): DC_File->edit()
#5 C:\xampp\htdocs\contao\contao\main.php(101): Backend->getBackendModule('settings')
#6 C:\xampp\htdocs\contao\contao\main.php(304): Main->run()
#7 {main}

---

sofern es sich um eine Neuinstallation handelt und daher in der "localconfig.php" die Variable mit den "Standardzugriffsrechten"

PHP-Code:

---

$GLOBALS['TL_CONFIG']['defaultChmod'] = 'a:9:{i:0;s:2:"u1";i:1;s:2:"u2";i:2;s:2:"u3";i:3;s:2:"u4";i:4;s:2:"u5";i:5;s:2:"u6";i:6;s:2:"g4";i:7;s:2:"g5";i:8;s:2:"g6";}'; 


---

noch nicht existiert.

Ist diese Variable in der lokalen Konfigurationsdatei vorhanden, wird diese Meldung nicht mehr angezeigt.

PS: Versteh' auch immer noch nicht ganz, wieso überhaupt der Wert dieser Variable in die "localconfig.php" geschrieben werden muss, wenn doch an den "Standardzugriffsrechten" in den "System-Einstellungen" keine Änderung stattgefunden hat.

Ich habe eben den "Version 2.9.1. candidate" committed (r529). Bitte noch mal testen, damit Ende der Woche das Release veröffentlicht werden kann.

Da kann ich mich nur anschließen.
Ich checke zwar 1-2 Mal die Woche aus, aber teste dabei nur meine eigenen Module daraufhin, da ich gerade selbst diese neu schreibe. (siehe #85)
Ein Gesamt Test bzw. ein Test der geänderten Funktionen die mich persönlich nicht betreffen, werde ich schon aus zeitlichen Gründen erst Samstag Abend durchführen können.

Ich bin bis Montag gar nicht da und kann daher auch nicht testen.
Im Ybrigen schliesse ich mich meinen Vorrednern an und halte 2 Tage ebenfallls fyr zu kurz.

Grysse
Chris

Wir können aber nicht für jedes Maintenance-Release, das gerade einmal ein paar Bugs behebt, eine Testphase von mehreren Wochen einrichten. Vor allem weil die Abstände zwischen den einzelnen Maintenance-Releases im Schnitt nur zwischen 4 und 6 Wochen liegen :)

Müssen wir uns eben ein anderes "Verfahren" überlegen. Am Releasetermin ändert das jedenfalls nichts (siehe Erklärung weiter oben).

Zitat:

---

Zitat von leo

Müssen wir uns eben ein anderes "Verfahren" überlegen. Am Releasetermin ändert das jedenfalls nichts (siehe Erklärung weiter oben).

---

Verwendest du selber Testcases? Das würde bei kurzen RC-Testphasen sicherlich für mehr Sicherheit sorgen.

Also für mich persönlich würde es schon reichen nicht Freitags die Veröffentlichungen zu tun, sondern Sonntag abend oder Montag früh. So können die Hobby Progger sich ein wenig Zeit nehmen zum Test am Wochenende.

Ausserdem wären dann die Agenturen auch verfügbar, wenn ein Kunde den Update-Knopf drückt und was passiert ;-)

Ich würde auch sagen, dass eine Ankündigung 5-7 Tage vor Release gemacht wird, dass man sich zumindest darauf einstellen kann (es müssen ja noch nicht alle, aber die wichtigen und meisten Änderungen committed worden sein). Generell sollte ein Release in der ersten Wochenhälfte erfolgen (Mo bis Mi), dass Agenturen bei Problemen schnell reagieren können; zudem ist am Wochenende vorher zusätzliche Zeit zum Testen. Zur besseren Planungsmöglichkeit sollte das Release zwei oder mehr Tage vor einem Wochenende angekündigt werden.

Somit ergibt sich als Mindestzeitraum 5 Tage (Do - Mo).
Wie gesagt, es müssen ja noch nicht wirkliche alle Änderungen zum Zeitpunkt der Ankündigung im Repo liegen, zum Wochenende sollte alles erledigt sein (mit Ausnahme von Korrekturen an Sprachdateien u. ä.).

Natürlich wird es Ausnahmen zu dieser Regel geben (müssen). Aber generell sollten mit dieser Regelung doch alle Interessengruppen zufrieden gestellt sein, oder?
Was meint ihr und vor allem du, Leo?

Zitat:

---

Zitat von leo

Ich habe eben den "Version 2.9.1. candidate" committed (r529). Bitte noch mal testen, damit Ende der Woche das Release veröffentlicht werden kann.

---

Also was meinen Beitrag #90 betrifft, kann ich sagen, dass durch die Änderungen in der "DC_File.php" (r529) das angesprochene Problem nicht mehr auftritt. :)

Nach Möglichkeit versuche ich auch einige der anderen Änderungen dieses Maintenance Release noch durchzutesten...

Zitat:

---

Zitat von leo.unglaub

Darunter zum Teil auch ein paar grawierende Dinge wie eine veränderung in der .htaccess Datei, ...

---

Welche ".htaccess"-Datei meinst Du? Die einzige diesbezügliche Änderung, die ich finden kann, betrifft mein Ticket #2337. Die dort durchgeführte Anpassung der Rewrite Condition würde ich aber jetzt nicht unbedingt als "gravierend" einstufen, zumal die betreffende Stelle in der Vorlage ".htaccess.default" ohnedies standardmäßig auskommentiert ist.

Weder gibt es "gravierende Änderungen", noch sind über 180 Dateien in 2 Tagen zu testen!

Die r529 von gestern enthält gerade mal 3 Änderungen, von denen zwei bereits in einem früheren Release enthalten waren und bei der Reintegration des 2.9-Branch in den Trunk offenbar nicht übernommen wurden. Für diese 3 unglaublich gravierenden Änderungen stehen in der Tat nur 2 Tage für den Test bereit. Alle anderen wurden sukzessive seit dem 7. Juli hinzugefügt und konnten schon in den letzten Wochen getestet werden.

Zudem lautet der Thread Wer liest mit im SVN und nicht Wer macht ausführliche Tests mit dem Trunk. Darüber hinaus war auch nie die Rede davon, Beta-Phasen für Maintenance-Releases einzuführen! Die Rahmenbedingungen für den Releasezyklus sind eigentlich klar und schon allein deswegen verstehe ich nicht, wieso hier trotzdem jedes Mal wieder gemeckert wird. Ich werde dann zukünftig keine Informationen mehr an dieser Stelle veröffentlichen, denn ich habe weder Zeit für noch Lust auf die immer gleiche und fruchtlose Diskussion.

Neben den hier aktiven Testern gibt es noch zwei Entwickler aus verschiedenen Agenturen, die im SVN mitlesen, und ich selbst bin auch nicht so dämlich, dass man mir permanent über die Schulter schauen müsste. Irgendwie ist ja dieses Contao entstanden, sogar ganz ohne dass es damals ein SVN gab. Ich glaube also fest daran, dass wir ein Maintenance-Release auch ohne mehrwöchige Testphase hinbekommen. (Und selbst wenn mal eine Kleinigkeit übersehen wird, ist diese dank Live Update ja schnell nachinstalliert.)

Wenn die Maintenance-Releases nur Bugfixe enthalten würde, würde ich Dir ja zustimmen. Dem ist aber nicht so.

Wenn Du keinen Wert auf Tests von möglichst vielen legst (gerade bei neuen Features, seien die Änderungen noch so klein), dann ebend nicht.

Auch dem Argument von Andreas kann man sich nicht verschließen, es geht hier ja auch im die Qualität und den guten Ruf von Contao.
Ich fände es auch sinnvoller Release Termin so zu legen, das mindestens ein regulärer Arbeitstag folgt, damit im Falle eines Falles "jemand da ist" dem Kunden zu helfen.

Das ist doch im Interesse aller hier denke ich.

Frage, wie kann ich die trunk version runterladen, zum Testen?
http://svn.contao.org/trunk/ Die dateien sind hier, aber wie kann ich die alle abspeichern?

Mir ist in der Rev528 noch etwas aufgefallen. Von meiner getRootIdFromUrl hast du den Teil mit " AND fallback=1" nicht übernommen. War das Absicht? Denn aus meiner Sicht müsste das unbedingt rein, damit Browser ohne Sprache korrekt funktionieren (auch wenn das wohl fast nie vorkommt).

Zitat:

---

Zitat von bruc13

Frage, wie kann ich die trunk version runterladen, zum Testen?
http://svn.contao.org/trunk/ Die dateien sind hier, aber wie kann ich die alle abspeichern?

---

Na mit SVN, was dachtest Du? ;)
Ungefähr so,mal als Kommandozeile:

Code:

---

svn co http://svn.contao.org/trunk contao-trunk

---

Legt ein Verzeichnis contao-trunk an und darin alle Dateien.
GUIs gibt es dafür natürlich auch.

Zitat:

---

Zitat von andreas.schempp

Mir ist in der Rev528 noch etwas aufgefallen. Von meiner getRootIdFromUrl hast du den Teil mit " AND fallback=1" nicht übernommen. War das Absicht? Denn aus meiner Sicht müsste das unbedingt rein, damit Browser ohne Sprache korrekt funktionieren (auch wenn das wohl fast nie vorkommt).

---

Hab ich korrigiert :)

Zitat:

---

Zitat von BugBuster

Ich fände es auch sinnvoller Release Termin so zu legen, das mindestens ein regulärer Arbeitstag folgt, damit im Falle eines Falles "jemand da ist" dem Kunden zu helfen.

---

Meinetwegen, dann peilen wir eben Anfang nächster Woche an. Offenbar gibt es keine Wochenendzuschläge mehr in der Branche :D

Hi Leo,

wäre es denn denkbar, noch die von mir angefragten Hooks einzubauen? Dann würde ich den Hook für Kommentare noch ergänzen und könnte dann ein die Erweiterungen auch veröffentlichen.

Jan

Zitat:

---

Zitat von leo

Darüber hinaus war auch nie die Rede davon, Beta-Phasen für Maintenance-Releases einzuführen! Die Rahmenbedingungen für den Releasezyklus sind eigentlich klar und schon allein deswegen verstehe ich nicht, wieso hier trotzdem jedes Mal wieder gemeckert wird. […] und ich selbst bin auch nicht so dämlich, dass man mir permanent über die Schulter schauen müsste.

---

Es redet ja auch niemand von Beta-Phasen für Maintenance-Releases (und es meckert auch niemand, es wird nur angemerkt, dass die Zeit etwas zu knapp wird, alles zu testen). Auch stellt keiner deine Kompetenz hier in Frage (im Gegenteil, wir sind ja alle hier, weil wir von deinem Produkt begeistert sind). Es geht Vielen mehr darum zu testen, ob es in ihren Umgebungen und bei ihren Erweiterungen Probleme mit den Änderungen gibt. Änderungen wie hier am Sprachen-Handling sind ja eine Seltenheit, und hier war für Querlesen und Testen ja genug Zeit.

Ich bin mit eigentlich jeder Regelung zufrieden, da ich eh immer ein paar Tage mit (unkritischen) Updates warte, um zu schauen ob bei anderen Probleme auftauchen ;) – die Änderungen im Repo lese ich regelmäßig so durch und teste ggf. Mein Vorschlag sollte nur dadurch, dass alle mit einer grundsätzlichen Regelung zufrieden wären, solche Diskussionen vermeiden.

Also mal rein aus Agentursicht: Ich bevorzuge auch Wochenanfänge für Releases. So kann ich vorher nochmal in den Trunk schauen bzw. nach dem Update vernünftig reagieren. Am WE habe ich frecherweise ja doch öfter mal Freizeit eingeplant :D

Zitat:

---

Zitat von leo

Meinetwegen, dann peilen wir eben Anfang nächster Woche an. Offenbar gibt es keine Wochenendzuschläge mehr in der Branche :D

---

Die gibt es schon lange nicht mehr, Leo - schon gar nicht für FreelancerInnen ...

Allerdings halte ich einen Release zu Wochenanfang ebenfalls für eine gute Idee. Dann kann man Sonntags (auch ohne Zuschlag) nochmal etwas genauer hinschauen, ohne den Alltagsstress zu haben.

Mit besten Grüßen,
Carolina (die übrigens nahezu täglich auscheckt).

Hallo Leo,

hab' grad gesehen, dass Du in der r530 auch das von mir im Ticket #2094 zusätzlich angemerkte Feature implementieren konntest. Werde ich gleich mal testen. Vielen Dank dafür!

Toll finde ich weiters, dass jetzt auch in der Standard-Vorlage der Serverkonfigurationsdatei ".htaccess.default" das Caching von statischen Ressourcen per Apache-Modul "mod_expires" entsprechend berücksichtigt wird.
Vielleicht könnte man in diesem Zusammenhang auch noch das Handling der ETags einbauen, sowie die Komprimierung zusätzlich per OutputFilter "DEFLATE" vorsehen (siehe dazu z.B. HIER); davon profitieren könnten dann u.a. auch Stylesheets und JavaScript-Dateien, welche von Erweiterungen eingebunden werden.

Beispiel-Konfiguration:

PHP-Code:

---

##
# Entity Tags Directive
##
<ifModule mod_headers.c>
  Header unset ETag
</ifModule>
FileETag None

##
# Set the Expires Header for various File Types
##
<IfModule mod_expires.c>

  # Turn on Expires and set default to 1 minute
  ExpiresActive On
  ExpiresDefault "access plus 1 minutes"
  
  ExpiresByType text/html "access plus 1 minutes"
  ExpiresByType text/plain "access plus 1 day"
  
  ExpiresByType text/css "access plus 5 weeks"
  ExpiresByType text/javascript "access plus 5 weeks"
  
  ExpiresByType image/png "access plus 5 weeks"
  ExpiresByType image/gif "access plus 5 weeks"
  ExpiresByType image/jpg "access plus 5 weeks"
  ExpiresByType image/jpeg "access plus 5 weeks"
  
  ExpiresByType image/x-icon "access plus 5 weeks"
  ExpiresByType image/vnd.microsoft.icon "access plus 5 weeks"

  ExpiresByType application/pdf "access plus 5 weeks"
  ExpiresByType application/javascript "access plus 5 weeks"
  ExpiresByType application/x-javascript "access plus 5 weeks"
  ExpiresByType application/x-shockwave-flash "access plus 5 weeks"
  ExpiresByType application/xml "access plus 1 day"
  
  <ifModule mod_headers.c>
    Header append Cache-Control "public"
  </IfModule>

  <FilesMatch "\.(css|js|gz)$">
    <ifModule mod_headers.c>
      Header set Vary "Accept-Encoding"
    </IfModule>
  </FilesMatch>

</IfModule>


##
# Compress Output Types by Filter "DEFLATE"
##
<IfModule mod_deflate.c>

  <FilesMatch "\.(html|htm|php|css|js)$">
    SetOutputFilter DEFLATE
  </FilesMatch>

  AddOutputFilterByType DEFLATE text/html text/plain text/xml text/php text/css text/javascript application/xml application/xhtml+xml application/x-javascript application/javascript application/rss+xml application/atom_xml
  
</IfModule> 


---

Um mit den neuen .css.gz konsequent umzugehen, müssten diese aber auch wieder gelöscht werden. Bisher wird in der system/modules/backend/StyleSheets.php, Zeile 120-127 die alten Dateien gelöscht, hier sollten auch die .css.gz entfernt werden.

Bin mal gespannt, wie sich das auf meinem FreeBSD-Problemkind macht. Kann das leider aber erst ab Montag testen da -> http://wacken.com/

Carolina.

Zitat:

---

Zitat von andreas.schempp

Um mit den neuen .css.gz konsequent umzugehen, müssten diese aber auch wieder gelöscht werden. Bisher wird in der system/modules/backend/StyleSheets.php, Zeile 120-127 die alten Dateien gelöscht, hier sollten auch die .css.gz entfernt werden.

---

Du hast vollkommen Recht. Werde ich noch ergänzen.

Zitat:

---

Zitat von leo

PHP-Code:

---

protected function httpAcceptLanguage() 
{ 
    preg_match_all('/([a-z]{2})[^,]*/', strtolower($_SERVER['HTTP_ACCEPT_LANGUAGE']), $matches); 
    return array_slice(array_unique($matches[1]), 0, 8); 
} 


---

Sieht auf jeden Fall gut aus. Aber nur weil der Code kompakter geschrieben ist, heißt es nicht, dass er auch effizienter läuft. Und nur darauf kommt es letztendlich an.

---

Ich kann mir nicht vorstellen warum ein preg_match_all weniger effizient als "explode, foreach, substr und preg_match" für jeden Eintrag sein soll...?
Deine Variante ermöglicht es, die q=... Bewertung zu berücksichtigen, aber das ist ja aktuell auch nicht der Fall.

Zitat:

---

Zitat von andreas.schempp

Ich kann mir nicht vorstellen warum ein preg_match_all weniger effizient als "explode, foreach, substr und preg_match" für jeden Eintrag sein soll...?

---

Das wollte ich damit auch gar nicht gesagt haben. Deine Lösung ist nicht besser oder schlechter, sie ist nur ein anderer Weg zum selben Ziel. Beide Ansätze sind ungefähr gleich, daher ist es egal, welchen wir nehmen.

Zitat:

---

Zitat von leo

Das wollte ich damit auch gar nicht gesagt haben. Deine Lösung ist nicht besser oder schlechter, sie ist nur ein anderer Weg zum selben Ziel. Beide Ansätze sind ungefähr gleich, daher ist es egal, welchen wir nehmen.

---

OK, dann sag ich es anders rum: Ich denke meine Variante ist (deutlich) effizienter :D:D
Klar... beweisen kann ich es nicht, und vermutlich wird niemand den ms-Unterschied merken.

Zitat:

---

Zitat von andreas.schempp

OK, dann sag ich es anders rum: Ich denke meine Variante ist (deutlich) effizienter :D:D

---

Och deutlich effizienter ist es nicht.

Bei 1 Mio Aufrufen ergebn sich folgende Zeiten:

PHP-Code:

---

alt: 19.859673976898s
Vorschlag: 14.841839075089s 


---

Sprich die preg_match_all-Version benötigt nur ~75% der Zeit.

Da ist der Unterschied zwischen array_key_exists('a', $a) und isset($a['']) doch deutlicher (isset ist um Faktor 7 schneller, auch wenn man es andersherum erwartet hätte ;) )

Zitat:

---

Zitat von SunBlack

Bei 1 Mio Aufrufen ergebn sich folgende Zeiten […] Sprich die preg_match_all-Version benötigt nur ~75% der Zeit.

---

Und da die Funktion ja nur ein einziges Mal aufgerufen und anschließend aus dem Cache geladen wird, ist es ziemlich egal. Meine Version hat außerdem den Vorteil, dass man theoretisch Gewichtungen einbauen könnte :)

Zitat:

---

Zitat von leo

Und da die Funktion ja nur ein einziges Mal aufgerufen und anschließend aus dem Cache geladen wird, ist es ziemlich egal.

---

Wo cachst du das? httpAcceptLanguage() selber cacht nicht - und die Funktion wird an mehreren Stellen aufgerufen (7-Code-Stellen). Wobei meistens 2-3 Aufrufe pro Seitenaufruf erfolgen. Aber selbst das dürfte von der Performance her egal sein ;)

Zitat:

---

Zitat von leo

Meine Version hat außerdem den Vorteil, dass man theoretisch Gewichtungen einbauen könnte :)

---

Ich hoffe das kommt irgendwann - inkl. Der Möglichkeit nach de-CH, de-DE etc. unterscheiden zu können ;)

@Leo: Besteht noch die Möglichkeit die Optimierung von Post #77 einzubauen?

Also statt:

PHP-Code:

---

$languages = $objEnvironment->httpAcceptLanguage;
krsort($languages);

foreach ($languages as $v)
{
    if (is_dir(TL_ROOT . '/system/modules/backend/languages/' . $v))
    {
        $GLOBALS['TL_LANGUAGE'] = $v;
    }

    unset($v);
}

if ($objInput->post('language'))
{
    $GLOBALS['TL_LANGUAGE'] = $objInput->post('language');
}

unset($languages); 


---

dies:

PHP-Code:

---

if ($objInput->post('language'))
{
    $GLOBALS['TL_LANGUAGE'] = $objInput->post('language');
}
else
{
    $languages = $objEnvironment->httpAcceptLanguage;

    foreach ($languages as $v)
    {
        if (is_dir(TL_ROOT . '/system/modules/backend/languages/' . $v))
        {
            $GLOBALS['TL_LANGUAGE'] = $v;
            break;
        }
    }

    unset($v);
    unset($languages);
} 


---

Wenn der Browser jetzt 8 Sprachen überliefert, prüft dein Algo immer auf 8 Ordner, anstatt von vorne nach hinten durchzugehen und maximal 8 Ordner zu überprüfen. Wenn die Sprache übergeben wird, fällt es bei der Verbesserung sogar komplett weg.

Nachdem ja in der r531 u.a. die nachfolgenden Stellen

Code:

---

  ##
  # Compressed .js and .css files
  #
  # Most of the JavaScript and CSS files used in Contao are also available
  # as compressed .gz version, which requires less bandwidth and optimizes the
  # page loading time. The following rules load these compressed ressources.
  ##
  AddEncoding gzip .gz
  <FilesMatch "\.js\.gz$">
    AddType "text/javascript" .gz
  </FilesMatch>
  <FilesMatch "\.css\.gz$">
    AddType "text/css" .gz
  </FilesMatch>
  RewriteCond %{HTTP:Accept-encoding} gzip
  RewriteCond %{REQUEST_FILENAME} \.(js|css)$
  RewriteCond %{REQUEST_FILENAME}.gz -f
  RewriteRule ^(.*)$ $1.gz [QSA,L]

---

aus der Vorlage der Serverkonfigurationsdatei ".htaccess.default" (r531) entfernt wurden, werden nunmehr JavaScript-Dateien mit dem neuen (korrekten?) MIME-Typ "application/javascript" ausgeliefert.

Damit aber für JavaScript-Dateien, welche mit diesem Inhaltstyp ausgeliefert werden, auch der ExpiresHeader korrekt gesetzt wird, müssten die Direktiven in der ".htaccess.default" (r530) mit diesem Inhaltstyp entsprechend ergänzt werden:

Zitat:

---

##
# Specify an expiration one week in the future for images, JavaScripts and
# CSS files (as recommended by Google Page Speed). Edit or remove the lines
# to set up your own expiration logic.
##
ExpiresByType image/png A604800
ExpiresByType image/gif A604800
ExpiresByType image/jpg A604800
ExpiresByType image/jpeg A604800
ExpiresByType text/javascript A604800
ExpiresByType application/javascript A604800
ExpiresByType application/x-javascript A604800
ExpiresByType text/css A604800

---

In diesem Zusammenhang taucht auch erneut die Frage auf (siehe dazu auch Ticket #1013), mit welchem Inhaltstyp man JavaScript-Code am besten ausliefern kann/soll. Zur Zeit werden beispielsweise Inline-Scripte (die per MooTools-Template eingebunden werden) mit dem MIME-Type "text/javascript" versehen; externe JavaScript-Dateien werden vom Webserver hingegen als "application/javascript" ausgeliefert.

Wenn man sich allerdings die offiziellen Registrierungsstellen ansieht, dann wird dort der MIME-Typ "text/javascript" mittlerweile als "obsolet" eingestuft:

• IANA.org bzw.
• RFC4329

An und für sich könnte man ja jetzt alle JavaScripte als "application/javascript" ausliefern, allerdings scheinen damit (wie so oft) die Browser aus der M$-Familie nicht immer ganz klar zu kommen, wie etliche Quellen im Internet (z.B. hier) erahnen lassen...

Hat irgendjemand schon die Änderungen seit der 2.9.2 und insbesondere die r587 getestet? Ich würde die 2.9.3 nämlich wegen der Sicherheits-Schwachstelle gerne zeitnah veröffentlichen.

Ich schau's mir gerade an...

Ich habe mir das ausführlich angesehen und im Internet recherchiert, das müsste so funktionieren. Du validierst nach einer IPv4 oder IPv6 Adresse, etwas anderes darf in diesem Feld nicht stehen. Theoretisch wäre das empty() nicht nötig, aber vermutlich resourcenschonender denn dann wird nur in seltenen Fällen das Regex angewandt.

Ich wäre allerdings froh wenn du folgendes Ticket noch einschliessen könntest?
http://dev.contao.org/issues/2752