Jak obsługiwać / czyścić przestarzałe zagregowane css / js?

Używam tylko Drupala 7 wbudowanego w agregację CSS / JS, jednak folder plików, w którym na żywo są pliki css.gz i js.gz, zapełnia się w dość szybkim tempie i chociaż jestem pewien, że to trochę potrwa zanim zacznie całkowicie wypełniać dysk, teraz jest tak dobry czas, jak każdy, aby poradzić sobie z sytuacją.

• Bieżąca liczba plików w / js wynosi 335
• Bieżąca liczba plików w / css wynosi 451

Czy jest jakaś standardowa metoda, którą powinienem zastosować, aby poradzić sobie z tą sytuacją? Wolałbym rozwiązanie, które utrzymuje drupala w pętli.

Ponadto widzę, że wiele plików gz ma odpowiedniki inne niż gz. Czy istnieje jakiś powód, dla którego przechowywane są pliki .css i .css.gz? Może degredacja?

Dzięki

Jest to właściwie zaprojektowane, aby strony w pamięci podręcznej ze starszymi wersjami plików nie ulegały uszkodzeniu. Zobacz ten zamknięty problem .

TL; DR: Będą usuwane automatycznie 30 dni (lub cokolwiek drupal_stale_file_thresholdustawiona jest twoja zmienna) po ich utworzeniu za pomocą drupal_clear_css_cache()i drupal_clear_js_cache(). Rozwiązaniem jest więc zmodyfikowanie drupal_stale_file_thresholdwartości na coś niższego niż domyślny 30 dni.

• Kiedy usuwane są stare pliki?

  Stare pliki pamięci podręcznej nie są usuwane natychmiast po opróżnieniu zmiennej wyszukiwania, ale są usuwane po określonym czasie przez drupal_delete_file_if_stale (). Dzięki temu pliki, do których odwołuje się strona w pamięci podręcznej, będą nadal dostępne.

drupal_delete_file_if_stale() domyślnie jest to 30 dni - więc jeśli a) Cron działa poprawnie i b) widzisz zagregowane pliki starsze niż 30 dni, masz inny problem.

variable_get('drupal_stale_file_threshold', 2592000)jest czekiem 30-dniowym. variable_set('drupal_stale_file_threshold', 172800)zmieni limit czasu na dwa dni. W witrynie, w której obsługa pamięci podręcznej jest ściśle kontrolowana, czas może być jeszcze krótszy.

Źródło: http://api.drupal.org/api/drupal/include!common.inc/function/drupal_build_css_cache/7
Zobacz drupal_delete_file_if_stale()więcej informacji.

• Czy istnieje jakiś powód, dla którego przechowywane są pliki .css i .css.gz?

  Jeśli włączona jest kompresja gzip CSS, włączone są czyste adresy URL (co oznacza, że ​​reguły przepisywania działają) i rozszerzenie zlib jest dostępne, a następnie utwórz wersję tego pliku spakowaną gzipem. Ten plik jest udostępniany warunkowo przeglądarkom, które akceptują gzip przy użyciu reguł .htaccess.

Źródło: http://api.drupal.org/api/drupal/include!common.inc/function/drupal_build_css_cache/7 (W komentarzach funkcji)

Zobacz także, drupal_build_js_cache()który jest prawie identyczny drupal_build_css_cache().

Po 4 latach muszę się nie zgodzić z pierwszą odpowiedzią, w której autor stwierdza:

„Dzięki temu pliki, do których odwołuje się strona w pamięci podręcznej, będą nadal dostępne.”.

Być może potwierdza, że ​​rzeczy zostały zmienione / zoptymalizowane w zakresie udostępniania starszych plików, ale jeśli ręcznie usunę starszy plik na serwerze w pliku files / advagg_js (którego najwyraźniej nadal używam w jednej z moich przeglądarek), ponowne ładowanie strony jest regenerowane dokładnie ten sam plik z ostatnio dodanym kodem źródłowym javascript, tak jakby drupal_build_js_cache()został wykonany na tej zagregowanej nazwie pliku.

na przykład. js__22qMV1d_G25luSFBkuR7bIuKD5FE80eKuXx6ldibEixg__yjA2JTeF2f1LUJ3PMdjMr8k9nOPZQJIcvVw-c5Gz_yc__FY0NTHFBVMd9MIGE5srDXTejEZGP-ccSH7UX2zImN-0.js

Podsumowując, ustawienie znacznie niższej wartości drupal_stale_file_thresholdnie spowoduje żadnych problemów, a nawet usunięcie wszystkich plików agregowanych, a następnie wyczyszczenie pamięci podręcznej wymusi regenerację agregatów (przetestowane i potwierdzone działanie przy przeładowywaniu stron)

• Pobierz moduł reguł
• Dodaj nową regułę, która zostanie wykonana podczas działania crona
• Jako akcję wybierz wykonaj kod php.
• Napisz kod php

Może to być coś takiego:

$dir = 'your/directory/';
  foreach(glob($dir.'*.*') as $v){
  unlink($v);
}

Te funkcje php mogą pomóc ci zmodyfikować kod, jak chcesz.

• Glob http://php.net/manual/en/function.glob.php
• odłączyć http://uk.php.net/manual/en/function.unlink.php

Bądź bardzo ostrożny przed wykonaniem tego! Jeśli nie zostanie właściwie wykorzystany, możesz usunąć swoją stronę! Przed wypróbowaniem tego kodu przetestuj go na hoście lokalnym