{"id":6698,"date":"2019-09-23T15:28:50","date_gmt":"2019-09-23T13:28:50","guid":{"rendered":"https:\/\/www.recolize.com\/?p=6698"},"modified":"2019-09-24T08:04:18","modified_gmt":"2019-09-24T06:04:18","slug":"wordpress-cache-busting-design-aenderungen","status":"publish","type":"post","link":"https:\/\/www.recolize.com\/de\/blog\/wordpress-cache-busting-design-aenderungen\/","title":{"rendered":"WordPress Cache Busting – oder wieso erscheinen meine Design-\u00c4nderungen nicht?"},"content":{"rendered":"
\n \n
<\/div>\n\n
\n
\n
\n

Als Betreiber einer WordPress Website oder eines Blogs werden Sie die Situation vielleicht kennen: Sie haben einige wundersch\u00f6ne Design-Anpassungen im Adminbereich vorgenommen und sobald Sie eine Vorschau der \u00c4nderungen anzeigen m\u00f6chten, sind diese nicht mehr vorhanden – egal was Sie versuchen. In diesem Fall wird eine Technik namens „Cache Busting“ ben\u00f6tigt.<\/p>\n

Einer der vielen m\u00f6glichen Gr\u00fcnde f\u00fcr dieses Verhalten ist der Caching-Mechanismus des Browsers. Prinzipiell macht es Sinn, dass der Browser nicht immer alle Stylesheets und JavaScript-Dateien bei jedem Aufruf der Seite herunterladen muss, da in der Regel die Frequenz, mit der sich diese Dateien \u00e4ndern, sehr gering ist. Deswegen weisen sehr viele Websites den Browser an, statische Dateien wie CSS und JavaScript zum Beispiel f\u00fcr 1 Jahr im Cache zu halten. Damit wird eine Menge Bandbreite auf Browser-Seite und zahlreiche Requests server-seitig gespart und die Website kann deutlich schneller angezeigt werden.
\nEine sehr gute Erkl\u00e4rung \u00fcber verschiedene Cache-Techniken von Browsern findet sich hier<\/a>.<\/p>\n

Der Nachteil dieses Verhaltens ist, dass der Browser wissen muss, wenn sich der Inhalt der (CSS- und JavaScript-)Dateien ge\u00e4ndert hat. Ansonsten w\u00fcrde er diese Dateien einfach nicht erneut herunterladen und die Version aus seinem internen Cache verwenden. Das ist genau der Fall, wenn der Anwender die durchgef\u00fchrten Design-\u00c4nderungen nicht sieht, solange er nicht seinen Browser-Cache leert (was niemand macht).<\/p>\n

Ein einfacher Weg, dieses Problem zu l\u00f6sen, ist, den Dateinamen oder -pfad der CSS- und JavaScript-Dateien jedes Mal zu \u00e4ndern, wenn sich deren Inhalt \u00e4ndert (Hinweis: es gibt nat\u00fcrlich noch andere Wege \u00fcber\u00a0E-Tags<\/a>\u00a0oder Last-Modified Header, aber das hier ist der einfachste). Dieser Prozess, den Cache zu invalidieren, ist als „Cache Busting“ bekannt.
\nIm Standard h\u00e4ngt WordPress an jede CSS- und JavaScript-Datei die installierte WordPress-Version an und zwar so:
\nhttp:\/\/demo.wordpress.recolize.com\/wp-includes\/js\/comment-reply.min.js?ver=5.2.3<\/u><\/em>
\n<\/strong>(Nebenbei bemerkt ist dieser Weg nicht sehr clever, da so die installierte WordPress Version von au\u00dfen sichtbar ist und ggfs. Sicherheitsl\u00fccken aufzeigt).<\/p>\n

Die WordPress Version wird angef\u00fcgt, damit bei jedem Upgrade – das m\u00f6glicherweise auch eine neue Theme-Version mit Design-\u00c4nderungen enth\u00e4lt – der Browser die statischen Dateien neu herunterl\u00e4dt.
\nDie meisten WordPress-Themes verwenden statische Stylesheets, die automatisch generiert werden, sobald \u00c4nderungen am Design im Backend vorgenommen werden. Das Problem ist, dass der Browser des Anwenders dies nicht mitbekommt, solange sich die WordPress-Version nicht \u00e4ndert.<\/p>\n

Die L\u00f6sung f\u00fcr dieses Problem ist ziemlich einfach: wir modifizieren den „ver“-Parameter, so dass er einen sogenannten Hash des \u00c4nderungsdatums der Datei enth\u00e4lt. Auf diese Weise wird jedes Mal, wenn die Datei neu generiert wird, das \u00c4nderungsdatum aktualisiert und damit \u00e4ndert sich der Hash. Dies bedeutet, dass der Browser einen neuen Dateinamen erkennt und die ge\u00e4nderte Datei vom Server anfragt. Unser Dateiname sieht jetzt wie folgt aus:\u00a0http:\/\/demo.wordpress.recolize.com\/wp-includes\/js\/comment-reply.min.js?ver=1534832128<\/u><\/em><\/p>\n

Unten finden Sie ein Code Snippet, das z.B. in die WordPress WordPress functions.php<\/em> Datei integriert werden kann:<\/p>\n<\/div>\n

\n 
<?php\r\n\/**\r\n * WordPress Cache Busting made simple.\r\n *\r\n * @author Recolize GmbH <service@recolize.com>\r\n * @license http:\/\/opensource.org\/licenses\/GPL-3.0 GNU General Public License Version 3 (GPLv3)\r\n *\r\n * This script is based on\r\n * @see https:\/\/medium.com\/@futuremediagr\/easy-versioning-for-css-and-js-files-in-wordpress-e7dad756586c\r\n * @see https:\/\/gist.github.com\/ocean90\/1966227\r\n *\/\r\n\r\nfunction set_custom_ver_css_js($src)\r\n{\r\n    \/\/ Don't touch admin scripts.\r\n    if (is_admin()) {\r\n        return $src;\r\n    }\r\n\r\n    $_src = $src;\r\n    if (strpos($_src, '\/\/') === 0) {\r\n        $_src = 'http:' . $_src;\r\n    }\r\n\r\n    $_src = parse_url($_src);\r\n\r\n    \/\/ Give up if malformed URL.\r\n    if (false === $_src) {\r\n        return $src;\r\n    }\r\n\r\n    \/\/ Check if it's a local URL.\r\n    $wordPressUrl = parse_url(home_url());\r\n    if (isset($_src['host']) && $_src['host'] !== $wordPressUrl['host']) {\r\n        return $src;\r\n    }\r\n\r\n    $filePath = ABSPATH . $_src['path'];\r\n    if (file_exists($filePath) && strpos($src, 'ver=') !== false) {\r\n        $src = add_query_arg('ver', filemtime($filePath), $src);\r\n    }\r\n\r\n    return $src;\r\n}\r\n\r\nfunction css_js_versioning()\r\n{\r\n    add_filter('style_loader_src', 'set_custom_ver_css_js', 9999);\r\n    add_filter('script_loader_src', 'set_custom_ver_css_js', 9999);\r\n}\r\n\r\nadd_action('init', 'css_js_versioning');\r\n<\/pre>\n<\/div>\n<\/div>        <\/div>\n    <\/div>\n<\/section>\n\n","protected":false},"excerpt":{"rendered":"
Als Betreiber einer WordPress Website oder eines Blogs werden Sie die Situation vielleicht kennen: Sie haben einige wundersch\u00f6ne Design-Anpassungen im Adminbereich vorgenommen und sobald Sie eine Vorschau der \u00c4nderungen anzeigen m\u00f6chten, sind diese nicht mehr vorhanden – egal was Sie versuchen. In diesem Fall wird eine Technik namens „Cache Busting“ ben\u00f6tigt. Einer der vielen m\u00f6glichen<\/p>\n","protected":false},"author":3,"featured_media":6750,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[774,26],"tags":[],"_links":{"self":[{"href":"https:\/\/www.recolize.com\/de\/wp-json\/wp\/v2\/posts\/6698"}],"collection":[{"href":"https:\/\/www.recolize.com\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.recolize.com\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.recolize.com\/de\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/www.recolize.com\/de\/wp-json\/wp\/v2\/comments?post=6698"}],"version-history":[{"count":5,"href":"https:\/\/www.recolize.com\/de\/wp-json\/wp\/v2\/posts\/6698\/revisions"}],"predecessor-version":[{"id":6751,"href":"https:\/\/www.recolize.com\/de\/wp-json\/wp\/v2\/posts\/6698\/revisions\/6751"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.recolize.com\/de\/wp-json\/wp\/v2\/media\/6750"}],"wp:attachment":[{"href":"https:\/\/www.recolize.com\/de\/wp-json\/wp\/v2\/media?parent=6698"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.recolize.com\/de\/wp-json\/wp\/v2\/categories?post=6698"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.recolize.com\/de\/wp-json\/wp\/v2\/tags?post=6698"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}