JPresta Speed Pack

Ci fałszywi użytkownicy są tworzeni przez Page Cache Ultimate w celu anonimizacji pamięci podręcznej (nowa metoda). Nie wolno ich usuwać (zostaną ponownie utworzone).

Tych fałszywych użytkowników nie będzie dużo, prawdopodobnie mniej niż 5, zależy to od ilości grup i różnic w wyświetlaniu między nimi.

Nie są aktywni, więc nie będą przeszkadzać w Twoich statystykach.

Jeśli masz motyw Anvato, oto co należy zrobić, aby uniknąć otwierania koszyka za każdym razem, gdy jest on odświeżany.

Skopiuj plik /modules/an_theme/views/js/sidebarcart.js w swoim motywie, abyś mógł go nadal aktualizować bez utraty modyfikacji, w /themes//modules/an_theme/views/js(utwórz foldery w razie potrzeby)

W tym pliku zastąpić ligne:

if (prestashop.page.page_name != 'cart' && prestashop.page.page_name != 'checkout') {

Przez

if (prestashop.page.page_name != 'cart' && prestashop.page.page_name != 'checkout' && requestData.action!='refresh') {

Następnie wyczyść pamięć podręczną na stronie Performances i pamięć podręczną przeglądarki, abyś mógł przetestować.

Jeśli twój motyw używa tagu "widgetblock", tak jak robi to motyw Warehouse, to musisz wyczyścić pamięć podręczną na stronie Performances po włączeniu Page Cache, aby szablon został skompilowany ponownie.

If you are using Nginx, then make sure your configuration is as follow:

"Proxy mode" must be ON, other options must be OFF.

Jeżeli używasz modułu PageSpeed Apache opracowanego przez Google (x-mod-pagespeed) to musisz wyłączyć poniższą opcję, aby nie nadpisywała ona dyrektyw cache przeglądarki dodanych przez Page Cache:

ModPagespeedModifyCachingHeaders off

Nie, jest wysoce zalecane, aby zachować Smarty cache włączone. Przyspieszy to działanie stron, które nie są buforowane, a także stron, na których bufor nie został jeszcze wygenerowany.

Aby odzyskać swoje style, musisz po prostu wyczyścić pamięć podręczną "Page Cache Ultimate".

Aby uniknąć tego problemu możesz wejść w "Tryb zaawansowany", w konfigurację "Page Cache Ultimate", a następnie w "Klucz pamięci podręcznej" włączyć "Wstaw wersję CSS i JS do klucza pamięci podręcznej".

To avoid the cookie notice to appear 1 second, then disappear, you must override the javascript file of the iqitcookielaw module.

To do it, create a file with the following content:

$(document).ready(function () {
 if (getCookie('cookielaw_module') != 1) {
  $("#iqitcookielaw").addClass('iqitcookielaw-showed');
 }
 $("#iqitcookielaw-accept").click(function (event) {
  event.preventDefault();
  $("#iqitcookielaw").removeClass('iqitcookielaw-showed');
  setcook();
 });
});

function setcook() {
 var name = 'cookielaw_module';
 var value = '1';
 var today = new Date();
 var expire = new Date();
 expire.setTime(today.getTime() + 3600000 * 24 * 14);
 document.cookie = name + "=" + escape(value) + ";path=/;" + ((expire == null) ? "" : ("; expires=" + expire.toGMTString()))
}

function getCookie(cname) {
 var name = cname + "=";
 var ca = document.cookie.split(';');
 for (var i = 0; i != ca.length; i++) {
  var c = ca[i];
  while (c.charAt(0) == ' ') c = c.substring(1);
  if (c.indexOf(name) != -1) return c.substring(name.length, c.length);
 }
 return "";
}

And place it in the theme (or child theme if you have one): /themes/warehouse/modules/iqitcookielaw/views/js/front.js

Then clear the cache in the Performances page.

When the cache is created, the page is anonymized, that means it is displayed without any information about the visitor displaying the page.

Modules that display content relative to the current visitor can be marked as dynamic, that means the content will be refreshed (replaced) by a background request in the browser that will carry the context of the current visitor.

If you check the option "Display nothing in cache" then the module will not be called to display its content in this hook during the creation of the cache. However, the content will be displayed as other dynamic modules (with background request).

If the products list is reloaded each time you display a page with a products list then you can fix this by modifying the file /warehouse/modules/ps_shoppingcart/ps_shoppingcart.js as follow:

Zastąp tę linię:

prestashop.emit('updateFacets', window.location.href);

.

By:

if (event.reason && event.reason.linkAction != 'refresh') {
    prestashop.emit('updateFacets', window.location.href);
}

Uaktualnij Page Cache Ultimate przynajmniej do wersji 7.9.39, aby uzyskać pełną kompatybilność z modułem cookiesplus.

W konfiguracji koszyka, w sekcji "Akcja dodawania do koszyka" wyłącz opcję "Otwórz koszyk".

Tak, wszystkie zdjęcia z Twojego sklepu zostaną automatycznie przekonwertowane do formatu WEBP. Nawet obrazy z CMS lub innych modułów jak blog.

Jest to normalne, gdy pamięć podręczna nie jest dostępna, wyświetlanie jest tak samo wolne jak bez pamięci podręcznej.

Należy opróżniać pamięć podręczną tylko wtedy, gdy jest to konieczne (modyfikacja CSS lub Javascript, dla szablonów wybierz opcję "Przekompiluj pliki szablonów, jeśli zostały zaktualizowane" na stronie "Wydajność").

TAK nadal potrzebujesz modułu WEBP dla Prestashop! Ponieważ funkcja ta ma błąd w PS 8.0. Powinna być naprawiona w PS 8.1, ale sprawdzę to jak tylko zostanie wydana, bo nie wiem czy obrazy JPG będą wyświetlane przeglądarkom, które nie potrafią odczytać formatu WEBP jak Safari (iPhone).

To było bardzo zdradliwe, aby znaleźć konfigurację, która działa dobrze. Nie jestem ekspertem w konfiguracji nginx, więc domyślam się, że jest inny sposób na zrobienie tego. Jeśli chcesz poprawić tę konfigurację, skontaktuj się ze mną, z przyjemnością zaktualizuję ten post, aby pomóc innym ludziom!

Oto moje rozwiązanie (bądźcie uprzejmi).

Przed sekcją "serwer" umieść ten kod:

map $http_accept $webp_enable {
	default 0;
	"~*webp" 1;
}

Powie nam, czy przeglądarka odwiedzającego może odczytać obrazy WEBP.

Prawdopodobnie masz wiele linii "rewrite" dla wszystkich obrazów, umieść następujący kod tuż przed nim:

# Jpresta Speedpack
if ($webp_enable = 1) {
	# Rewrite images URL using a specific extension ".webp_compressor" so we can have specific rules to compress the image/svg
	# if the webp file is not already created.
	rewrite "^/c/([0-9]+)(\-[_a-zA-Z0-9-]*)/(.*)\.jpg$" /img/c/$1$2.webp_compressor last;
	rewrite "^/c/([_a-zA-Z-]+)/(.*)\.jpg$" /img/c/$1.webp_compressor last;
	rewrite "^/([0-9])(\-[_a-zA-Z0-9-]*)?/(\P{M}\p{M}*)*\.jpg$" /img/p/$1/$1$2.webp_compressor last;
	rewrite "^/([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?/(\P{M}\p{M}*)*\.jpg$" /img/p/$1/$2/$1$2$3.webp_compressor last;
	rewrite "^/([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?/(\P{M}\p{M}*)*\.jpg$" /img/p/$1/$2/$3/$1$2$3$4.webp_compressor last;
	rewrite "^/([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?/(\P{M}\p{M}*)*\.jpg$" /img/p/$1/$2/$3/$4/$1$2$3$4$5.webp_compressor last;
	rewrite "^/([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?/(\P{M}\p{M}*)*\.jpg$" /img/p/$1/$2/$3/$4/$5/$1$2$3$4$5$6.webp_compressor last;
	rewrite "^/([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?/(\P{M}\p{M}*)*\.jpg$" /img/p/$1/$2/$3/$4/$5/$6/$1$2$3$4$5$6$7.webp_compressor last;
	rewrite "^/([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?/(\P{M}\p{M}*)*\.jpg$" /img/p/$1/$2/$3/$4/$5/$6/$7/$1$2$3$4$5$6$7$8.webp_compressor last;
	rewrite "^/([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?/(\P{M}\p{M}*)*\.jpg$" /img/p/$1/$2/$3/$4/$5/$6/$7/$8/$1$2$3$4$5$6$7$8$9.webp_compressor last;  
	# all other images
	rewrite "^(.+)\.jpg$" $1.webp_compressor last;   
}

location ~* ^(.+)\.webp_compressor$ {
	# Indicates to proxies that the file content/format depends (Vary) on the "Accept" header
	add_header Vary Accept;

	# Indicates to proxies that the file can be cached for the max duration
	add_header Pragma public;
	add_header Cache-Control "public, must-revalidate, proxy-revalidate";
	expires max;

	# Indicates to nginx not to log access
	access_log off;
	log_not_found off;

	# Try to serve the WEBP file directly or compress the image
	set $url_webp_compressor "/modules/jprestaspeedpack/controllers/front/webp.php?src=$1.jpg";
	try_files $1.webp $url_webp_compressor;
}

OSTRZEŻENIE: jeśli używasz samodzielnego modułu kompresji WEBP, musisz zastąpić „jprestaspeedpack” przez „jprestawebp”.

Skontaktuj się ze mną, jeśli potrzebujesz pomocy lub jeśli możesz poprawić skrypt!

Jeśli lista wyboru waluty już nie działa, sprawdź te 2 opcje:

Opcja "Ignoruj adresy URL pasujące do tego regexa" musi zawierać ".*SubmitCurrency=1.*", np. ".*[&]q=.*|.*SubmitCurrency=1.*"

Opcja "Ignorowane parametry URL" nie powinna zawierać "submitcurrency,id_currency"

Możesz również chcieć wyłączyć pamięć podręczną przeglądarki, ponieważ jeśli odwiedzający zmieni walutę po obejrzeniu kilku stron, jeśli powróci do tych stron, zostanie wyświetlona oryginalna waluta.

Nie zapomnij wyczyścić modułu i pamięci podręcznej przeglądarki po tych zmianach.

tak, przeglądarki, które nie mogą odczytać formatu WEBP, otrzymają oryginalny format (JPG/PNG).

Kiedy modyfikujesz produkt, kategorię, stronę CMS, cenę, stan magazynowy itp. pamięć podręczna jest automatycznie odświeżana.

Kiedy dodajesz, usuwasz lub modyfikujesz moduł, musisz ręcznie wyczyścić pamięć podręczną, ponieważ nie można tego wykryć automatycznie. Na przykład podczas modyfikowania suwaka strony głównej.

Kiedy modyfikujesz CSS lub szablon motywu, musisz ręcznie wyczyścić pamięć podręczną, ponieważ nie można tego wykryć automatycznie.

Kiedy synchronizujesz lub modyfikujesz swój katalog, ceny i/lub stany magazynowe za pomocą zewnętrznej aplikacji, prawdopodobnie będziesz musiał wyczyścić pamięć podręczną ręcznie lub za pomocą skryptu, ponieważ przechwytywanie Prestashop nie jest wykonywane.

Aby wyczyścić pamięć podręczną określonych stron, możesz użyć adresów URL CRON/API, które znajdziesz w menu „API” w konfiguracji Page Cache Ultimate. Możesz także użyć tabeli statystyk do przefiltrowania stron, które chcesz odświeżyć, a następnie kliknąć przycisk „Wyczyść pamięć podręczną (tylko pliki)”.

Należy również pamiętać, że pamięci podręcznej przeglądarki nie można wyczyścić, dlatego jest ona ograniczona w czasie.

Dzieje się tak, ponieważ link logowania jest ładowany dynamicznie i dlatego parametr "back", który odwołuje się do bieżącego adresu URL, jest ustawiony z adresem URL modułów dynamicznych.

Aby uniknąć tego problemu, wejdź w konfigurację strony Page Cache Ultimate, w menu "Dynamiczne moduły i widżety", na dole dodaj następujący kod javascript do pola "Javascript do wykonania":

if (!prestashop_pc.customer.is_logged) {
 $('header a').each(function() {
 $(this).attr('href').replace('ajax%3Dtrue', '').replace('page_cache_dynamics_mods%3D=1', '')
 });
}

Wyczyść pamięć podręczną i powinno to naprawić problem.

te katalogi są tworzone, gdy cache nie może być w pełni usunięty w PHP, ponieważ jest zbyt długi i nie powiedzie się z błędem timed out. Więc zamiast usuwać katalog cache, jest on po prostu zmieniany na ten z przyrostkiem.

Możesz usunąć wszystkie te katalogi z sufiksem please_delete_me, ale polecam zrobić to bezpośrednio w konsoli serwera, ponieważ będzie to zbyt długie, aby zrobić to przez FTP.

Te haki są przeznaczone dla twórców modułów, skontaktuj się z pomocą techniczną, jeśli potrzebujesz pomocy.

Oto przykład implementacji funkcji haków:

    /**
     * Called each time a page is displayed so this must remain very fast!
     * @param $params Empty array
     * @return mixed The datas you will need in hookActionJPrestaRestoreSpecificCacheKeyInfos()
     */
    public function hookActionJPrestaGetSpecificCacheKeyInfos($params) {
        // Let's say that the cookie 'test' modify the content of the page, we indicates to the cache manager
        // to generate a cache key that depends on the value of this cookie
        return $_COOKIE['test'];
    }

    /**
     * This function is called by Page Cache Ultimate when the cache-warmer service want to generate the cache of a
     * specific context. In this case we must restore the context so the content is the good one.
     * @param $params $params['specifics'] contains the datas returned by the hook 'ActionJPrestaGetSpecificCacheKeyInfos'
     */
    public function hookActionJPrestaRestoreSpecificCacheKeyInfos($params)
    {
        // Here we will just modify the $_COOKIE value, we don't need to send the cookie to the browser with function
        // setcookie, we just want the remaining PHP code to execute to get the correct value of the cookie.
        $_COOKIE['test'] = $params['specifics'];
    }

Moduł Creative Elements umożliwia edycję części sklepu za pomocą linków/przycisków wyświetlanych bezpośrednio w sklepie po połączeniu z administratorem Prestashop. Aby zachować tę funkcjonalność, pamięć podręczna jest dezaktywowana z powodem "editing-with-creative-element". Zapewniamy, że odwiedzający korzystają z pamięci podręcznej, tylko użytkownicy połączeni z administratorem nie mają pamięci podręcznej. Aby uzyskać dostęp do pamięci podręcznej, wystarczy wyświetlić sklep w prywatnej karcie przeglądarki.

Pierwszą rzeczą do zrobienia jest upewnienie się, że masz najnowszą wersję modułu, ponieważ stale go ulepszam, aby zmniejszyć zużycie pamięci, zarówno po stronie bazy danych, jak i dysku twardego.

Drugą rzeczą jest okresowe przeprowadzanie czyszczenia (co 2 lub 3 dni). Czyszczenie usuwa z pamięci podręcznej strony, które już nie istnieją lub których kontekst już nie istnieje. Nie ma to wpływu na wydajność pamięci podręcznej. Czyszczenie można wykonać ręcznie za pomocą przycisku pod tabelą statystyk pamięci podręcznej lub planując zadanie CRON z adresem URL wyświetlanym w menu "API (adresy URL CRON)" w konfiguracji modułu.

Wreszcie, jeśli w /var/cache/pagecache znajdują się katalogi kończące się na "please_delete_me", możesz je usunąć. Jest to stara pamięć podręczna, której PHP nie było w stanie całkowicie usunąć (zbyt długa).

Moduł nie wywołuje funkcji Hook, która umożliwia aktualizację.

Musisz zmodyfikować funkcję imageResize() w pliku /modules/prestablog/prestablog.php:

Zastąp to

         return ImageManager::write('jpg', $dest_image, $file_after);

Przez to

         $ret = ImageManager::write('jpg', $dest_image, $file_after);

 Hook::exec('actionOnImageResizeAfter', ['dst_file' => $file_after, 'file_type' => 'jpg']);

 return $ret;

następnie obrazy zostaną zaktualizowane.

Statyczna pamięć podręczna może być używana tylko wtedy, gdy znany jest kontekst odwiedzającego. Kontekst zawiera szereg informacji, których nie można wywnioskować na podstawie samego adresu URL: waluta, grupy użytkowników, wybór plików cookie, podatki do zastosowania itp.

Kontekst ten jest przechowywany w pliku cookie o nazwie "jpresta_cache_context", który jest dodawany, gdy użytkownik wyświetla pierwszą stronę. Gdy plik cookie jest obecny, można użyć statycznej pamięci podręcznej.

Przejdź do konfiguracji modułu, w menu "System pamięci podręcznej" upewnij się, że wybrana jest opcja "Prestashop Static!". Jeśli jest już zaznaczona, wybierz "Standardowy system plików" i zapisz, a następnie wybierz "Prestashop Static!" i zapisz ponownie. Spowoduje to ponowną aktywację statycznej pamięci podręcznej.

Komunikat "customer-specific-prices" oznacza, że jesteś połączony z użytkownikiem, który ma określone reguły cenowe, więc nie ma sensu tworzyć pamięci podręcznej, ponieważ tylko on będzie mógł z nich skorzystać. Lepiej jest tworzyć grupy użytkowników i tworzyć reguły cenowe dla tych grup.

Być może symulujesz ekran telefonu za pomocą konsoli przeglądarki, dlatego widzisz ten widok mobilny pomimo posiadania ekranu komputerowego.

Dzieje się tak, ponieważ plik cookie o nazwie 'jpresta_cache_context' przechowuje kontekst odwiedzającego w przeglądarce. Ten kontekst zawiera informacje o tym, czy widok jest 'mobilny' czy 'na pulpicie'. Dlatego jeśli początkowo wyświetlasz strony w trybie pulpitu, a następnie przełączysz się na tryb mobilny, pamięć podręczna nadal będzie dostarczać widok pulpitu.

Jeśli chcesz przetestować widok mobilny za pomocą konsoli przeglądarki, upewnij się, że usuniesz plik cookie 'jpresta_cache_context' wcześniej.

Nie, moduł tylko konwertuje obrazy JPG/PNG do formatu WEBP. Zaleca się wgrywanie obrazów jako JPG, ponieważ niektóre przeglądarki wciąż nie mogą ładować plików WEBP. Ponadto uważam, że JPG są lepsze jako obrazy oryginalne, ponieważ Prestashop tworzy wiele formatów/rozmiarów obrazów, dlatego oryginalny obraz powinien być dobrej jakości.

Jeśli korzystasz z modułu "Google Tag Manager Enhanced Ecommerce" stworzonego przez "Comptoir du code", upewnij się, że masz najnowszą wersję modułu i włącz specjalną opcję do użytku z modułami full page cache.

W każdym razie nie musisz oznaczać modułów Google Tag Manager jako dynamicznych.