Разработка плагина Smart Search

После релиза Joomla! 2.5, мы получили доступ к новой возможности улучшить поиск на сайтах Joomla!. За основу инструмента Smart Search был взят JXtended's Finder. С его помощью можно улучшить результативность поиска и найти именно то, что искал. Стандартный Smart Search работает с основной массой данных, но сторонним разработчикам придется создавать собственный плагин для взаимодействия со Smart Search. Здесь я вам помогу.

Что делают плагины Finder?

Плагины Finder настраивают поиск элементов и автоматически обновляют их в процессе обычного использования сайта. Без них данные компонента не могут быть проиндексированы и обработаны в процессе поиска в компоненте Smart Search. Похожее требование есть в «классическом» компоненте Search. Он помогает искать данные.

Что необходимо для плагинов Finder?

У каждого плагина свои особые требования, но есть код, который нужен для должной работы любого плагина. Вместо тго, чтобы размещать громоздкие блоки кода, я дам вам ссылку на плагин Finder для статей com_content на GitHub. Советую использовать код, как я расписал его здесь.

Свойства класса и внешняя зависимость

Как видно сразу после блока с документами, нужно скачать два файла. Jimport подгружает класс JComponentHelper, а он используется в методе индексов. Оператор require_once подгружает родительский класс плагина Finder - FinderIndexerAdapter. Все плагины Finder’а должны расширить этот класс для правильной работы.

Объясню, что означает каждое свойство класса в этом плагине, а также некоторые свойства родительского класса, которые нужно учесть:

  • $context – это идентификатор плагина. В ядре это часть имени класса после plgFinder;
  • $extension – расширение, поддерживаемое плагином, то есть com_content;
  • $layout – имя sublayout, которое будет использоваться в процессе построения результатов поиска. В ядре – это имя одного вида элемента во внешнем интерфейсе (чтобы объяснить подробнее, во внешнем интерфейсе поисковой движо будет искать файл шаблона default_article.php в com_finder, а если он отсутствует там, то в файле default_result.php);
  • $type_title – название типа контента, который обрабатывается плагином. Он используется для отображения имени в опции фильтрации "Type" тогда, когда фильтры доступны (учтите, что он привязан к языковым константам. Обратитесь к соответствующему языковому файлу для того, чтобы увидеть детали структуры);
  • $table – таблица базы данных, в которой хранятся данные компонента (важно: зесь нужно использовать префикс #__).

Дополнительные свойства в родительском классе FinderIndexerAdapter:

  • $mime – при индексации различных типов файлов (таких как файлы PDF), это свойство должно быть выставлено соответственно MIME данных – по умолчанию NULL;
  • $db – объект базы данных, все плагины должны взаимодействовать с выбором базы;
  • $state_field – это поле, в котором хранится состояние публикации в базе данных (обычно состояние или поле). По умолчанию – состояние (state).

Функции классов и информация о родительских классах

Далее я расскажу о каждой функции в этом классе, а также о том, как правильно пользоваться классом FinderIndexerAdapter. Все эти функции (кроме плагина Finder, работающего с com_categories) входят в родительский класс, который содержит родовой код для обновления ключевых свойств элемента. Разработчики, которые хотят заместить (переопределить?) эти функции должны тщательно изучить родительские классы, чтобы данные правильно обрабатывались на всех уровнях.

  • public function __construct – стандартный класс конструктора, который требуется большинством плагинов для загрузки языковых файлов из директорий по умолчаниию.
  • public function onFinderCategoryChangeState – новая функция в Joomla! 2.5. Этот метод похож на событие onCategoryChangeState, которое срабатывает при изменении состояния публикации категории в списке администратора. Используется для обновления ключевых свойств дочернего элемента в категории (не нужна для компонентов без категорий/структуры элемента).
  • public function onFinderAfterDelete – это событие работает также, как и onContentAfterDelete и по умолчанию стирает индексируемые данные тех элементов, которые были удалены в компоненте или в панели администратора Smart Search.
  • public function onFinderAfterSave - это событие работает также, как и onContentAfterSave и по умолчанию обновляет информацию об уровне доступа к элементу при его изменении или, когда изменен уровень доступа к категории. Для правильной работы, контекстная проверка одного элемента должна включать как вид категории во внутреннем, так и во внешнем интерфейсе.
  • public function onFinderBeforeSave – это событие работает также, как и onContentBeforeSave и по умолчанию запрашивает и хранит уровень доступа к родительской категории или элементу. Используется вместе с onFinderAfterSave для изменения индексируемых данных при изменении уровня доступа.
  • public function onFinderChangeState - это событие работает также, как и onContentChangeState и по умолчанию обновляет и публикует информацию о состоянии элемента при его изменении в списке администратора. Этот метод работает при отключении плагина – он стирает индексируемые данные данного отключенного плагина.
  • protected function index – этот метод управляет всеми процессами добавления элементов в индекс поиска. Именно здесь выставляется URL элемента, а также метаданные.
  • protected function setup – этот метод срабатывает перед методом индексации. Он подготавливает индексатор к обработке данных плагина. По умолчанию помощники маршрутизации расширений уже включены, так что не должно возникнуть проблем при установке индекса.
  • protected function getListQuery – этот метод заставляет объект JDatabaseQuery запрашивать данные, которые нужно проиндексировать. Нужно использовать API JDatabase и JDatabaseQuery, чтобы индексатор работал.

Методы родительского класса FinderIndexerAdapter, которые нужно иметь в виду:

  • protected function getStateQuery – этот метод заставляет объект JDatabaseQuery запрашивать состояние публикации и уровня доступа к элементу или родительской категории. Компоненам без категории (структуру элемента) нужно будет заместить (переопределить?) этот метод в своих плагинах.
  • protected function getUpdateQueryByTime - этот метод заставляет объект JDatabaseQuery запрашивать время обновления из измененного поля базы данных. Компоненты, которые не хранят такие данные или используют другое имя поля должны будут заместить (переопределить?) этот метод в своих плагинах.
  • protected function getURL - этот метод возвращает элементу его non-SEF URL. Используя com_content с параметром ID «1», путь возврата выглядит так: index.php?option=com_content&view=article&id=1. Разработчикам, которым требуется добавление дополнительной информации в URL, потребуется заместить (переопределить?) этот метод в своих плагинах.

Это далеко не полный список всех API для компонента Smart Search, но это подспорье для разработчиков, которые хотят знать основы, достаточные для написания рабочего плагина для своих компонентов.

 

Оригинал статьи