Neu cache busting der JS / CSS files von plugins / templates

[Toskan]

wenn ein plugin JS file geladen wird sieht das so in den chrome dev tools aus

myjsfile.js?v=4.06

4.06 nehme ich an, kommt vom shop? e.g. die shop version ist 4.06

gibt es für mich eine möglichkeit, das javascript file zu updaten ohne einen komplett neuen Versionsfolder anzulegen?


wie stehts bei template files? momentan wird das ja etwa so geladen:

/templates/evo-child/css/mytheme.css?v=4.06

wieder, 4.06

wenn ich mein css erneure, möchte ich natürlich selbst die Versionszahl erhöhen, sonst zerbricht ja alles.

 

[martinwolf]

Ich verstehe ehrlich gesagt Deine Frage nicht. Du kannst deine JS-Dateien jederzeit updaten. Der Wert des Parameters wird aus der PHP Konstante "JTL_VERSION" gezogen und spielt bei einem Update keinerlei Rolle. Es soll Dir nur suggerieren, welche Shopversion im Einsatz ist.

 

[FPrüfer]

Hallo,

gibt es für mich eine möglichkeit, das javascript file zu updaten ohne einen komplett neuen Versionsfolder anzulegen?

Wenn du Änderungen an einem Plugin vornimmst die "released" werden musst du auch die Version anpassen, sprich einen neuen Versionsordner anlegen. Dieses Vorgehen ist ja unabhängig davon, ob du ein komplettes Refactoring machst oder nur einen Bug in einem Javascript-File behebst.
Das v=xxx wird vom Shop an Template-Resourcen angehängt, um den Browser bei einem Template-Update zu zwingen die Resourcen neu zu laden und nicht aus dem Browser- Cache zu holen.
Beim Entwickeln musst du halt deinen Browser durch Hard-Reloads dazu bewegen die geänderten Datei statt der Cache-Versionen zu laden.

 

[Toskan]

Hallo,

Wenn du Änderungen an einem Plugin vornimmst die "released" werden musst du auch die Version anpassen, sprich einen neuen Versionsordner anlegen. Dieses Vorgehen ist ja unabhängig davon, ob du ein komplettes Refactoring machst oder nur einen Bug in einem Javascript-File behebst.

also das plugin wird ja nur intern verwendet in unsrem eigenen Shop. Man muss dann nicht für jeden kleinen fix ein release machen.

"Das v=xxx wird vom Shop an Template-Resourcen angehängt, um den Browser bei einem Template-Update zu zwingen die Resourcen neu zu laden und nicht aus dem Browser- Cache zu holen. "
Ok also ich habe es gefunden, es ist der Eintrag
<Version>4.06</Version>

im template.xml
den kann ich dann auf 455 oder was auch immer setzen...

obendrauf muss ich dann noch btw in den admin bereich, und dort ins template, in die einstellungen, und dann speichern drücken, dann zieht es die neue version nummer, und busted den cache.


das busted dann auch den cache von den plugins.

 

[martinwolf]

Vergiss doch mal die Version, die ist nur für den Cache relevant. Wenn die Ressourcen verändert werden, dann werden diese auch direkt ausgerollt, egal was da für eine Version hinten dran hängt.

 

[Toskan]

Vergiss doch mal die Version, die ist nur für den Cache relevant. Wenn die Ressourcen verändert werden, dann werden diese auch direkt ausgerollt, egal was da für eine Version hinten dran hängt.

alle wiederkehrenden Kunden sehen die neue Version natürlich nicht es sei denn sie machen einen hard reload oder eben du erhöhst die Version. Und welche Kunden machen schon einen hard reload? d.h. das erhöhen der Version ist sehr wichtig, es sei denn dir ists egal ob die wiederkehrenden Kunden deinen shop nicht mehr benutzen können

 

[martinwolf]

Du kannst die Version aber nicht ändern. Was machst du nun? Richtig, den Template und Objektcache leeren.

 

[Toskan]

Du kannst die Version aber nicht ändern. Was machst du nun? Richtig, den Template und Objektcache leeren.

lieber martin

ja du kannst die template version ändern, ist weiter oben beschrieben wie.

Vorsicht:
die version darf nicht
1.00 sein, oder 1.01
Weil .00 wird ignoriert
du kannst
100
oder 101 etc benutzen
einfach kein punkt afaik

 

[martinwolf]

lieber martin

ja du kannst die template version ändern, ist weiter oben beschrieben wie.

Vorsicht:
die version darf nicht
1.00 sein, oder 1.01
Weil .00 wird ignoriert
du kannst
100
oder 101 etc benutzen
einfach kein punkt afaik

Ich bin Servicepartner, ich verkaufe Templates und passe Templates nach Kundenwunsch hin an. Ich weiß daher, dass man die Version in der template.xml ändern kann. Aber das ist im Falle von Anpassungen an js- oder css-Dateien absolut NICHT notwendig. Template- Cache im Admin leeren, dann zieht sich der Browser auch entsprechend die neuen Versionen. Oder willst Du jetzt für jede noch so kleine Änderung die Version hochsetzen? Ist doch Blödsinn.

 

[css-umsetzung]

Der Browser- Cache bekommt davon aber nichts mit, daher bin ich vereinzelt dazu übergegangen, z.B. Teile des Datums und der Zeit mit zu übergeben. Tag und Stunde Beispielsweise.

 

[Toskan]

manchmal reg ich mich auf ohne Grund.
Ich habe gemerkt, dass der ansatz, dass ich egal wie alt oder erfahren, einfach immernoch am Lernen bin. Seither bin ich viel entspannter

@css-umsetzung ich denke wenn du den browser cache immer busten willst, kannst du das auch per htaccess / nginx config machen. Der expires header wird wohl dort gesetzt. Aber: wo bustest du den cache mit dem Datum? in den template files meine ich. Dann kann ich das auch überschreiben mit einer Version damit muss ich dann nicht immer ins Backend um speichern zu drücken, das war mir bisher immer lästig.

@martinwolf
mal schauen ob ich hier ein image einfuegen kann


fangen wir unten rechts an, da steht Code 200 (from disk cache) das heisst das der browser eben nicht zum server verbindet und schaut ob es eine neue version gibt
warum macht der das denn nicht?
oben drueber

expires Wed 02 Oct

darum nicht. der jtl shop verteilt also die css und js files mit dem Hinweis dass die files eben erst in einem Monat erneuert werden muessen. Bis zu dem Datum, wird nix erneuert vom Browser, der behaelt die Files einfach bis dann.

also da muss man im Detail dann noch etwas aufpassen, max-age hat auch einen Effekt.

sobald das wie oben links markierte v=1 auf v=2 wechselt, meint der Browser "Oh, eine neue Datei" und kann dann also zwangsweise nicht eine lokal gecachte version ziehen.


Caching ist also gut. Man sollte auch nicht ein monat cachen sondern ein Jahr imho.

was imho eine bessere Lösung wäre:
einfach die Version in der shop config setzen e.g. ich glaub es war

config.JTL-Shop.ini.php

und die version dann jeweils irgendwie im template zum js / css load attachen statt der template version.
zum entwickeln kannst ja hard reloaden...

 

[css-umsetzung]

Wenn du das über die htaccess machst, ist deine Bewertung bei Google (pagespeed) fürn Ars...

Das ist eine einmalige Sache im Template und wird über $smarty.now geregelt.

 

[martinwolf]

Für Anpassungen an den Ressourcen könnte man die Cache Control auch runterfahren und anschließend wieder auf 1 Jahr hoch setzen, nachdem die neuen Versionen im Cache liegen. Aber mir an sich vollkommen egal wie Du es machst. Nimm den weg der für Dich am komfortabelsten ist.

 

[Toskan]

Wenn du das über die htaccess machst, ist deine Bewertung bei Google (pagespeed) fürn Ars...

Das ist eine einmalige Sache im Template und wird über $smarty.now geregelt.

hmm also Caching ist mir wichtig, ich würde das also niemals ausschalten es sei denn, auf einem Dev shop oder so. Die ganzen riesigen JS und CSS files, das runter zu laden immer auf jedem request macht alles schon langsamer...

wenn ich dich richtig verstanden habe, verarscht du den page load speed benchmark einfach? e.g. du gibts datum und uhrzeit an alle files mit, der benchmark sieht dann "die files sind ein monat gültig, ist gut, pass" beim nächsten request haben die files dann aber ein neues Datum Uhrzeit udn der cache wird auf jedem request gebusted?

besser wäre das last modified date vom file auszulesen und das zu attachen e.g. v=datefilelastmodified, das ist halt auch nicht immer sicher, weil das wird je nachdem auch nach einem upload nicht erneuert (das Datum).

der einfachste mittelweg wäre es imho wirklich eine simple versions nummer die du halt hochsetzen musst mit dem Nachteil momentan, dass man halt ins backend muss immer, e.g. musst mehrere Sachen machen um die Versionsnummer zu erhöhen was etwas lästig ist.

 

[css-umsetzung]

wenn ich dich richtig verstanden habe, verarscht du den page load speed benchmark einfach? e.g. du gibts datum und uhrzeit an alle files mit, der benchmark sieht dann "die files sind ein monat gültig, ist gut, pass" beim nächsten request haben die files dann aber ein neues Datum Uhrzeit udn der cache wird auf jedem request gebusted?

In den früheren Versionen habe ich auch die .htaccess erweitert, weil der cache da normal nur auf 86400 stand, über eine kleine Modifikation konnte ich den auf ein Jahr hochschrauben damit Google sich nicht ständig beschwert
-> RewriteRule ^asset/(.*)$ includes/libs/minify/?g=$1&1234 [L]

Du siehst das auch falsch, der User bekommt davon ja nichts mit, es ist wenn er drei Tage später kommt nur das erste Laden (so wie wenn er wie alle anderen das erste mal auf die Seite kommt) weil er das JS und das CSS neu cached.
danach bzw. innerhalb von einer Stunde hat er den gleichen cache wie ohne meine Modifikation.

Google denkt weiterhin das alles schön ist weil Google sich nur für die Cache Zeit interessiert aber nur so kannst du einigermaßen sicherstellen das ein User das aktuelle CSS und JS hat.
Ich mache das auch nur auf Seiten wo ständig Änderungen sind und es ist einfacher als ständig und sinnlos eine Versionsnummer hochzuzählen.

Ich glaube Themeart oder Salepix haben in Ihren Templates extra ein Feld eingebaut in dem du eine Nummer hochzählen kannst wenn du Änderungen vorgenommen hast, geht auch aber du musst immer daran denken.