Internen Cache bei Contao 4 abschalten?

[Bernd.P]

Hallo,

gibt es schon eine Möglichkeit den internen Cache in Contao 4.4 wie bei Contao 3.5 für die Entwicklung abzuschalten?

Gruß Bernd

[Spooky]

Ja, die app_dev.php benutzen. Oder den Ordner var/cache/prod/contao löschen und den Cache nicht neu aufwärmen lassen*.

* Hinweis: der Cache wird neu aufgewärmt wenn du a) eine composer Operation durchführst, b) im Contao Manager den Cache neu aufbauen lässt, c) das Install Tool aufrufst oder d) den Cache über die Konsole selbst neu aufwärmst

[Bernd.P]

Super... die Oder-Variante klappt, was versteckt sich hinter der app_dev.php? Im Forum finde ich nichts, bzw. habe zu viele Treffer. Hast du weitere Infos oder einen netten Link?

[planepix]

Hallo Bernd,

https://leofeyer.github.io/workshop-2015/#9

https://contao.ninja/contao-4-login-...hp-setzen.html

https://www.marcosimbuerger.ch/conta...-contao-4.html

https://community.contao.org/de/show...l=1#post443311

[Bernd.P]

Oha, da bleibe ich doch erst einmal bei der "Oder-Variante" und warte bis ich irgendwann das Häkchen setzen kann.

[Samson1964]

Ja, die app_dev.php benutzen. Oder den Ordner var/cache/prod/contao löschen und den Cache nicht neu aufwärmen lassen*.

* Hinweis: der Cache wird neu aufgewärmt wenn du a) eine composer Operation durchführst, b) im Contao Manager den Cache neu aufbauen lässt, c) das Install Tool aufrufst oder d) den Cache über die Konsole selbst neu aufwärmst

Und was ist wenn a, b, c und d nicht zutrifft und der Cache trotzdem wieder da ist? Ich lösche immer wieder alle paar Minuten cache/dev, obwohl ich z.B. mit app_dev in FE/BE arbeite.

[Spooky]

Hier geht es um den internen Cache von Contao, also var/cache/prod/contao

Die Ordner var/cache/prod bzw. var/cache/dev existieren immer spätestens wenn man auf die app.php oder app_dev.php zugreift.

[Fehrmann]

Mir geht es da tatsächlich wie Samson. Beim entwickeln unter Contao 4.4 und unter app_dev.php muss ich ständig den dev-Cache löschen. Wenn es hier noch etwas zusätzlich zubeachten gibt, wäre ich daran interessiert es zu erfahren.

[Spooky]

Warum genau musst du den ständig löschen? Musst du höchstens nur wenn du etwas an der config änderst

[Fehrmann]

Während der Entwicklung eines Bundles schaut man hin und wieder ob die gemachten Anpassungen im System auch die gewollten Auswirkungen haben. Das Laden des Backend/Frontend (je nachdem) per Strg+F5 bringt aber oft einfach keine Resultate. Erst nach dem Löschen des Caches sehe ich die Auswirkungen.

[Spooky]

Während der Entwicklung eines Bundles schaut man hin und wieder ob die gemachten Anpassungen im System auch die gewollten Auswirkungen haben. Das Laden des Backend/Frontend (je nachdem) per Strg+F5 bringt aber oft einfach keine Resultate. Erst nach dem Löschen des Caches sehe ich die Auswirkungen.

Über die Entwicklungsumgebung? Welche Änderungen?

[Samson1964]

var/cache/ ist leer. Sobald ich die Seite app_dev.php/contao einmal refreshe werden unter var/cache/dev sofort wieder ein Haufen Ordner und Dateien angelegt. Der Ordner var/cache/dev/contao/cache wird zwar auch angelegt, aber er ist leer.

Mehr Sorgen als dieser Cache bereitet mir aber assets/css. Hier verewigen sich hartnäckig css-, scss-, gz- und andere Dateien, die die Theme-Entwicklung oder das Gestalten einer Website erheblich beeinträchtigen. Ich habe mich schon mal dusslig gesucht, warum meine Entwicklerseite anders aussah als meine Vorlageseite. Bis ich bei der Vorlageseite mal assets/css löschte und endlich das richtige Layout zu sehen bekam. Vorher dachte ich immer, meine Entwicklerseite wäre falsch. Dabei war die Vorlage falsch.

[Spooky]

var/cache/ ist leer. Sobald ich die Seite app_dev.php/contao einmal refreshe werden unter var/cache/dev sofort wieder ein Haufen Ordner und Dateien angelegt.

Das ist normal.

Der Ordner var/cache/dev/contao/cache wird zwar auch angelegt, aber er ist leer.

Das soll auch so sein. In der Entwicklungsumgebung gibt es keinen internen Cache.

Mehr Sorgen als dieser Cache bereitet mir aber assets/css. Hier verewigen sich hartnäckig css-, scss-, gz- und andere Dateien, die die Theme-Entwicklung oder das Gestalten einer Website erheblich beeinträchtigen. Ich habe mich schon mal dusslig gesucht, warum meine Entwicklerseite anders aussah als meine Vorlageseite. Bis ich bei der Vorlageseite mal assets/css löschte und endlich das richtige Layout zu sehen bekam. Vorher dachte ich immer, meine Entwicklerseite wäre falsch. Dabei war die Vorlage falsch.

Bindest du direkt SCSS ein? Wenn ja würde ich dir raten das nicht zu machen, sondern immer bereits kompiliertes CSS einzubinden. Siehe dazu auch https://github.com/contao/core-bundle/pull/1010

[Samson1964]

Bindest du direkt SCSS ein? Wenn ja würde ich dir raten das nicht zu machen, sondern immer bereits kompiliertes CSS einzubinden. Siehe dazu auch https://github.com/contao/core-bundle/pull/1010

Ich verwende das ProTheme. Da ist kein (S)CSS in den Layouts eingetragen. Und auch in den Theme-Einstellungen (Spezialfunktion des Themeanbieters?) habe ich nichts zu (S)CSS gefunden. Wird wohl direkt über den Module-Ordner eingebunden ohne Einflußmöglichkeit im BE. Jedenfalls liefert das Theme eine Erweiterung mit, die SCSS parst.

[Spooky]

Jedenfalls liefert das Theme eine Erweiterung mit, die SCSS parst.

Dann liegt es wohl daran.

[Fehrmann]

Das mit CSS und auch bspw. bei neuen Klassen ist mir klar. Aber ich habe das Verhalten tatsächlich auch, wenn ich nur Änderungen in Templates vornehme.

[Spooky]

Das mit CSS und auch bspw. bei neuen Klassen ist mir klar. Aber ich habe das Verhalten tatsächlich auch, wenn ich nur Änderungen in Templates vornehme.

Contao Templates werden nicht gecached. Twig Templates schon - aber über app_dev.php nicht.

[Fehrmann]

Hmm, ok. Ich behalte das mal im Auge. Danke für deine Unterstützung.

[Fehrmann]

Ich konnte mein Problem nun beheben. Ich hatte in meinen Bash-Aliasen einen Befehl für das Löschen des Caches doppelt vorhanden und dem Angewendeten fehlte das '--no-warmup'.

[ph!L]

In die system/config/initconfig.php folgendes schreiben:

/**
 * Delete CSS files in assets/css/ which are older than the newest SCSS file in files/*
 *
 * @author Andreas Burg <http://andreasburg.de/>
 */
// purge contao cache
\Files::getInstance()->rrdir('var/cache/prod/contao', true);
\Files::getInstance()->rrdir('assets/css', true); 

Schon erzeugt er die scss Dateien mit jedem Load neu :-)

[webstar]

In die system/config/initconfig.php folgendes schreiben:

/**
 * Delete CSS files in assets/css/ which are older than the newest SCSS file in files/*
 *
 * @author Andreas Burg <http://andreasburg.de/>
 */
// purge contao cache
\Files::getInstance()->rrdir('var/cache/prod/contao', true);
\Files::getInstance()->rrdir('assets/css', true); 

Schon erzeugt er die scss Dateien mit jedem Load neu :-)

Aber nicht nur für css Dateien sondern alle gecachten Dca, config, symfony und erweiterungsspezifischen Dateien. Also nicht zu empfehlen.

[ph!L]

Aber nicht nur für css Dateien sondern alle gecachten Dca, config, symfony und erweiterungsspezifischen Dateien. Also nicht zu empfehlen.

Da hat Du sogar Recht. Aber was besseres haben wir nicht gefunden um CSS neu zu laden. Ohne geht es halt nicht und Contao 4 lässt uns damit ganz schön im Regen stehen.

Du darfst hier gerne korrigieren und ergänzen!

[Spooky]

Da hat Du sogar Recht. Aber was besseres haben wir nicht gefunden um CSS neu zu laden. Ohne geht es halt nicht und Contao 4 lässt uns damit ganz schön im Regen stehen.

Was genau möchtest du machen und warum?

[eS_IT]

Wenn man Änderungen an den Sprachdateien oder dem DCA macht, muss man vor jedem Reload den Cache leeren, auch wenn man über app_dev.php geht. Erst Gestern mit 4.4.16 ungefähr 53 Mal getestet. Das ist schon echt lässtig. Es wäre wirklich schön, wenn es hier eine Möglichkeit gäbe, dies während der Entwicklung zu umgehen. Wenn man ein neues Bundle erstellt, mag dies ja noch zu verkraften sein, da man ja ungefähr weiß, wo man hin will. Muss man sich aber Stück für Stück vorarbeiten z.B. weil man den Code anderer Debugen muss, ist es sehr sehr langwierig.

[Spooky]

Wenn du die app_dev.php benutzt musst du das nicht machen. Evt. bist du aber in folgendes Problem gestolpert: https://github.com/contao/core-bundle/issues/740 - Sprachvariablen kannst du in der Entwicklungsumgebung nicht mit PHP Dateien überschreiben, wenn diese in XLF Dateien definiert sind. Das geht nur mit einem aufgebauten, internen Contao Cache.

[webstar]

Wenn man Änderungen an den Sprachdateien oder dem DCA macht, muss man vor jedem Reload den Cache leeren, auch wenn man über app_dev.php geht. Erst Gestern mit 4.4.16 ungefähr 53 Mal getestet. Das ist schon echt lässtig. Es wäre wirklich schön, wenn es hier eine Möglichkeit gäbe, dies während der Entwicklung zu umgehen. Wenn man ein neues Bundle erstellt, mag dies ja noch zu verkraften sein, da man ja ungefähr weiß, wo man hin will. Muss man sich aber Stück für Stück vorarbeiten z.B. weil man den Code anderer Debugen muss, ist es sehr sehr langwierig.

Setzt du die Option --no-warmup beim Leeren des Caches? Meistens kann ich ohne das permanente Reload des Caches arbeiten.

[eS_IT]

Wenn du die app_dev.php benutzt musst du das nicht machen. Evt. bist du aber in folgendes Problem gestolpert: https://github.com/contao/core-bundle/issues/740 - Sprachvariablen kannst du in der Entwicklungsumgebung nicht mit PHP Dateien überschreiben, wenn diese in XLF Dateien definiert sind. Das geht nur mit einem aufgebauten, internen Contao Cache.

@Spooky: Es geht nur um die Sprachdateien von Erweiterungen, die als PHP-Arrays vorliegen.

Setzt du die Option --no-warmup beim Leeren des Caches? Meistens kann ich ohne das permanente Reload des Caches arbeiten.

@webstar: Danke für den Hinweis, ich werde es versuchen. Aber spätestens wenn man z.B. über das Installtool die DB aktualisiert, wird der Cache doch neu aufgebaut, wenn ich mich nicht irre. Ist also auch nur bedingt eine Lösung. Ein Abschalten während der Entwicklung wäre schon schön.

[Spooky]

@Spooky: Es geht nur um die Sprachdateien von Erweiterungen, die als PHP-Arrays vorliegen.

Dann kann ich dein Problem nicht nachvollziehen. Über die Entwicklungsumgebung wird nichts im Ordner var/cache/dev/contao erzeugt und jede Änderung an bspw. TL_DCA oder TL_LANG ist sofort sichtbar.

Aber spätestens wenn man z.B. über das Installtool die DB aktualisiert, wird der Cache doch neu aufgebaut, wenn ich mich nicht irre.

Nein, in der Entwicklungsumgebung nicht.

Ein Abschalten während der Entwicklung wäre schon schön.

Diese Möglichkeit hast du ja mit der Entwicklungsumgebung

[webstar]

@webstar: Danke für den Hinweis, ich werde es versuchen. Aber spätestens wenn man z.B. über das Installtool die DB aktualisiert, wird der Cache doch neu aufgebaut, wenn ich mich nicht irre. Ist also auch nur bedingt eine Lösung. Ein Abschalten während der Entwicklung wäre schon schön.

Das war mal der Fall. Wurde aber gefixt siehe https://github.com/contao/installation-bundle/issues/67

[Spooky]

Setzt du die Option --no-warmup beim Leeren des Caches? Meistens kann ich ohne das permanente Reload des Caches arbeiten.

Das ist nicht notwendig. Selbst wenn du

vendor/bin/contao-console cache:warmup --env=dev

ausführst, wird der interne Cache von Contao nicht für die Entwicklungsumgebung aufgebaut.

[danielm]

Also wie kann denn jetzt der ganz normale Wald-und-Wiesen Webdesigner wie ich den Cache am besten abschalten?
Kann doch nicht sein, dass man nach jeder Änderung im externen Less oder Css File im Backend die Daten bereinigen muss? Und das muss man tatsächlich, sonst ändert sich gar nix im Frontend - super anstrengend und nervig!

[Webbaumeister]

Also wie kann denn jetzt der ganz normale Wald-und-Wiesen Webdesigner wie ich den Cache am besten abschalten?

Die Option "Skripte komprimieren" in den Einstellungen könnte dein Problem lösen.

Tip von hier:

Nach dem Update auf 4.4.3 habe ich mich auch gewundert: Ohne die Einstellung im Seitenlayout "Skripte zusammenfassen" haben Änderungen an externen SCSS Dateien keine Auswirkungen mehr, wenn man die Webseite nur neu lädt. Erst, wenn man den Skript-Cache leert und die Webseite neu lädt, erscheinen die Änderungen.

Mit der Einstellung "Skripte zusammenfassen" werden die CSS Files korrekt aktualisiert und man muss nicht jedes Mal nach einer Änderung an einer SCSS Datei den Skriptcache leeren.

[Schnippel]

Hi

ich arbeite mit SASS-Dateien (also .scss), die in einer zentrale.css eingebunden werden.
Die zentrale.css wiederum wird als externes CSS im Contao-BE eingebunden.

Ab und zu habe ich das Problem, daß bei der Website-Erstellung Seiten im Debug-Modus ( app_dev.php ) über F5 nicht aktualisiert werden.
Wenn also im externen CSS / SCSS Änderungen vorgenommen werden reagiert die Aktualisierung F5 nicht. Erst nach einem Browsercache ist die Aktualisierung zu sehen.

Woran kann das liegen?

Änderungen im BE werden übernommen ohne den Browser zu cachen. Änderungen im externen CSS werden erst nach einem Browsercache übernommen.

Woran liegt das?
Wie löst man das Problem?

## LÖSUNG gefunden: ####
siehe hier

[heyho]

Auch in 4.9 ist es für mich noch mühsam in dca's und configs zu arbeiten..

Wie schon weiter oben beschrieben ist für mich die Lösung:

/system/config/initconfig.php erstellen und darin:

\Files::getInstance()->rrdir('var/cache/dev/contao', true);
//\Files::getInstance()->rrdir('assets/css', true); 

Bei BrowserCache Problemen einfach den Cache im Dev-Tools deaktivieren und das dev-Tool offen lassen.

[Spooky]

Auch in 4.9 ist es für mich noch mühsam in dca's und configs zu arbeiten..

In wie fern?

[heyho]

Im dev modus, egal ob mit cookie oder mit .env, muss ich bei jeder Anpassung im dca file oder der Sprache den cache im Manager löschen.

[Spooky]

Das sollte nicht passieren.