Neu custom.css Versionierung / Cache Problem?

[weisser-dev]

Hallo zusammen,

ich helfe aktuell einem Freund beim konfigurieren seines Shops. Hierzu haben wir einige CSS Änderungen gemacht. Jetzt ist uns gestern aufgefallen, immer wenn die Custom.css angepasst wird, wird hier eine neue Version dieser gespeichert, also bspw. ruft der Browser dann NOVAChild/themes/my-nova/custom.css?v=5.2.1 auf. Wenn ich nun die Custom.css wieder ändere, ruft er weiterhin die custom.css?v=5.2.1 auf, diese hat allerdings nicht die neusten Änderungen. Diese sind (warum auch immer) in der 5.2.2 und das passiert auch wenn ich meinen Browser Cache lösche. Was nun hilft ist in der templates.xml die Version auf 5.2.2 zu setzen, dann wird auch die richtige css-Datei angezogen. Nach einigerzeit (nächster Tag bspw.) ist allerdings auch die 5.2.1 auf dem Stand, den ich gerne hätte. Jetzt habe ich an verschiedenen Stellen im Shop selbst geschaut und wo es möglich war den Cache auf 1 Sekunde geändert. Leider ändert das nichts am Verhalten. Daher wäre meine Frage gibt es für "Templates" bspw. eine Art "Entwicklungsmodus" das in der Zeit Caching / Versionierung von JS / CSS Dateien komplett deaktiviert wird?

PS. ein ähnliches Thema wurde offenbar 2019 hier im Forum schonmal besprochen, wollte aber keine alten Beiträge neu eröffnen und auch kam es da zu keiner Lösung die mir aktiv weiterhilft. Da hier immer nur auf die .htaccess verwiesen wurde. Aber die falsche css-Datei wird immer ausgespielt

 

[mh1]

Ich kenne den JTL Shop nicht, aber nahezu jede Web App hat ja einen Template Cache.
Hast du also mal im Backend des Shops geschau, ob du dort einen Template Cache löschen kannst?

 

[css-umsetzung]

Wenn Ihr wesentliche Änderungen an der custom.css vornehmt, dann ist es am besten die Template Version hochzusetzen.

 

[weisser-dev]

Ich kenne den JTL Shop nicht, aber nahezu jede Web App hat ja einen Template Cache.
Hast du also mal im Backend des Shops geschau, ob du dort einen Template Cache löschen kannst?

Genau, es gibt die Option "Template Cache löschen" da hätte ich auch erwartet, dass diese wie gewünscht greift. Leider Fehlanzeige... also kleines Beispiel hierfür:

custom.css V5.2.0 ->

a.nav-link {
  color:var(--black);
}

Nun gefällt mir die Farbe und ich möchte beim nav-link bspw. noch ein margin haben, also verbinde ich mich via ftp, ändere die custom.css erneut:

a.nav-link {
  color:var(--black);
  margin-top: 10px;
}

jetzt zieht der shop weiterhin die custom.css über die Template-Version an also bspw. ruft er dann folgenden Link (/templates/NOVAChild/themes/my-nova/custom.css?v=5.2.0) auf:
und hierbei ist es egal ob ich den Browser oder den Template-Cache lösche. mit v=5.2.0 lädt er immer die alte custom.css die so via FTP gar nicht mehr erreichbar ist. Und auch nirgends existiert. Selbst im Inkognito Modus lädt er dieses File wieder vom Shop (nicht vom Disk-Cache).

Wenn ich nun bspw. direkt die CSS Datei aufrufe und dort händisch mit den Versionen rumspiele also mal im Browser /templates/NOVAChild/themes/my-nova/custom.css?v=5.2.1 eingebe passt es. Heißt im Backend wird irgendwo etwas versioniert und hochgezählt. Und nach X Stunden wird die alte 5.2.0 durch die neue 5.2.1 ersetzt, also 5.2.0 hat nun den erwarteten Stand.

Jetzt ist mir allerdings nicht bekannt, wann passiert das genau? Wo ist die Einstellung dafür (alles Cacheseitige habe ich schon auf 1 gesetzt). Auch funktioniert "Template Cache" löschen nicht. Sondern man muss wirklich wie hier erwähnt:

Wenn Ihr wesentliche Änderungen an der custom.css vornehmt, dann ist es am besten die Template Version hochzusetzen.

Die Template Version hochsetzen.
Das macht es natürlich etwas umständlicher, da ich wirklich bei jeder Änderung and der Custom.css auch die Template.xml anfasse, dann im Anschluss den Cache löschen muss etc.

Ich hätte mir erhofft, dass es bspw. eine Art "Developer Mode" gibt, in der diese Logik einfach übersprungen wird, damit man quasi dauerhaft Änderungen machen kann ohne dass da ein Cache läuft oder man Versionen hochziehen muss. Und sobald man mit seinem Template fertig ist, deaktiviert man diesen wieder und die Caching-Logik greift korrekt.

 

[css-umsetzung]

du könntest wenn das wenn die Komprimierung eingeschaltet ist auch einfach in der header.tpl ändern das du da z.B: das draus machst

                <link rel="preload" href="{$ShopURL}/{$combinedCSS|cat:"&"|cat:time()}" as="style" onload="this.onload=null;this.rel='stylesheet'">

Das sollte in dieser Form nicht, im produktiv Modus drin bleiben.
Da würde ich eher, damit der User der nach einem Tag kommt eher ein Datum einbinden.

 

[weisser-dev]

du könntest wenn das wenn die Komprimierung eingeschaltet ist auch einfach in der header.tpl ändern das du da z.B: das draus machst

                <link rel="preload" href="{$ShopURL}/{$combinedCSS|cat:"&"|cat:time()}" as="style" onload="this.onload=null;this.rel='stylesheet'">

Das sollte in dieser Form nicht, im produktiv Modus drin bleiben.
Da würde ich eher, damit der User der nach einem Tag kommt eher ein Datum einbinden.

Ok danke, werde es mal verproben und berichten ob es mein Problem gelöst hat!