Всем привет. Специалисты, по Search API, скажите:
А как в в индекс автоматически включать новые элементы? По крону например.
В D7 вроде можно было как-то.
А как в Search API Автоматически включать в индекс новые элементы?
Главные вкладки
Лучший ответ
1
Итак правильный вопрос был: Как заставить Search API работать с эмодзи.
А правильный ответ тут:
https://www.drupal.org/project/search_api/issues/3060442
Комментарии
"Элементы" - это новый контент? Так вроде сами автоматически включаются. По умолчанию - при очередном запуске cron, если нужно быстрее - в настройках конкретного индекса, в самом низу, под INDEX OPTIONS можно включить Index items immediately.
Если не включаются даже по cron - надо разбираться почему. Если не показываются во вьюхе - надо в продвинутых настройках вьюхи поменять настройку Caching на Search API (tag-based).
Проиндесировал элементы
admin/config/search/search-api/index/search_index
Index status 100%
Добавил несколько статей на сайт
Index status 99%
Запустил крон.
Index status 99% (все равно).
Index items immediately - ВКЛ.
В журнале нет ошибок, что что-то не удалось проиндексировать?
Если в настройках индекса зпасукать индексирование - вроде индексирует все что нужно.
После запуска крона такое предупреждение в журнале:
SQLSTATE[HY000]: General error: 1366 Incorrect string value: '\xF0\x9F\x93\x8B \xC2...' for column 'body' at row 1: INSERT INTO "search_api_db_search_index" ("body", "body_1", "category_name", "category_name_fulltext", "created", "field_full_name", "field_full_name_fulltext", "field_my_icon", "field_text", "tag", "tag_fulltext", "title", "type", "search_api_datasource", "search_api_language", "item_id") VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9, :db_insert_placeholder_10, :db_insert_placeholder_11, :db_insert_placeholder_12, :db_insert_placeholder_13, :db_insert_placeholder_14, :db_insert_placeholder_15); Array ( [:db_insert_placeholder_0] => 📋 Полное имя: Френки де Йонг [:db_insert_placeholder_1] => [:db_insert_placeholder_2] => Полузащитники [:db_insert_placeholder_3] => Полузащитники [:db_insert_placeholder_4] => 1512177839 [:db_insert_placeholder_5] => [:db_insert_placeholder_6] => [:db_insert_placeholder_7] => [:db_insert_placeholder_8] => [:db_insert_placeholder_9] => [:db_insert_placeholder_10] => [:db_insert_placeholder_11] => 21 Френки де Йонг [:db_insert_placeholder_12] => page [:db_insert_placeholder_13] => entity:node [:db_insert_placeholder_14] => ru [:db_insert_placeholder_15] => entity:node/170:ru )
А кодировка базы данных какая? База данных явно не приемлет расширенные символы типа клипборда в строке "📋 Полное имя: Френки де Йонг". С другой стороны, а как этот символ изначально оказался в БД? Возможно разные кодировки для разных таблиц/полей?
Как выяснилось у меня под Docker4Drupal такой проблемы нет. А на продакшене - есть.
Кодировка базы.
+------------------------+-------+
| Variable_name | Value |
+------------------------+-------+
| character_set_database | utf8 |
+------------------------+-------+
"Возможно разные кодировки для разных таблиц/полей?" - как проверить?
Я сразу скажу, что я в этой теме не настоящий сварщик, наверняка другие смогут объяснить более корректно. Но насколько я понимаю, кодировка utf8, она же utf8mb3, позволяет хранить в базе символы размером до 3 байт. Сюда влезают буквы практически всех живых языков этой планеты, но не влезает всякая новомодная подростковая хрень типа смайликов, букетиков и прочих клипбордиков. Если в базе непременно нужно хранить эту подростковую хрень, то кодировка должна быть utf8mb4. Тогда нет смысла разбираться с кодировкой отдельных таблиц и полей, а нужно просто всю базу конвертнуть в utf8mb4.
Тут одно из двух, либо на продакшене не та кодировка базы, либо туда залили дамп не в той кодировке. Такое бывает, что обе базы в utf8mv4, но при экспорте выбирают обычную кодировку и потом всё ломается
Значит так.
На сервере у БД показывало COLLATE utf8_unicode_ci. Хотя у большинства таблиц в ней utf8mb4_general_ci.
Выполнил
Query OK, 1 row affected (0,00 sec)
Все так же не получается проиндексировать все содержимое. Ошибка выше - сохраняется.
В settings.php что-то прописывать?
Почему-то в консоли показывает одну кодировку.
+------------------------+-------+
| Variable_name | Value |
+------------------------+-------+
| character_set_database | utf8 |
+------------------------+-------+
А phpmyadmin другую:
Казалось бы - при чем тут COLLATE (сортировка)? Сharacter set и collation - это разные вещи... COLLATE - это всего лишь правила сортировки, от их замены при той же кодировке база данных не научится хранить четырехбайтовые символы. Нужно
ALTER DATABASE barcamania_d9prod CHARACTER SET utf8mb4;
Естественно сделав свежий бэкап.
Когда делаешь такие вещи, желательно всё же потратить время на то, чтобы понять что именно ты делаешь. Бездумные копипасты команд из случайных источников могут привести к катастрофическим результатам...
Да, я пробовал так.
ERROR 1115 (42000): Unknown character set: 'utf8mb4_general_ci'
Потом так.
Query OK, 1 row affected (0,02 sec)
Но все равно сохраняются ошибки при индексировании статей с эмодзи.
а если эту ноду открыть на редактирование и сохранить, ошибка есть?
Открыл-сохранил не вижу ошибку. Только та что парой коментов выше в журнале возникает.
А после сохранения получилось переиндексировать?
Насколько я понимаю ALTER DATABASE ... CHARACTER SET всего лишь меняет кодировку по умолчанию для новых таблиц, которые будут создаваться в этой БД. Для перекодировки существующих данных надо в явном виде конвертировать все таблицы и текстовые поля, в которых могут содержаться расширенные символы.
Большинство таблиц в БД имеют кодировку utf8mb4_general_ci
Но на сервере некоторые таблицы (отсортировано по кодировке):
А когда БД идет ко мне на ПК, то:
Поразмышляв понял, что 2й раз поставил задачу неправильно.
https://www.barcamania.com/riki-puch - из эмодзи представленых тут, только некоторые позволяют вносить статью в индекс. Другие же приводят к ошибке индексирования. И на сервере и на моем ПК.
https://www.drupal.org/project/search_api/issues/3060442 - вроде тут похожая проблема. Прислушиваться советов, как считаете?
utf8 и utf8mb3 - это одно и то же, так что принципиальной разницы между девом и продом тут нет.
То, что основные таблицы в кодировке utf8mb4, а таблицы search_api в utf8mb3, полностью объясняет тот факт, что все эмодзи прекрасно хранятся в контенте и вызывают ошибки только при попытке занести их в индекс.
Естественно, потому что некоторые эмодзи вписываются в три байта и utf8mb3, а некоторые - нет.
Да, похоже что Search API принудительно переводит свои таблицы в utf8mb3, так что патч, возможно, поможет.
Самое смешное, что если бы сайт был спроектирован не через жопу, а по уму, то этой проблемы бы и не возникло, так как все эти эмодзики по сути не являются контентом, а являются декорацией лейблов полей. Если бы все эти "Полное имя", "Дата рождения" и т.п. были бы оформлены как отдельные поля Друпала, то никакие эмодзики в индекс и не попали бы. Но какой-то гений захерачил всё это в body. Похоже, чел ранее работал с вордпрессом или битриксом, его спросили "а на друпале сможешь?", и он "смог"!
Патч помог. После этого требуется переустановка модуля.
Я не понимаю: почему search_api формирует свои таблицы в кодировке отличной от БД всего сайта?
Насчет проектирования сайта. Мне не сложно сделать тип материала Человек с полями для которых как-то подцепить значки. Но такой задачи пока не было.
Тут проблема, что сайт с претензией на социальную сеть. И если из авторов кто-то эмодзи в текст добавит, страница в индекс не пойдет.
Можно написать свой процессор, который повырезает все эти штуки перед индексом.
Итак правильный вопрос был: Как заставить Search API работать с эмодзи.
А правильный ответ тут:
https://www.drupal.org/project/search_api/issues/3060442
Чтобы автоматически включать новые элементы в индекс в Search API, вам потребуется настроить сервер и индекс с нужными настройками, а затем создать обработчик контента, который указывает, какой контент должен быть включен в индекс.
Вот шаги, которые вы можете выполнить, чтобы настроить это:
Теперь, когда на вашем сайте создается или обновляется новый контент, он должен автоматически включаться в индекс. Вы также можете использовать кнопку «Индексировать сейчас» на странице «Индексировать», чтобы переиндексировать все содержимое вашего сайта в любое время.