SearchWP WP Document Revisions Integration - Плагин WordPress

Руководство по настройке SearchWP WP Document Revisions Integration для поиска по документам

SearchWP WP Document Revisions Integration нужен не для того, чтобы заменить систему хранения документов, а для того, чтобы связать две разные части сайта: библиотеку документов WP Document Revisions и поисковый индекс SearchWP. В этом руководстве разберём, как подготовить сайт, включить интеграцию, добавить правильный источник и атрибут в алгоритм поиска, выполнить переиндексацию и проверить, что посетитель находит документ по словам из файла, а не только по заголовку записи.

Материал рассчитан на ситуацию, когда WP Document Revisions уже используется как внутренний или публичный архив файлов: регламенты, инструкции, договоры, формы, технические паспорта, методички, протоколы, презентации. Главная ценность интеграции в том, что SearchWP получает текст из последней ревизии документа и может учитывать его при ранжировании. Поэтому настройка здесь отличается от обычного добавления нового поискового плагина: важно понимать, где лежит файл, какая ревизия считается актуальной, какой custom field индексируется и как не показать в выдаче лишнее.

Дальше будет не рекламный обзор, а практическая инструкция. Мы отдельно пройдём подготовку, установку, карту настроек SearchWP, рабочий пример для библиотеки документов, проверку результата, типичные ошибки, ограничения по файлам и похожие решения. Там, где точных подтверждений в источниках нет, рекомендации сформулированы осторожно: лучше проверить поведение на копии сайта, чем обещать универсальный результат для любой темы, роли пользователя и хостинга.

Какую задачу решает интеграция и где она особенно полезна

Обычный поиск WordPress хорошо справляется с простыми записями, но плохо подходит для сайта, где ценная информация хранится внутри файлов. Если на странице документа есть только заголовок вроде "Политика обработки данных", а важные термины находятся в PDF или DOCX, стандартная выдача может не найти нужный материал. SearchWP умеет строить собственный индекс и учитывать разные источники, но связка с WP Document Revisions требует отдельного моста: документ в этой системе является записью WordPress, а актуальный файл живёт как ревизия, привязанная к документу.

SearchWP WP Document Revisions Integration закрывает именно этот разрыв. По официальной документации расширение получает файл из последней ревизии документа, извлекает текст, сохраняет его в псевдо custom field с ключом swp_wp_document_revision и позволяет SearchWP индексировать это поле как обычный атрибут источника. Для владельца сайта это означает, что настройка поиска переносится из области "показывать документы по названию" в область "искать по реальному содержимому актуального файла".

Лучший сценарий для расширения - документальная библиотека, где пользователи ищут конкретные термины внутри файлов. Это может быть база инструкций для сотрудников, раздел с технической документацией, образовательный портал, юридический архив, библиотека шаблонов договоров, каталог внутренних регламентов или раздел поддержки с файлами для клиентов. В таких проектах пользователь редко помнит точное название документа. Он вводит фрагмент требования, номер формы, название процедуры, термин из спецификации или фразу из инструкции.

Кому расширение подходит

Интеграция будет полезна администраторам и разработчикам WordPress-сайтов, где одновременно выполнены три условия: SearchWP уже выбран как основной поисковый движок, WP Document Revisions используется как система управления документами, а содержимое файлов важнее, чем простые метаданные записи. Особенно хорошо расширение вписывается в сайты, где документы регулярно обновляются: пользователь должен находить актуальную версию, а не случайную старую копию.

Расширение также подходит редакциям и внутренним командам, где документ проходит через статусы и версии. WP Document Revisions умеет хранить ревизии, владельца, видимость и историю изменений. SearchWP, в свою очередь, отвечает за индекс и релевантность. Такая связка удобнее, чем попытка вручную копировать текст каждого файла в описание документа, потому что ручное копирование быстро устаревает после очередной загрузки новой версии.

Кому может не подойти

Интеграция может быть лишней, если документы не ведутся через WP Document Revisions. Например, если все PDF загружены как обычные файлы в медиабиблиотеку и не имеют истории ревизий, часто достаточно настроить в SearchWP источник Media и атрибут Document Content. Если нужна внешняя поисковая инфраструктура для очень большого архива, стоит заранее оценить специализированные решения, потому что официальный FAQ SearchWP осторожно рекомендует плагин в первую очередь для сайтов малого и среднего размера, а не для каталогов с десятками или сотнями тысяч объектов.

Отдельная ситуация - файлы, в которых нет извлекаемого текста. Если PDF является сканом без распознавания текста, поисковый движок не сможет прочитать его содержимое так же, как человек не может выделить текст мышью внутри изображения. В этом случае сначала нужен процесс распознавания текста или нормальная текстовая версия документа. Интеграция не превращает картинку в текст и не заменяет подготовку самих файлов.

Что проверить перед установкой на рабочий сайт

Перед установкой важно не торопиться. Интеграция работает на пересечении поиска, файлов, ревизий, прав доступа и производительности. Ошибка в одном месте может выглядеть как "плагин не ищет", хотя на деле причина в неиндексируемом PDF, неверном источнике алгоритма, старом индексе, закрытом файле или сломанном пути после миграции.

Проверка лицензии и состава плагинов

Официальная страница SearchWP указывает, что расширение требует Pro-лицензию. В статье не нужно разбирать покупку или активацию лицензии, но перед технической настройкой стоит убедиться, что у вас есть рабочий SearchWP, активный WP Document Revisions и доступ к расширениям в вашей учетной записи SearchWP. Если SearchWP не установлен, интеграция не даст отдельной поисковой страницы сама по себе. Если WP Document Revisions не установлен, ей нечего индексировать.

Проверьте, что в админ-панели есть меню документов WP Document Revisions и что там уже можно создать или открыть документ. Для нового проекта сначала настройте саму библиотеку документов: статусы, видимость, владельцев, права, структуру URL и место загрузки файлов. Только после этого имеет смысл настраивать SearchWP, иначе вы будете индексировать неполную или тестовую структуру.

Проверка файлов и текстового слоя

SearchWP может извлекать текст из поддерживаемых документов, но источники прямо предупреждают: для PDF важен настоящий текстовый слой. Простой тест - открыть файл в обычном просмотрщике и попробовать выделить фразу мышью. Если выделяется только картинка или выделить ничего нельзя, поиск по словам из такого файла, скорее всего, не сработает без распознавания текста.

Для офисных документов и текстовых форматов также полезно проверить размер, кодировку, парольную защиту и реальные права доступа к файлу. Зашифрованные, повреждённые или нестандартно сохранённые документы могут плохо обрабатываться. Не делайте вывод по одному удачному файлу: возьмите несколько типичных документов из вашей библиотеки, включая длинный PDF, короткую инструкцию, офисный файл и файл с кириллицей.

Проверка места хранения и прав доступа

WP Document Revisions может хранить документы так, чтобы доступ к ним проходил через механизмы WordPress, а не через прямую ссылку на файл. В FAQ плагина описаны уровни видимости: private, password protected и public. Там же отмечено, что имена файлов хэшируются, а папку документов можно вынести за пределы публичного корня сайта. Это полезно для безопасности, но требует аккуратной проверки после миграций и смены хостинга.

Перед индексацией проверьте не только поиск, но и доступ к самому документу. Если файл уже не открывается по постоянной ссылке WP Document Revisions, SearchWP не должен быть первой точкой диагностики. Сначала восстановите путь, права на папки, запись attachment ID и постоянные ссылки.

Проверка тестовой среды и резервной копии

Переиндексация может нагружать сервер, особенно если библиотека большая или документы тяжёлые. Лучший порядок - сначала копия сайта или временное окно с низкой посещаемостью, затем ограниченный набор документов, затем полный индекс. Для сайта с внутренними документами дополнительно проверьте выдачу под разными ролями: администратор, редактор, автор, обычный вошедший пользователь и гость.

Если на сайте стоят плагины очистки базы данных, внимательно проверьте, не удаляют ли они ревизии документов. В support-форумах WP Document Revisions есть пример, где журнал ревизий исчез после очистки post revisions сторонним оптимизатором. Для SearchWP это критично: если документальная история повреждена, интеграция может получить не тот файл или вообще не найти корректную привязку.

Установка и первичная проверка без лишнего риска

Технически установка похожа на обычное включение расширения WordPress, но логика проверки отличается. Важен не сам факт, что пункт появился в списке плагинов, а то, что SearchWP увидел источник документов и может прочитать поле, которое добавляет интеграция.

Рекомендуемый порядок включения

Начните с базовых зависимостей. Сначала убедитесь, что WP Document Revisions активен и в нём есть хотя бы один тестовый документ с файлом. Затем проверьте, что SearchWP активен, открывается раздел SearchWP и доступна страница Algorithm. После этого включайте SearchWP WP Document Revisions Integration. Такой порядок помогает отделить ошибки библиотеки документов от ошибок алгоритма поиска.

1. Создайте или выберите тестовый документ в Documents с понятным названием и файлом, где есть уникальная фраза.
2. Откройте документ по постоянной ссылке и убедитесь, что скачивается или показывается последняя версия файла.
3. Проверьте, что SearchWP открывает настройки алгоритма без ошибок и видит пользовательские типы записей.
4. Активируйте расширение интеграции через стандартный экран плагинов или через доступный вам механизм установки расширений SearchWP.
5. Не запускайте сразу полный reindex, пока не добавлен источник и атрибут документа в алгоритм.

После включения расширения не ждите отдельной публичной формы или нового раздела настроек с большим количеством параметров. Официальная документация описывает настройку через алгоритм SearchWP: нужно включить тип записей документов как источник и добавить custom field swp_wp_document_revision. То есть основная работа происходит внутри поискового движка, а не внутри WP Document Revisions.

Мини-проверка после активации

На этом этапе задача простая: убедиться, что ничего не сломалось. Откройте список документов, страницу редактирования тестового документа, постоянную ссылку документа и страницу SearchWP Algorithm. Если после активации появляются ошибки PHP, пустые экраны, пропадает загрузка файлов или перестаёт открываться медиабиблиотека, сначала разберите конфликт на тестовом сайте. Не переходите к полной индексации, пока базовые экраны работают нестабильно.

Хороший признак - в SearchWP можно открыть источник документов и добавить custom field. Плохой признак - тип документа отсутствует в источниках, а поле не удаётся добавить даже вручную. В такой ситуации проверьте, активен ли сам WP Document Revisions, не отключён ли пользовательский тип записей документами другой доработкой и нет ли ограничений у текущей роли администратора.

Карта настройки SearchWP после активации расширения

Главная настройка выполняется в алгоритме SearchWP. В официальной документации указано: нужно перейти в SearchWP -> Algorithm, отредактировать конфигурацию движка, включить тип записи документа как источник, добавить custom field swp_wp_document_revision и выполнить полный reindex. Этот блок стоит пройти внимательно, потому что большинство ошибок поиска по документам сводится к пропущенному источнику, неправильному весу или старому индексу.

Источник документов

В SearchWP движок состоит из Sources и Attributes. Source - это тип индексируемого контента: записи, страницы, медиаданные, пользователи или пользовательский тип записей. Документы WP Document Revisions обычно представлены отдельным типом записей, часто с логикой document. В вашем интерфейсе название может отображаться человеко-понятно, но смысл остаётся тем же: SearchWP должен получить право учитывать эти документы в конкретном поисковом движке.

Если вы используете стандартный поиск сайта, настройка обычно относится к Default Engine, потому что он перехватывает нативные запросы WordPress. Если же документы нужны только в отдельной базе знаний или внутреннем разделе, может быть удобнее создать дополнительный движок и подключить его к отдельной форме или шаблону результатов. Это снижает риск, что служебные документы начнут смешиваться с обычными статьями блога.

Атрибут custom field

После добавления источника нужно открыть атрибуты этого источника и добавить custom field с ключом swp_wp_document_revision. В документации SearchWP указано, что в ряде случаев это поле может отображаться в списке как WP Document Revisions. Если видите такой вариант, используйте его. Если не видите, добавьте ключ вручную, внимательно проверив написание: лишний пробел, дефис вместо подчёркивания или другой регистр превратят настройку в пустой атрибут.

Не заменяйте этот атрибут обычным полем Content или Excerpt. Заголовок, описание и выдержка документа полезны для релевантности, но текст из последней ревизии интеграция передаёт именно через swp_wp_document_revision. Если это поле не индексируется, пользователь будет находить документы по названию, но не по фразам внутри файла.

Вес атрибутов и первые значения

SearchWP позволяет назначать каждому атрибуту вес. Это не настройка "работает или не работает", а настройка релевантности. Если вес содержимого документа слишком низкий, документ может находиться, но проигрывать страницам, где тот же термин встречается в заголовке. Если вес слишком высокий, поиск будет чрезмерно тянуть в выдачу длинные PDF, даже когда пользователь ищет обычную страницу сайта.

Для начала используйте умеренную схему: заголовок документа оставить самым сильным сигналом, swp_wp_document_revision сделать вторым важным сигналом, описание и таксономии использовать как вспомогательные. После тестовых запросов можно изменить вес без полной перестройки индекса, но добавление нового атрибута и обработка существующих документов требуют переиндексации. SearchWP сам уведомляет, когда изменения требуют rebuild, но в этом сценарии полный reindex после добавления поля обязателен практически всегда.

Когда повышать вес содержимого файла

Повышайте вес swp_wp_document_revision, если пользователи чаще ищут фразы из текста документа, чем точные названия. Это типично для инструкций, регламентов, технических паспортов и учебных материалов. Например, документ называется "Регламент обслуживания", а пользователь ищет "замена фильтра после аварийного режима". Такой запрос должен уверенно поднимать документ, даже если в заголовке нет ни одного слова из фразы.

Когда снижать вес содержимого файла

Снижайте вес, если длинные документы начинают забивать выдачу по слишком общим словам. Большой PDF может содержать десятки повторов термина, но не всегда быть лучшим ответом. В таком случае заголовок, таксономия, статус или раздел сайта должны помогать ранжированию. Для публичного сайта также полезно отделить общий поиск по сайту от отдельной формы "поиск по документам".

Почему важна именно последняя ревизия документа

Ключевая особенность интеграции - работа с последней ревизией. WP Document Revisions хранит историю, а пользовательская ссылка на документ обычно должна вести к актуальному файлу. SearchWP WP Document Revisions Integration следует этой логике: берёт файл из последней ревизии, извлекает текст и кладёт его в индекс. Это правильно для большинства документальных библиотек, но у такого поведения есть нюансы.

Что происходит после загрузки новой версии

Когда редактор загружает новую версию файла в WP Document Revisions, для пользователя меняется актуальное содержимое документа. Но поисковый индекс не всегда перестраивается мгновенно в тот же момент, особенно на сайтах с фоновой обработкой и большой библиотекой. SearchWP умеет применять небольшие обновления после изменений контента, но после первичной настройки интеграции и при массовых изменениях документов лучше явно следить за статусом индексации.

Практический вывод простой: после загрузки новой редакции проверьте не только ссылку на документ, но и поиск по новому термину из файла. Если старая фраза всё ещё поднимает документ, а новая не находится, индекс мог не успеть обновиться или файл не был корректно обработан. В таком случае помогает точечная переиндексация документа или полный rebuild, если менялась конфигурация движка.

Старые версии и юридически важные архивы

Интеграция ориентирована на актуальную ревизию, а не на полноценный поиск по всем историческим версиям. Это логично для справочной страницы, где пользователю нужен текущий регламент или свежая инструкция. Но если ваш проект обязан искать по архивным версиям документов, например для юридического аудита или внутренней истории согласований, одной этой интеграции может быть недостаточно. В таком сценарии нужно отдельно проектировать модель поиска по ревизиям и проверять, какие объекты могут быть источниками SearchWP.

Не стоит маскировать это ограничение настройкой веса. Если SearchWP индексирует только содержимое последней ревизии через swp_wp_document_revision, то повышение веса не заставит его искать по старой версии файла. Для пользователя это нужно объяснить в интерфейсе: поиск по документам показывает актуальные документы, а история версий остаётся внутри карточки документа.

Fallback на вложение и почему это важно

Официальная документация интеграции отмечает важный нюанс: если ревизия не хранит действительный attachment ID явно, система пытается использовать самый свежий загруженный файл, связанный с документом. Это полезно для совместимости с внутренней моделью WP Document Revisions, но для администратора означает, что после миграций и ручных переносов нельзя игнорировать attachment metadata. Если в базе потерялась связь между документом и файлом, поиск может вести себя непредсказуемо.

Никогда не чините такую проблему правкой ядра плагина на рабочем сайте. Сначала восстановите резервную копию, проверьте путь к папке документов, attachment ID, поле _wp_attached_file, постоянные ссылки и логи. Правка файлов плагина исчезнет при обновлении и может ухудшить безопасность.

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

Представим сайт компании, где WP Document Revisions используется для внутренних регламентов. Сотрудники не знают точных названий файлов, но ищут по рабочим фразам: "заявка на доступ", "аварийный режим", "ответственный за согласование", "форма передачи оборудования". Задача - сделать отдельный поиск по документам так, чтобы результаты находились по тексту последней редакции файла, но публичные страницы сайта не смешивались с внутренней библиотекой.

Цель

Нужно получить поисковую форму для раздела "Документы", где результаты включают документы WP Document Revisions и ранжируются по названию, описанию, статусу и содержимому последней ревизии. Пользователь должен находить документ по фразе из PDF или офисного файла. При этом конфиденциальные документы не должны всплывать в выдаче для неподходящей роли.

Подготовка

Перед настройкой создайте три тестовых документа. Первый - публичная инструкция с уникальной фразой в заголовке и внутри файла. Второй - частный документ с уникальной фразой только внутри файла. Третий - документ, у которого есть новая ревизия с термином, которого не было в старой версии. Такой набор позволит проверить сразу три вещи: базовую индексацию, поведение доступа и обновление последней ревизии.

Для каждого файла запишите контрольные запросы. Например: фраза из заголовка, фраза только из тела документа, фраза из старой версии и фраза из новой версии. Это простая таблица проверки, но она экономит много времени. Без контрольных запросов администратор часто тестирует поиск общими словами и не понимает, сработал ли именно новый атрибут интеграции.

Шаги настройки

1. Откройте SearchWP -> Algorithm и выберите движок, который будет обслуживать поиск по документам.
2. Добавьте источник документов WP Document Revisions, если он ещё не включён.
3. В атрибутах источника добавьте custom field swp_wp_document_revision.
4. Оставьте заголовок документа сильным сигналом, а содержимое файла сделайте значимым, но не единственным фактором релевантности.
5. Если поиск должен быть только по документам, не добавляйте в этот движок обычные записи и страницы либо подключите отдельную форму к дополнительному движку.
6. Сохраните настройки и выполните полный reindex.
7. После завершения индексации выполните контрольные запросы под нужными ролями пользователей.

Проверка

Сначала ищите фразу, которая есть только в тексте файла, но отсутствует в заголовке и описании документа. Если документ находится, значит custom field работает. Затем ищите фразу, которая есть только в старой ревизии, и фразу из последней ревизии. Ожидаемое поведение - поиск ориентируется на актуальный файл. Если старая фраза всё ещё находится после замены документа, выполните повторную индексацию и проверьте, действительно ли новая ревизия стала последней в WP Document Revisions.

Нюанс, который часто мешает

Если документ не появился в выдаче, не меняйте сразу веса. Вес влияет на позицию результата, но не лечит отсутствие данных в индексе. Сначала проверьте: включён ли source документов, добавлен ли swp_wp_document_revision, завершён ли reindex, читается ли текст внутри файла, не зашифрован ли документ, не удалена ли ревизия оптимизатором базы и не ограничивает ли правило движка нужный тип записей.

Как проверять результат и настраивать релевантность

Проверка поиска должна быть строже, чем обычное "я что-то нашёл". В документальной библиотеке важно понять, почему результат оказался в выдаче: совпал заголовок, сработало содержимое файла, подтянулась таксономия, помогла фраза из описания или документ попал случайно из-за слишком общего слова. Если не разделить эти причины, дальнейшая настройка веса будет похожа на угадывание.

Набор тестовых запросов

Соберите небольшой лист запросов из реальных слов пользователей. Не берите только идеальные фразы из документации. Нужны короткие и длинные запросы, точные названия, фразы с опечаткой, слова из PDF, слова из заголовка, термины из описания, запросы без результата и запросы, которые должны поднимать закрытый документ только для подходящей роли.

Для каждого запроса фиксируйте ожидаемый результат: какой документ должен быть первым, какие документы допустимы ниже, какие документы не должны появляться вообще. После изменения веса или правил повторяйте тот же набор. Так вы увидите, улучшилась ли релевантность, а не просто изменилась выдача.

Точные фразы и подсветка

SearchWP поддерживает поиск по фразам в кавычках с некоторыми ограничениями. Это полезно для проверки, когда нужно отличить общий набор слов от точной фразы в документе. Если документ находится по отдельным словам, но не находится по точной фразе, проверьте, как текст извлекается из файла: PDF-парсеры иногда меняют переносы строк, порядок колонок или пробелы. Это не обязательно ошибка интеграции, но это влияет на ожидания пользователя.

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

Отдельная форма для документов

Во многих проектах лучше иметь две поисковые логики: общий поиск по сайту и отдельный поиск по документам. Общий поиск должен быстро находить страницы, записи и основные разделы. Документальный поиск может быть глубже, учитывать содержимое файлов, показывать больше результатов и использовать фильтры по типу документа, статусу или разделу. SearchWP позволяет работать с разными движками, поэтому не обязательно смешивать всё в Default Engine.

Если используете SearchWP Live Ajax Search, проверьте, какой движок использует форма и сколько результатов показывается в выпадающем списке. Для документов живой поиск удобен, но длинные названия файлов и похожие регламенты могут требовать более подробного шаблона результатов. В таком случае лучше показать не только заголовок, но и короткую выдержку, тип документа, дату изменения в административном смысле и статус доступа, если это допустимо для аудитории.

Безопасность доступа: индекс не заменяет правила просмотра

Документы часто чувствительнее обычных записей. В WP Document Revisions есть приватные и защищённые паролем документы, владельцы, права и возможность ограничить доступ через возможности WordPress. SearchWP строит индекс, но индекс не должен восприниматься как система прав доступа. Ваша задача - проверить, что поисковая выдача не показывает лишние заголовки, выдержки или ссылки тем пользователям, которые не должны знать о документе.

Что проверить для закрытых документов

Создайте тестовый закрытый документ с фразой, которой нет больше нигде. Войдите как администратор и убедитесь, что документ находится. Затем выйдите из аккаунта или используйте отдельное окно браузера без авторизации. Повторите запрос. Если результат виден гостю, решите, допустимо ли это для вашего проекта. Иногда достаточно, чтобы ссылка требовала авторизации при открытии. Но для внутренних регламентов, кадровых документов или клиентских файлов уже сам заголовок в выдаче может быть лишним.

Если закрытые документы не должны появляться в общем поиске, используйте отдельный движок, правила источника, шаблон результатов и проверку роли пользователя. Не надейтесь на то, что пользователь "всё равно не сможет скачать файл". Поиск - это тоже интерфейс доступа к информации, и он должен проектироваться вместе с политикой видимости.

Роли, Members и ограничения по документам

FAQ WP Document Revisions упоминает, что права можно менять через плагины ролей вроде Members или через фильтр document_caps. Но support-обсуждения показывают, что тонкая роль-доступность конкретного документа может быть сложнее, чем ожидает администратор. Поэтому для серьёзной модели доступа сначала проверьте реальное поведение под каждой ролью, а не только наличие галочек в интерфейсе.

Если нужно разграничение по отделам, рабочим группам или таксономиям, лучше проектировать это как отдельную задачу. В Code Cookbook WP Document Revisions есть примеры расширений для дополнительных сценариев, но добавлять их в рабочий сайт без тестов рискованно. Для поиска это означает: пока модель прав не подтверждена, не включайте чувствительные документы в публичный движок SearchWP.

Файлы вне публичного корня

Вынесение папки документов за пределы web root может повысить контроль над прямым доступом к файлам, но добавляет требования к серверу и миграциям. Если после переноса сайта документы открываются с ошибкой, SearchWP не сможет сделать этот путь надёжным. Сначала проверьте настройку Document Upload Directory, запись attachment metadata, права на папку и постоянные ссылки WP Document Revisions. Только потом возвращайтесь к переиндексации.

Производительность индексации и качество документов

Поиск по содержимому файлов всегда тяжелее, чем поиск по заголовкам. SearchWP строит собственный индекс в фоновой обработке, разбивает контент на токены и затем ищет по индексу. Это быстрее для пользователя, но первичная обработка документов может занять время. Чем больше файлов, чем они тяжелее и чем сложнее формат, тем важнее планировать индексацию.

Когда запускать полный reindex

Полный rebuild нужен после добавления нового атрибута swp_wp_document_revision, после существенного изменения источников, после массового импорта документов и после восстановления библиотеки из резервной копии. Если меняется только вес уже индексируемого атрибута, SearchWP обычно может применить вес при поиске без полной перестройки, но ориентируйтесь на уведомления интерфейса и проверку результата.

На небольшом сайте можно запустить rebuild из админ-панели. На более техническом проекте удобно использовать WP-CLI, если он доступен и вы понимаете последствия. Документация SearchWP описывает команды:

wp searchwp index --rebuild
wp searchwp reindex 114
wp searchwp diagnostics tokens 114

Эти команды не нужно выполнять вслепую на продакшене. Используйте их как инструмент администратора: rebuild - для полного пересчёта, reindex - для отдельной записи, diagnostics - для проверки токенов и статуса. Если у вас нет доступа к командной строке, аналогичную логику можно пройти через административные инструменты SearchWP.

Ограничения файлов

Официальные материалы SearchWP говорят о поддержке PDF, офисных документов, OpenOffice/LibreOffice, RTF и текстовых файлов, но также подчёркивают невозможность гарантировать чтение каждого PDF. Если PDF зашифрован, повреждён или состоит из изображений без текста, поиск не сможет извлечь нужные слова. Для библиотек с отсканированными документами сначала настройте распознавание текста до загрузки в WP Document Revisions.

Качество документа влияет на качество поиска сильнее, чем вес атрибута. Чистый текстовый PDF с нормальными заголовками, описанием и понятным названием найдётся лучше, чем скан с длинным случайным именем файла. Перед массовой индексацией стоит привести документы к единому правилу именования, заполнить описания и проверить, какие типы файлов реально используются.

Большие библиотеки и хостинг

Для большой библиотеки оценивайте не только SearchWP, но и хостинг: лимиты памяти, длительность фоновых задач, cron, права на чтение файлов, размер базы данных и резервные копии. SearchWP в FAQ осторожно указывает, что продукт лучше всего подходит для малых и средних сайтов, а очень крупные наборы записей могут быть неподходящим сценарием. Это не запрет, но сигнал провести тест на реальном объёме, а не на пяти файлах.

Частые проблемы и диагностика поиска по ревизиям

Диагностику удобно вести по симптомам. Не начинайте с переустановки всех плагинов: сначала определите, на каком участке цепочки сбой. Документ создан? Последняя ревизия открывается? Текст в файле выделяется? Поле swp_wp_document_revision добавлено? Индекс перестроен? Выдача проверена под правильной ролью? Такой порядок быстрее, чем хаотичная смена настроек.

Типичные симптомы и первые проверки

Симптом	Возможная причина	Что проверить	Как исправить
Документ не находится по фразе из файла	Не добавлен custom field или индекс не перестроен	Источник документов, атрибут swp_wp_document_revision, статус индекса	Добавить поле, сохранить алгоритм и выполнить полный reindex
Документ находится по заголовку, но не по содержимому	Файл не прочитан или не содержит текстового слоя	Выделяется ли текст в PDF, не защищён ли файл, поддерживается ли формат	Подготовить файл с текстовым слоем, заменить ревизию и переиндексировать
В выдаче появляется старая версия документа	Индекс не обновился после загрузки новой ревизии	Какая ревизия последняя, завершилась ли фоновая индексация	Точечно переиндексировать документ или запустить rebuild после массовых изменений
После миграции документы открываются с ошибкой	Сломан путь к папке документов или attachment metadata	Document Upload Directory, _wp_attached_file, права на чтение, постоянные ссылки	Исправить путь и права, проверить открытие документа, затем переиндексировать
Закрытый документ виден не той аудитории	Поисковый движок включает источник без нужных правил видимости	Результаты под гостем и разными ролями, шаблон выдачи, правила source	Разнести публичный и внутренний поиск, добавить правила и проверить выдержки
Исчез журнал ревизий	Оптимизатор базы удалил document revisions как обычные ревизии	Историю документа, резервные копии, настройки cleanup-плагина	Восстановить из резервной копии и исключить ревизии документов из очистки

Поле не видно в списке атрибутов

Если в списке нет подписи WP Document Revisions, попробуйте добавить ключ вручную. Если и это не помогает, проверьте, что расширение активно, а источник документов действительно включён в текущий движок. Иногда администратор редактирует не тот engine: например, на сайте используется отдельная форма с supplemental engine, а изменения внесены в Default Engine.

Поиск работает в админке, но не на сайте

SearchWP может использовать разные формы и движки. Если администратор проверяет поиск внутри админ-панели, а пользователь вводит запрос в кастомную форму темы, результаты могут отличаться. Проверьте, перехватывает ли SearchWP нативный поиск, не использует ли форма отдельный параметр, не переопределяет ли тема запрос и не подключён ли Live Ajax Search к другому движку.

Выпадающая живая выдача показывает мало документов

Live Ajax Search имеет собственные настройки: минимальное число символов, максимальное количество результатов, шаблон вывода и привязку к форме. Если полная страница результатов показывает документы, а выпадающий список нет, проблема может быть не в интеграции WP Document Revisions, а в конфигурации живого поиска. Проверьте ограничение количества результатов и движок, который использует конкретная форма.

Когда лучше откатить настройку

Откатывайте последние изменения, если после добавления документов резко ухудшилась общая выдача сайта, посетители стали видеть служебные материалы или индексирование заметно нагружает сервер. Самый безопасный откат - убрать источник документов из общего движка, сохранить настройки, перестроить индекс при необходимости и оставить отдельный тестовый движок для документального поиска. Не удаляйте сами документы и не очищайте ревизии ради быстрого "исправления" поиска.

Полезные улучшения без правки ядра плагинов

Вокруг WP Document Revisions много старых советов с правкой PHP-файлов плагина. Для рабочего сайта такой путь плох: изменения потеряются при обновлении, могут конфликтовать с безопасностью и усложнят поддержку. Лучше использовать настройки SearchWP, отдельные движки, правила источников, шаблоны результатов, роли WordPress и проверенные hooks только тогда, когда вы понимаете их назначение.

Отдельный шаблон результатов для документов

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

Правила источника вместо ручного исключения документов

Если в общем поиске нужны только публичные документы, используйте правила Source или отдельный engine. Ручное удаление документов из индекса неустойчиво: после следующего rebuild они могут вернуться. Правило в конфигурации понятнее и воспроизводится после переиндексации.

Контроль ревизий и очистки базы

Плагины оптимизации базы могут воспринимать ревизии документов как мусор. Для WP Document Revisions это не мусор, а ключевая часть продукта. Перед включением автоматической очистки проверьте документацию оптимизатора и сделайте тест на копии сайта. Если ревизии исчезают, выключите соответствующий режим очистки или добавьте исключение. Восстановление истории обычно сложнее, чем профилактика.

Проверка через диагностические логи

SearchWP поддерживает режим отладки, который пишет логи в папку загрузок и может выводить диагностический HTML-комментарий на страницах результатов. Используйте это временно, когда нужно понять, какой движок сработал, какие токены обработаны и какие результаты получили релевантность. После диагностики удалите логи, потому что в них могут быть SQL-запросы и служебные данные.

Когда SearchWP WP Document Revisions Integration будет удачным выбором

Расширение стоит использовать, когда на сайте уже есть две опоры: SearchWP как поисковый движок и WP Document Revisions как система управления файлами с ревизиями. В этом случае SearchWP WP Document Revisions Integration добавляет недостающий слой: содержимое последней ревизии документа становится частью поискового индекса и может влиять на релевантность выдачи.

Перед запуском проверьте зависимые плагины, читаемость файлов, источник документов, атрибут swp_wp_document_revision, полный reindex, права доступа и выдачу под разными ролями. Если все контрольные запросы проходят, интеграция превращает обычную страницу документов в рабочую справочную библиотеку, где пользователь ищет не по догадкам о названии файла, а по реальным словам из актуальной версии документа.

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