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 до верхнего предела сервера и исключать таблицы индексов  - это не правильный путь...

Подскажите пожалуйста что такое может быть или что может мешать нормальной работе модуля:

(версия OC 2.3.0.2 orig + используется режим NGINX Fast-CGI, сайт на https. Уже заполнено около 11 тыс. товара )

1) товары добавлять могу - но ... никогда не видел чтобы была видна дата обновления прайса поставщика, всегда вижу только нули 0000-00-00.

Дата всегда почему-то показывалась по нулям что осенью,

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

2) Не могу заменить название производителя Производитель 1 на Производитель 2, хотя в прошлой версии модуля мог менять Производитель 1 на Производитель 2

3) Не могу удалить товар выбранного производителя (раньше мог удалять без проблем)

В логах ошибок - пусто (admin/uploads при этом пусто). 

Где что можно посмотреть ?

Спасибо за ответ, доступы пишу в личку.

Попутно еще несколько вопросов, думаю что пригодятся эти ответы еще для других:

1. Галочка "скрывать цену" у меня в положении OFF - это правильно если я хочу чтобы цена была видна ?

Уточните пожалуйста в каком положении она должна быть чтобы не скрывать цену в сниппете. 

2. Когда-то я передавал цену то ли в H1, и/или возможно в Meta Description или еще где-то.

Сейчас я этого не делаю и цена товара есть только в самой карточке товара.

Достаточно ли этого условия для получения красивого сниппета карточки товара в выдаче Гугла с ценой ?

3. Как сделать проверку структурированных данных - понятно.

Допустим смотрим и проверяем:
https://search.google.com/structured-data/testing-tool?hl=ru#url=https%3A%2F%2Fzabeznal.com%2Fshkaf-19-napolnyj-csv-lite-plus-42u-600h1000-steklo

3. А как и где конкретно увидеть сниппет этого товара который будет выдаваться при наличии разметки ?

Можете показать какой-то ссылкой (чтобы потом туда можно было подставить свой url)?

Подскажите пожалуйста по такой ситуации.

Раньше у меня стоял модуль улучшенных хлебных крошек Breadcumbs ля-ля, точно не помню, но могу найти какой именно был установлен.

И Гугл выдавал нормальную красивую карточку товара с ценой в разметке, цепочкой категории и т.д.

Купил Ваш модуль Microdata PRO v.7 (кажется Вы и устанавливали) на замену модулю Breadcrumb xx

И сейчас вижу что через какое-то время по новому товару разметка карточки товара (Хлебные крошки) в  выдаче Гугла пропала.

1 = было раньше

2 = стало сейчас

Скриншот: https://prnt.sc/mo5q12

При этом тест проверки структуры разметки страниц сайта, в том числе и проверка разметки карточки товара средствами Гугла - проходит нормально.

Вопросы:

1. Что это может быть ?

2. Как вернуть/снова получить красивую разметку в выдаче результатов Гугла ?

3. Как можно проверить или увидеть как будет выглядеть сниппет карточки свежедобавленного товара ?

Ок, сорри.

Тогда уточню вопросы через личку, будем считать что я так не понял Вас...
 

P.S. просто в файле инструкции-документации к данному модулю нет никаких примеров, чтобы можно было понять формат записей для SMART-редиректа и что и как нужно настроить.
А без документации и хотя бы пары примеров что и как - покупка этого модуля ничего такому "новичку, типа меня" не дает  

Задаю вопросы-просьбу через личку.

Купил модуль с желанием получить некую интеллектуальность редиректов измененных ссылок.

На OC 2.3 установил по инструкции два файла:

migrate-2.3.ocmod.zip

FX-migrate.ocmod.xml

Подскажите пожалуйста как настроить функцию Smart (галочка включена):

какие волшебные буковки и цифры нужно прописать в поле DB?

Вот для такого примера:

Имеем проиндексированную Гуглом ранее старую ссылку  _https://zabeznal.com/mfu-a4-ch-b-brother-dcp-1510r

Сейчас этот же товар имеет такую ссылку: _https://zabeznal.com/mfu-a4-ch-b-brother-dcp-1510r-18706

По факту это один и тот же товар, но в текущую url ссылку seo был дописан код товара.

Понятно что могу руками подкорректировать, но хочется smart технологий в редиректе...

Подскажите пожалуйста какие должны быть настройки (записи в DB) чтобы сработала SMART-переадресация модуля

(часть названия товара совпадает) ?

Ну и интересна настройка когда ссылки наоборот: проиндексирована с кодом товара, а сейчас на сайте url - без кода товара.

Спасибо

chukcha, Вы - умница! Большое спасибо, понятно!
Написал сообщение в личку!

Подскажите что может быть и где копать.

В магазине есть товар, товар импортирован из прайса поставщика модулем Обработка прайсов поставщиков.

Товар

- а) ищется в результатах поиска

- б) присутствует и редактируется в админке

Но, при переходе на карточку товара получаю ошибку 404.

Товар есть, и модуль собственной 404й страницы тоже установлен.

Но так как товар де факто есть - модуль кастомизации 404й (Serge Tkach) - не срабатывает

Пробовал менять seo-url чпу - ситуация не меняется.

Понимаю что скорее всего какая-то проблема в БД в полях seo,  или возможно в связанных артикулах SKU (было такое когда импортировал прайс, использовал две колонки актикулов с галочкой связать)

но чем и как можно сейчас такое вылечить - не понимаю.

Таких товаров - несколько штук точно.

Пример карточки товара с проблемой

_https://zabeznal.com/aten-pn0108-ustrojstvo-upravleniya-pitaniem

Товар по слову PN0108 легко ищется и находится поиском на https://zabeznal.com

Товар - удалял, менял seo-url, импортировал заново, проверял на уникальность seo-url ... не помогает.

Есть ли у кого-то какие-то мысли ?

Купил модуль, на оригинальный OpenCart 2.3 с пол-оборта пока этот модуль не установился.

Задал вопросы в личку.

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

Например такое часто бывает с зарубежными артикулами.

Артикулы могут быть похожими по цифрам, но сами товары - близко не совпадают по тому что бы можно было назвать их похожими...

Т.е. хорошо бы добавить галочку задействовать "похожесть" SKU-артикула или нет.

Посмотрите что у Вас еще в robots.txt делается.

Сервер Apache или Nginx ?

Да, содержимое файла sos.tmp меняется (там одна строчка - но видно что товар обновляется)

Видимо пошло по кругу... нажимал F5 (обновить) раз 5-6...

Напомните пожалуйста - кажется можно было поставить куда-то в ячейку прайса слово end

(под последний артикул или под последний товар) - чтобы избежать зацикливания.

Есть/была такая возможность - или эта возможность мне "показалась" ?