Перенос Prestashop на новый сервер, кеширование и Apollo PageBuilder

в настоящее время я немного потерялся или, может быть, у меня просто психическая блокада.

Тема для моего вопроса - 1.7.3.3 Prestashop, который в настоящее время размещен на виртуальном хостинге. Из-за низкой производительности и длительного TTFB я в настоящее время перемещаю его на VPS под управлением Plesk, размещенного на DigitalOcean.

Теперь наступает часть, в которой я немного потерялся: я скопировал файлы через WGET, сбросил базу данных и правильно применил разрешения (насколько мне известно). Магазин без проблем открывается на новом Plesk-Host под новым доменом.

Как только я пытаюсь включить кеширование MySQL, я могу редактировать страницы с помощью Apollo Pagebuilder, но больше не сохранять их. По крайней мере, изменения не отображаются на стойке регистрации. Если я вернусь к файловому кэшу, изменения будут распространяться по назначению, но страница модулей в бэкэнде больше не работает (например, ошибка 500, может быть исправлена ​​путем удаления / app / cache / prod и app / cache / dev)

Итак, чтобы резюмировать мою проблему: если я включу файловый кеш, все, кроме страницы модуля, будет работать, если я включу MySQL-cache, все, кроме распространения Apollo Pagebuilder, будет работать.

Что я уже пробовал:

Я переустановил Apollo PageBuilder, но это, скорее, полностью сломает мой фронт-офис (это означает, что мне придется перестраивать все с нуля, так как текущий статус, похоже, не читается должным образом).

Экспортировал, реимпортировал и "обновил и исправил" Apollo, не удалось :(

Единственное, что приходит мне в голову в качестве решения, - это жертвовать чем-то богам, но я бы не стал этого делать.

Окружающая среда:

Ubuntu 16.04 LTS; Plesk Onyx 17.8.11; Prestashop 1.7.3.3; PHP 7.1.26

Если раньше ни у кого не было этой проблемы, возможно, у кого-то есть идея, что удалить, чтобы просто включить модули в бэк-офисе. Я бы предпочел принять кеширование MySQL как недоступное.

Спасибо заранее за вашу помощь.


person Christian Gätcke    schedule 03.02.2019    source источник


Ответы (1)


Хорошо, думаю, я нашел ответ. Когда сервер, включая кеш, был перенесен, он также кэшировал соединение с базой данных. (К счастью, он не мог писать в предыдущей БД).

Итак, если кто-то столкнется с той же проблемой:

prestaroot / app / cache / prod / appProdProjectContainer.php хранит строки подключения в двух позициях.

После входа: защищенная функция getDoctrine_Dbal_DefaultConnectionService () // ** около строки 670

и один раз около строки 5000. Проще всего было бы просто найти свои предыдущие учетные данные для подключения.

Также вам необходимо убедиться, что в prestaroot / app / cache / prod / appParameters.php существуют те же действительные учетные данные.

Надеюсь, однажды это поможет кому-то.

person Christian Gätcke    schedule 20.02.2019