Не працює Page Builder в CMS PrestaShop — повчальна казка зі щасливим кінцем
- Головна
- Блог
- Авторська колонка
- Не працює Page Builder в CMS PrestaShop — повчальна казка зі щасливим кінцем
Що робити, якщо магазин під керуванням PrestaShop не відображає візуальний редактор макетів сторінок, відображаючи замість нього якийсь сірий прямокутник?
В деякому царстві (якщо бути точним — біологічний вид людини розумної належить до царства тварин) жив-був купець. Торгував він товаром заморським, жив-поживав, добра наживав.
Одного разу, щоб справа ще краще робилась, покликав купець умільців, щоб інтернет-магазин йому зробили, щоб товари заморські дужче купувалися і продавалися в магазині тім, та добро щоб наживалося швидше. Дюжину ночей і тринадцять днів умільці працювали — зробили купцеві не магазин, а чудо. А щоб купець в цьому магазині міг що завгодно поміняти, від оздоблення до описів товарів заморських, дали чарівний дзвіночок: подзвониш в такий дзвіночок, і враз все хоч догори дном перевернеться, головне — обережно зателефонувати, щоб летящою скринею НЕ забило.
І ось одного разу вирішив купець трохи фасад магазину підправити. Вирішив, що двері нехай посередині будуть, а вікна — з боків. І вивіска нехай нова заодно з логотипом чавунним буде, а то що ж! Подзвонив купець в дзвіночок чарівний, та й каже магазину: «Повернись-но ти, магазин, до мене як треба, зараз фасад тобі міняти будемо!». Заскрипіло щось в магазині, заухало, повернувся він, та якось не тим боком, видать, бо замість фасаду красивого побачив купець тільки стіну бетонну, ні вікон там, ні дверей, ні логотипу чавунного.
Подзвонив купець ще в дзвіночок, поматюкался на магазин, та й вирішив, що треба умільців на допомогу кликати, які магазин йому цей будували. Прийшли умільці, подзвонили в дзвіночок, дивляться — як є стіна бетонна, ні вікон, ні дверей, і нічого з нею не зробиш, навіть слова зовсім коротенького на ній не напишеш. Задумалися, умільці, вирішили, що треба у Баби Яги ради запитати, авось вона що підкаже ...
Для даного сервера була активована опція підтримки по гарантії. Це означає, що адміністрування системи, що забезпечує роботу веб-сайту, знаходиться в нашій сфері відповідальності. О 17:53 службу технічної підтримки надійшов запит, в якому клієнт повідомив про труднощі в роботі веб-сайту на виділеному йому віртуальному сервері. У повідомленні містилося опис проблеми та інформація, яка необхідна для того, щоб мати можливість відтворити ситуацію самостійно.
Симптоматика вказувала на те, що причина неполадки, швидше за все, обумовлена якимись особливостями роботи PrestaShop саме в даному конкретному середовищі. Особливо очевидним це стало, коли ми побачили наступну картину:
Стало ясно, що при запуску Page Builder в браузері у користувача запускається JS-додаток, яке починає досить інтенсивно відправляти запити до сервера, де працює серверна частина програми PrestaShop. Проаналізувавши вміст самих запитів, ми виявили, що запити не надто сильно відрізняються один від одного, при цьому в різні моменти успішно обробляється різна кількість запитів.
Звичайно ж, mod_evasive, що ж ще? Зберігає в оперативній пам'яті кількість запитів до веб-сервера з одного з різних адрес, а якщо кількість запитів перевищує певний межа — на якийсь час (як правило, 10 секунд) вважає IP-адреса, з якого ці запити надходять, потенційним джерелом неприємностей і блокує нові запити з його боку.
І, до речі, немає ж, щоб Apache HTTP Service хоч якісь записи в error.log про це робив, як же, як же ... Тільки ось таке:
[Mon Oct 28 18: 18: 18.130666 2018] [: error] [pid 13666] [client 13.13.13.13:13666] client denied by server configuration: /***/admin***/index.php, referer: https : //***/admin***/index.php? controller = AdminPspagebuilderProfile & token = *** & id_pagebuilderprofile = ***
Ага, denied by server configuration, це в якійсь мірі навіть правда. У конфігурації же є директива підключення цього модуля? Є! Ну так і все. ;-) Але, якщо ви, наприклад, використовуєте таку популярну панель управління як ISPmanager, врахуйте, що mod_evasive включений за замовчуванням, так що, якщо веб-сайт час від часу з якоїсь причини починає відповідати 403-ми помилками, перевірте, чи не підключений такий модуль і у вас.
Можна, наприклад, виконати таку команду:
httpd -M | grep evasive
Загалом, довелося попросити його не заважати. Для цього в файл /etc/httpd/conf.d/mod_evasive.conf (це вірно для CentOS 7 з ISPmanager 5 Lite) довелося внести зміни, а саме — закомментировать (додати значок «#» в початок рядка) наступний рядок:
LoadModule evasive20_module modules / mod_evasive24.so
Потім, правда, вирішили, що це не зовсім елегантно і повернули модуль на місце, змінили значення параметрів DOSPageCount і DOSSiteCount. Щоб зовсім красиво було.
Поворушив купець вітрину по фасаду, двері ширше зробив, та логотип чавунний повісив — ай да краса! Краще ніж раніше, стали продаватися товари заморські, добра ще більше наживати став.