Ordnungsgemäß in WordPress eingebundene JS- und CSS-Dateien werden bei der Ausgabe mit einer Versionsnummer als GET-Parameter ausgestattet. Dieses Verhalten dient dem sg. Cache-Busting. Eine sinnvolle Core-Funktion finde ich.
Allerdings gibt es in meinen Augen ein generelles Problem mit dem Fallback, der einspringt wenn beim entwickeln etwas sparsam gearbeitet wurde. Ein Punkt der durch automatische (Sicherheits-)Updates nur verstärkt wird. Beschrieben habe ich dies bereits vor einiger Zeit in diesem Trac-Ticket.
Da eine automatische Lösung kompliziert erscheint, bleibt erst mal nur der Weg es richtig zu machen.
Bedeutet es muss immer wenn die Version des Theme angehoben wird an mehreren Stellen geschaut werden ob auch dort der String angepasst werden muss. Namentlich:
- Header-Info in der (Child-)Theme: style.css
- Alle Enqueue-Funktionen für (Child-)Theme CSS-Datei in functions.php
- Alle Enqueue-Funktionen für (Child-)Theme JS-Datei in functions.php
- ggf. weitere Code-Stellen
Etwas das wenn wir mal ehrlich sind gerne mal untergeht und dann zu defekten Darstellungen bei Website-Besuchern führen kann.
Automatisieren was geht
Um sich den Aufwand des suchen und ersetzen der Versionsnummer innerhalb eines Theme zu sparen, sieht man immer wieder die Verwendung von PHP-Konstanten. Ein halb-garer Weg. Man reduziert den Aufwand zwar aber es verbleiben 2 Code-Stellen, die zu editieren sind.
Close, but not yet there.
Als inzwischen schon langjähriger Benutzer von WordPress befasse ich mich immer gerne mit allem Möglichen rund um dieses CMS. Dazu gehören auch immer wieder Meetups und Konferenzen. Nach verschiedenen Städten in den letzten Jahren hat sich dieses Jahr ein Team aus dem 
Beim regelmäßig stattfindenden