
How can we help you?
Some of our questions and answers
This is a short list of some questions and answers. Type one or more keywords above to find what your are looking for.
Jestem freelancerem we Francji, więc jako bardzo mała firma nie płacę podatku VAT (art. 293 B francuskiego prawa podatkowego). Jeśli sprawdzisz cenę, zobaczysz, że nie ma w niej VAT-u ani podatku. Dlatego też nie posiadam żadnego numeru identyfikacji podatkowej ani numeru VAT.
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.
All our modules can run on LiteSpeed Web Server since it supports the Apache .htaccess file.
However, the HTML cache feature (Page Cache Ultimate) is not compatible with the LiteSpeed Cache Plugin since they are both working on the same layer of cache.
Which one should you choose?
LiteSpeed Cache is a generic cache which does not handle all different contexts of Prestashop. Which taxes are applied? Is there a flash sale comming up? Should I display a different content for this user because he belongs to a specific user group? Did this visitor accept cookies? etc.
Page Cache Ultimate has been created for Prestashop and it is only dedicated to this platform, it handles all different contexts and can also upgrade fast if a new Prestashop feature is out.
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
Fakturę znajdziesz na swoim koncie JPresta w menu "Historia i szczegóły zamówienia".
Jeśli jej nie widzisz upewnij się, że zarejestrowałeś adres na swoim koncie, aby faktura mogła zostać wygenerowana.
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.
Jeśli po zainstalowaniu modułu przestały się wyświetlać niektóre obrazki w Twoim sklepie, np. logo, obrazki na stronach CMS, obrazki na zapleczu itp. to przyczyną jest plik .htaccess w katalogu /img. Ten plik blokuje każdy skrypt PHP, nawet jeśli jest to przekierowanie (skrypt tak naprawdę nie znajduje się w tym katalogu).
Aby naprawić ten problem należy zmienić nazwę pliku /img/.htaccess na /img/.htaccess.off
Modyfikacje wykonane w module, w motywie, w CSS lub w Javascript nie mogą być automatycznie wykryte, więc musisz wyczyścić pamięć podręczną, aby zobaczyć zmiany.
Istnieją 3 sposoby, aby wyczyścić pamięć podręczną
- W konfiguracji modułu "Page Cache Ultimate", przejdź do menu "Statystyki". Możesz filtrować strony, których dotyczą Twoje modyfikacje. Następnie kliknij przycisk "Wyczyść pamięć podręczną" na dole tabeli.
- Kliknij przycisk "Wyczyść pamięć podręczną" w konfiguracji modułu "Page Cache Ultimate" na górze i po prawej stronie ekranu, spowoduje to wyczyszczenie pamięci podręcznej wszystkich stron.
- Użyj adresu URL, który znajdziesz w menu "API" w konfiguracji modułu "Page Cache Ultimate"
W konfiguracji koszyka, w sekcji "Akcja dodawania do koszyka" wyłącz opcję "Otwórz koszyk".
Jeśli używasz modułu "SuperTinyMCE PRO" stworzonego przez Liewebs to musisz dodać wyjątek w konfiguracji tego modułu dla kontrolera "JprestaThemeConfiguratorLive". Upewnij się również, że posiadasz co najmniej wersję 1.2.2 modułu "JPresta - Theme Configurator".
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.
Unable to get cache-warmer informations from the shop (maybe the module is disabled or uninstalled): Read timed out
Jeśli widzisz ten błąd w logu cache-wamer, oznacza to, że jest timeout, kiedy cache-warmer pobiera strony, aby się rozgrzać. Aby uniknąć tego timeoutu, w konfiguracji Page Cache Ultimate, kliknij na "Tryb zaawansowany", a następnie w menu na "Opcje" i ustaw niższą wartość dla "Maksymalnego czasu wykonania w sekundach".
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']; }
Czas trwania rozgrzewki zależy od 3 czynników:
- Liczba stron do wygenerowania: pierwsze rozgrzewki zazwyczaj zawierają dużo stron, co jest normalne, a liczba ta będzie się zmniejszać wraz z postępem rozgrzewek
- Maksymalna liczba zdefiniowanych botów: domyślnie jest to 30, ale można ją zmniejszyć do 5 botów, aby zmniejszyć obciążenie serwera, ale oczywiście wydłuży to czas potrzebny na każdą rozgrzewkę
- TTFB stron bez pamięci podręcznej: jeśli czas odpowiedzi serwera jest długi bez pamięci podręcznej (> 3 s), może być konieczne przeanalizowanie powolności Prestashop
Boty Cache-Warmer są prawdopodobnie uważane za boty SPAM przez dostawcę usług hostingowych. Aby to zadziałało, musisz wskazać w ustawieniach swojego dostawcy hostingu, że agent użytkownika "JPresta-Cache-Warmer" jest dozwolony.
W porównaniu do liczby produktów i kategorii, które posiadasz, nie sądziłeś, że będziesz miał tak wiele stron do wygenerowania, i to jest normalne!
Cache-warmer wygeneruje strony Twojego sklepu Prestashop w różnych kontekstach. Na przykład, będziesz mieć jeden kontekst dla telefonów komórkowych, inny dla komputerów, jeden dla odwiedzających, a inny dla połączonych klientów itp.
Tak więc liczba stron jest mnożona przez liczbę kontekstów.
Jeśli subskrypcja obejmuje tylko jedną rozgrzewkę, to tak, można określić czas rozgrzewki.
Jeśli pakiet subskrypcji obejmuje kilka rozgrzewek, można określić czas rozpoczęcia pierwszej rozgrzewki, a kolejne będą uruchamiane w regularnych odstępach czasu.
JPresta-Cache-Warmer korzysta z serwerów Amazon (AWS), aby zapewnić stabilną i wydajną usługę niezależnie od liczby abonentów.
Jeśli chcesz, aby Twój dostawca hostingu nie blokował robotów podgrzewających pamięć podręczną, musisz autoryzować żądania z następujących IPS: 18.119.72.109 i 18.189.172.189
Podczas korzystania z natywnych statystyk Prestashop, aby uniknąć uwzględnienia cache-warmera w statystykach, wystarczy dodać to nadpisanie w /override/classes/Connection.php:
class Connection extends ConnectionCore
{
public static function setNewConnection($cookie)
{
if (isset($_SERVER['HTTP_USER_AGENT'])
&& preg_match('/JPresta-Cache-Warmer/i', $_SERVER['HTTP_USER_AGENT'])) {
// To jest cache-warmer: nie rejestruj połączenia
return false;
}
return parent::setNewConnection($cookie);
}
}
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).