Einen Vorschlag in der Antwort zu diese Frage , sowie dieser Artikel die eine fast identische lösung bietet, habe ich versucht, htaccess einzurichten, um eine autoversionierungsregel für meine js und css-dateien zu handhaben.
Der Grund, warum ich das tun möchte, ist, dass ich sie ziemlich oft ändere, aber immer noch möchte, dass sie von Browsern für aggressiv lange Zeiträume zwischengespeichert werden, ohne bei jeder Änderung manuell eine neue Versionsnummer eingeben zu müssen. p>
Die verwendete Methode ist einfach: (1) eine Funktion hängt eine Versionsnummer an Dateien an, die das Datum verwenden, an dem sie geändert wurden, im Muster [filename].[version_number].[suffix] , also wird style.css zum Beispiel% Code%; (2) mit php ist die versionierte Nummer in der Stylesheet-Deklaration für die Seiten meiner Site enthalten, und diese wird an Client-Browser geliefert, die eine neue Kopie anfordern, wenn der Name der versionierten Datei von dem zwischengespeicherten Namen abweicht; (3) Eine RewriteRule in .htaccess mit mod_rewrite schreibt die Versionsnummer neu, setzt sie auf ihren ursprünglichen Wert zurück und liefert die aktualisierte Datei.
Der Code, den ich in jeder dieser drei Phasen verwende, ist unten aufgeführt. Ich teste das auf dem Stylesheet in einer Sandbox-Version meines Blogs auf Ссылка
style.1300638388.css -Teil meiner Blog-Dateien Mit dem oben beschriebenen Setup werden Seiten ohne Formatierung angezeigt, und der Quellcode der generierten Seite zeigt, dass auf das Stylesheet als versionierte Nummer verwiesen wird, die natürlich nicht auf dem Server existiert.
Dies würde darauf hindeuten, dass die Funktion den Namen des Stylesheets korrekt ändert, aber dass das Regex-Muster in RewriteRule in .htaccess aus irgendeinem Grund den Dateinamen nicht abfängt und neu schreibt. In der Tat, es fängt es nicht einmal, wenn ich es in <head> ändern.
Ich habe mehrere Muster ausprobiert, ohne Erfolg, aber es muss etwas ziemlich Grundlegendes fehlen.
^style.1300638388.css$ style.css [L] ist auf dem Server aktiviert und wird ohne Probleme für mehrere andere RewriteRule-Instanzen ausgeführt.
AKTUALISIEREN
Die einzige andere RewriteRule in der mod_rewrite -Datei ist die standardmäßige WordPress Pretty URL Rewrite-Regel. Ich bezweifle, dass es sich hier einmischt, obwohl ich natürlich ohne die WordPress-Regel nicht ohne weiteres testen kann, da dies die Seitengenerierung komplett zerstören würde:
UPDATE 2: Gelöst
CharlesLeaf hat in einem Kommentar darauf hingewiesen, dass, da die WordPress-Regel vor der Versionierung war, diese nicht ausgeführt würde. Dies war tatsächlich der Grund und erlaubte mir, die Frage zu beantworten, indem ich die zwei Regeln wie folgt gruppiere:
%Vor%^ bedeutet "Beginn der Zeichenfolge", in diesem Fall nicht "style", sondern / path / to / style.
Sie könnten es mit dem vollständigen Pfad in der Regex versuchen oder vielleicht in RewriteBase schauen.
aktualisierte Lösung Das Problem in diesem Szenario war, dass es andere RewriteRules vor dem fraglichen gab, also erreichte es nie diese RewriteRule. Die richtige Reihenfolge der RewriteRules ist wichtig.
Vielen Dank für die .htaccess-Lösung. Ich hatte Probleme mit jQuery-Plugin-Dateien, die ein eigenes Versionierungsschema im Dateinamen enthalten, wie in jquery.NAME-OF-PLUGIN.1.1.1.js. Ich empfehle, die geänderte Dateizeit mit [0-9]{10} zu analysieren, so dass nur ein zehnstelliges Suffix "entfernt" wird. Es ist immer noch möglich für Fehler, wenn der Dateiname zehn Ziffern am Ende hat, aber das wäre ein seltener Randfall.
Auch 11 Ziffern im UNIX Epoch-Zeitstempel müssen erst am Samstag, den 20. November 2286 17:46:40 GMT berücksichtigt werden.
Tags und Links php regex .htaccess mod-rewrite versioning