VadimOd

Тоже заинтересовался. Надо будет посмотреть исходники/файлы сайта. А почему поисковики игнорируют ? - думаю что из-за дефиса. Поисковики скорее всего не считают rdr-cache одним целым словом, а считают это составным словом. И rdr - вот эта часть может проигнориоваться как опечатка набора поискового слова/фразы (нет такого смыслового слова в английском), а по "cache" - идет общий поток информации. Версия: Пока могу только высказать предположение что может быть установлен какой-то модуль редиректов. Отсюда и использование сокращения rdr (редирект)

Хороший полезный скрипт. Особенно после восстановления из бекапов. Может есть смысл доработать его чтобы проверял правильность выставленных прав в версиях 2.1, 2.3 и 3.0х? На 2.3.0.2 - не проверяет права на каталоги по причине изменившейся структуры.

Дал ТП хостера восстанавливаться со старых копий. Написали следующее: Импортировал дамп бд за 13-02-2019, сайт отображается корректно, по товарам открывается нормально. Также обнаружил что не получается залогиниться в phpmyadmin, Логи php_ini говорят о проблеме с правами на конфигурационные файлы [25-Oct-2019 02:43:34 Europe/Kiev] phpmyadmin: Failed to load /var/lib/phpmyadmin/blowfish_secret.inc.php Check group www-data has read access and open_basedir restrictions. [25-Oct-2019 02:43:34 Europe/Kiev] phpmyadmin: Failed to load /var/lib/phpmyadmin/config.inc.php Check group www-data has read access and open_basedir restrictions. [25-Oct-2019 02:43:34 Europe/Kiev] phpmyadmin: Failed to load /etc/phpmyadmin/config-db.php Check group www-data has read access and open_basedir restrictions. Удалось исправить ошибки с blowfish_secret.inc.php и config.inc.php, но пока так и не удалось исправить ошибку с правами доступа на config-db.php Владельцем БД магазина - является www-root. Написал им это. Чтобы попробовали восстановить права сперва от имени www-root, а если не получится, то через root, либо смотреть что в бекапах по root. Хотя я в phpMyAdmin могу спокойно зайти как пользователь БД.

Самое интересное что не работают страницы с товарами и страницы категорий. Инфостраницы и новости (через модуль Markimax-a) - работают. Ради интереса откатился на бекап полугодовой давности (файлы + БД (БД восстанавливал после очищения данных в таблицах БД, структура таблиц 0 не менялась) - в общем пока такая же фигня... сайт не работоспособен. Вывод ошибок - включен везде. Пусто, ничего не наблюдаю. Пробовал отключать dreamfilter и некоторые модули, чистил кеши, включал/выключал SeoPro, отключил кеширование шаблона = тоже не помогло... Из интересного замеченного: - если брать из бекапа и копии кеша = то тогда из кеша страницы товаров и категорий открываются как только очищаю кеш - то все... страницы товара и категорий перестают работать. Есть у кого какие-то мысли ?

А нет... эпопея еще не закончилась. Проблема осталась. Последовательность действий: Сделал вечером бекап файлов сайта вручную + утром сделал бекап БД через PHPMyAdmin (более 13,5 тыс товаров). Далее - добавил утром модулем Поставщики (обработка прайс-листов) небольшой прайс на 27 товаров. По логам работы модуля = товар добавился. Новые товары в админке видны. После этого снова начинается вчерашняя картина. Воспроизвожу последовательность: 1) на фронтэнде магазина получил пустой экран категории https://zabeznal.com/officetech/ (хотя до добавления товаров там были утром нормально видны подкатегории) 2) Добавленные новые товары при этом в админке видны нормально (уничтожители документов и счетчики банкнот) Смотрю на лог ошибок магазина - на эту тему чисто. (Там идет только ругань на то что в контактной форме не может отработать гугловская рекапча) 3) Прописал товарам теги H1 и пр. 4) Проиндексировал/добавил новые (27 шт) товары в поисковый модулем "Поисковая система .... 5) Проверил поиском например по слову "уничтожитель" - новые товары видно что есть и находятся - список найденного выводится. А вот попытка открыть карточку нового товара = получаем пустую страницу. И вот тут уже снова повторяются грабли: 6) Очистил кеш данных. Очистил кеш шаблона NewStore 7) = страницы сайта снова стали пустые... В логе ошибок появилось следующее: 2019-10-23 12:21:05 - records_total = 13577 2019-10-23 12:21:18 - records_total = 13577 2019-10-23 12:21:34 - records_total = 13577 2019-10-23 12:21:55 - records_total = 13577 2019-10-23 12:22:10 - records_total = 1 2019-10-23 12:22:12 - records_total = 1 2019-10-23 12:22:12 - records_total = 1 2019-10-23 12:22:15 - records_total = 1 2019-10-23 12:22:27 - records_total = 0 2019-10-23 12:23:18 - PHP Notice: Undefined index: more in /var/www/www-root/data/www/zabeznal.com/system/storage/modification/admin/view/template/extension/module/search_suggestion.tpl on line 553 2019-10-23 12:23:18 - PHP Notice: Undefined index: more in /var/www/www-root/data/www/zabeznal.com/system/storage/modification/admin/view/template/extension/module/search_suggestion.tpl on line 771 2019-10-23 12:23:18 - PHP Notice: Undefined index: more in /var/www/www-root/data/www/zabeznal.com/system/storage/modification/admin/view/template/extension/module/search_suggestion.tpl on line 974 Восстанавливаю БД с бекапа (sql = 121Мб) Получил сообщение в phpMyAdmin = 413 Request Entity Too Large Гуглю: https://my.vdswin.com/knowledgebase.php?action=displayarticle&id=27 Меняем параметр в client_max_body_size на 128M После восстановления БД с копии - сайт уже оживает. Играюсь дальше... буду вычислять проблему и смотреть что происходит по шагам

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

zabeznal.com.error.log вообще пустой или на каком уровне надо смотреть?

ЧПУ выключал = не помогло. Страница товара без ЧПУ - тоже не отрабатывается/не отображается.

Споймал странную ситуацию - не смог отследить во-время что повлияло... Недавние сегодняшние действия: 1. Добавлялся товар через модуль поставщиков + добавилась новая категория товара. Не увидел созданную новую подкатегорию. Странно, полез смотреть + решил проверить-оптимизировать таблицы БД (давно не делал). 2. Сделал перезапуск сервера (обновлялось ядро + ставились рекомендуемые патчи) 3. Почистил кеши, обновил модификаторы... Не помогло. Включал-выключал кеширование - думал что-то сбилось... Имею ИТОГО: Перестал нормально работать сайт при переходе на товар = не отображается страница товара, при этом главная страница сайта отрабатывает нормально также не отображаются страницы категорий. Сайт: https://zabeznal.com Чистил кеши, обновлял модификаторы, оптимизировал таблицы БД, поотключал некоторое кеширование … не помогло. Смотрим на главную - сайт работает (и рано утром еще работал нормально полноценно - приходил заказ). А сейчас = не могу понять что произошло... По глупости обнулил лог ошибок после обновления модификаторов - пытаюсь отследить что случилось. Пока в логе чисто. У кого какие мысли что могло произойти, куда смотреть? Есть у меня подозрение что сбилось то ли seo-pro, то ли переадресация с http на https. Как проверить, что передернуть?

Тоже переносил сайт-магазин (2.3) с одного сервера/хостера на другой. Копирование файлов + дамп БД и разворачивание дампа обратно. Последовательность была такова: 1. Дамп БД со старого сайта-сервера. 2. Создал вначале аналогичную БД (пользователь/пароль) на новом сервере. 3. Потом скопировал файлы/папки 4. Потом импортировал дамп БД Сайт-магазин визуально заработал. Заказы идут... Думаю - все хорошо... Но... сегодня захотел установить один новый модуль и получаю ошибку Error. LocalMode FIX - установлен, проверил, отключил/включил - попытался установить тот модификатор - снова получаю при попытке инсталляции просто фразу Error и соответственно модуль не установился. Дай, думаю, попробую установить другой модуль - получаю снова Error. В том, что проблема не в тех модулях что хотел установить - уверен на 100%. Так как эти же модули работают в другом магазине на той же версии движка OC 2.3. В логе OC Ошибок что в админке - пусто. Вопросы: 1. Что не учел при переезде ? 2. Какие логи и где примерно по серверу смотреть ?

Есть просьба, опишу ситуацию с которой столкнулся. 1. Возможно ли учесть в следующей версии поисковой системы следующее... В IT-сфере очень часто приходится работать с артикулом производителя - SKU Особенность данного модуля, (и подозреваю что и модуля морфологического релевантного поиска тоже) является то, что автор модуля использует разбивку выражений где есть префикс (дефис) на несколько составляющих, а именно если у Вас пишется патч-корд - то будет идти разбивка на два слова: "патч" и "корд" Ладно когда это слова. Но имеем например такой артикул производителя: WZ-LZ16-60-00-000/C20 Поучаем что в этом случае идет разбивка на части потом поиск по уже разбитым словам, потом дальше основывается на логике И или ИЛИ формируются результаты поиска. Это все - иногда "лишние" запросы к БД. Было бы здорово если бы можно было в настройках модуля настраивать в каких полях делать "разбивку на слова" а в каких - не делать. например в названии товара, описании товара, атрибутах - делать, а в артикуле SKU - не делать… 2. И еще пожелание по дальнейшей интеллектуальности поисковых модулей. Есть поле для пользовательской таблицы подмены слов в поиске. Ок, неплохо. Но если бы еще сделать вкладку для поля "синонимов" слов для поиска - было бы вообще замечательно. Вот возможные примеры для пользовательской таблицы "синонимов" 1024Mb <=> 1Gb 1Tb <=> 1000Gb 4Gb <=> 4096Mb white <=> белый настенный <=> навесной

100napb, спасибо, напишу в личку. Общий текущий объем БД = 223Мб, 3,6 млн. строк Из них: Объем таблицы search_word = 20,7Мб (278 тыс строк) Объем таблицы search_word_to_product = 95,7Мб (3 млн. строк) Что касается записи Schedule Backup Interval: 2 min(Test) - то это не правильный перевод. Там имеется ввиду тестовый одноразовый запуск бекапа через 2 минуты = чисто для проверки работы бекапирования.

Otvet, а подскажите тогда как еще в такой способ записать команду чтобы исключить из бекапа пару таблиц (для примера)

Может кому-то из начинающих пригодится. Немного попробовав разные модули бекапов для OpenCart понял для себя следующее: Для небольших магазинов возможно будет достаточно бесплатного модуля бекапа БД типа Accu AutoBackup https://www.opencart.com/index.php?route=marketplace/extension/info&extension_id=33125 А вот для магазинов где много товаров, много записей и т.д. - там есть смысл использовать модули, в которых можно указывать и выбирать для бекапа не все поля из таблиц БД (например не тянуть индексы, которые всегда можно перестроить) например есть вот такой модуль: Backup/Restore Plus (порядка 25 дол) https://www.opencart.com/index.php?route=marketplace/extension/info&extension_id=26326 или такой: Backup Pro for Opencart 2.x (порядка 25 дол) https://www.opencart.com/index.php?route=marketplace/extension/info&amp;extension_id=19334 Некоторые модули конечно еще хороши тем что предлагают делать бекапы на Google Drive или в Dropbox, но часто у них не получается хорошо отработать задачу в силу того что БД имеет несколько больших таблиц из индексов и скрипт бекапа, запускаемый через php, - подвисает из-за нехватки ресурсов на сервере.

Установлена поисковая система с морфологией + поиск с вариантами (замена быстрого Ajax поиска от автора) + еще модуль подбора похожих товаров MR с доработкой на основе результатов этой поисковой системы Количество товара - около 11 тыс. Будет еще примерно столько же. Так как у меня много товара которые имеют значимые 2 символа (WD, FO и т.д.) - то поставил минимальное количество в названии товара 2 символа, в описании - используется минимум 3 символа (нужно чтобы искались HDD, SDD, LCD и пр.) Эксперементировал с вариантами поисковой выдачи, и мне больше понравилась логика И чем ИЛИ. При логике ИЛИ у меня получалось в выдаче больше количество найденных товаров несоответствующих ожиданию пользователя. Сервер на VPS, NGINX + FastCGI, 4Гб ОЗУ, 2 ядра Стояло значение в настройках memory_limit=1024Mb Столкнулся с такими ситуациями (через некоторое время только заметил): 1. Не хочет создаваться штатным способом копия БД через Настройки - Инструменты - Импорт/экспорт. Не хватает ресурсов... Опытным путем выяснил что штатным способом бекап БД может создаться только когда снимаю галочки с таблиц oc_search_word, oc_search_word_to_product 2. Стоит и прекрасно ранее работал модуль автоматических бекапов Accu AutoBackup Заметил что тоже перестали им создаваться копии БД. Начали с хостером разбираться почему перестало работать бекапирование данным модулем... При общении с ТП хостера была выявлена следующая ситуация: При попытке запустить скрипт из под браузера возникала ошибка "Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 43 bytes)", что указывает на недостаточный объём выделяемой памяти для PHP-скрипта. Выполнили увеличение значения memory_limit с 1024 до 4096, после чего скрипт успешно отработал и соответствующий архив появился в списке архивов модуля, так же скрипт успешно отработал из-под командной строки. Однако при настройках "Backup type: auto" и "Schedule Backup Interval: 2 min(Test)" резервная копия не создаётся. Конечно остается вариант запускать бекап через крон с командной строки или не включать индексные таблицы. НО... Возникает вопрос: Какие типовые настройки для оптимизации работы и запросов MySQL Вы можете порекомендовать ? Мне кажется что просто тупо увеличивать memory_limit до верхнего предела сервера и исключать таблицы индексов - это не правильный путь...