getRelated MODX Revolution. Связанные ресурсы MODX

getRelated – сниппет для MODX Revolution, помогающий создать список связанных ресурсов.

Он помогает настроить алгоритм, с помощью которого такое необходимое свойство как &fields позволит вам определить поля для сравнения и определения важности каждого из них.

Ссылки и история создания

Версия	Дата выпуска	Особенности
1.2.0-pl	7 июня 2012	Добавлены &stopwords свойства, улучшена обработка множественных вызовов на странице, теперь с поддержкой русского языка.
1.1.2-pl	21 января 2012	Добавлено &hideContainers свойство. Предотвращается появление ошибки E_NOTICE. Устранены ошибки в работе &includeDeleted.
1.1.1-pl	10 декабря 2011	Исправлены ошибки в &parents. Исправлена ошибка в &fields, из-за которой можно было выбрать только одно поле.
1.1.0-pl	4 декабря 2011	В настройки результатов добавлены TV свойства, а также новое свойство &exclude для скрывания определенных результатов.
1.0.2-pl	10 ноября 2011	Исправлена ошибка с фильтрацией текущих ресурсов, теперь поиск нечувствителен к регистру букв, исправлены ошибки в свойствах ignoreHidden и ignoreUnpublished. Сделан более понятным процесс отладки.
1.0.1-pl(2)	26 октября 2011	Исправлены ошибки, возникающие при работе со свойствами tpl &parents и &fields
1.0.0-pl	13 октября 2011	Первая публикация. Версии до 1.0 публиковались только для HandyMan. Спонсирована бета-версия.

Как работает getRelated (обязательно к прочтению)

Для правильного использования свойств и получения нужного результата важно понимать, как работает getRelated.

Нижеприведенные шаги собирают вместе необходимые ресурсы.

getRelated находит ресурс, который будет использоваться в качестве базового, обычно это текущий ресурс. Он использует поля, определенные вами (&fields) и разделяет их на части для определения уникальных слов.

Стоп слова, используемые в лексиконе, отфильтровываются, остаются только слова, действительно имеющие смысл.

Далее используются связанные слова в запросе к базе данных, ограниченные контекстом, а также источники, заданные вами и содержащие необходимые ресурсы. Это образец для сравнения. Это работает для входных полей и переменных шаблона на основе заданных вами свойств полей.
Пример работает на основе коэффициента веса, который вы определите в свойствах поля (&fields) для вычисления ранга каждого ресурса.
Результаты сортируются в зависимости от ранга (с самым высоким рангом - первые) и затем выводится на экран в соответствии с tpl свойствами.

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

Использование

Нет никаких причин, чтобы я мог подумать вызвать этот сниппет некэшированным. Еесли вы запускаете огромный сайт, вызов сниппета некэшируемым поможет повышению производительноти, причем результат будет настолько значительным, что это просто не нужно. Этот сниппет обращается к данным ресурсов, и по умолчанию кэш очищается после обновления. Между обновлениями нет изменений, которые getRelated мог бы хранить. Поэтому НЕ ВЫЗЫВАЙТЕ ЭТОТ СНИППЕТ НЕКЭШИРУЕМЫМ!

Вы не уверены в том, каким вы вызываете getRelated? Некэшируемый сниппет вызывается с использованием восклицательного знака: [ [!snippetname]], поэтому нам нужно использовать его БЕЗ восклицательного знака: [ [snippetname]].

Необходимый минимум для вызова getRelated заключается в использовании тэга:

Такой вызов создает неупорядоченный список, максимум с тремя связанными ресурсами, базирующимися на на pagetitle и introtext. В дальнейшем вы можете изменить это, используя свойства the &fields (см. выше) для задействования какого-либо тэга, или категории TV, или другого поля, которое содержит итоговое значение или ключевые слова.

Оптимизация производительности сниппета getRelated

Если из-за getRelated появилось снижение производительности, вот несколько предложений / мыслей на эту тему:

Убедитесь, что сниппет вызван кэшируемым! Я не смогу помочь узнать причину снижения проиводительности, если вы некэшируете этот сниппет.
Не используйте поля наподобие контента, т.к. они попросту могут быть очень большими.
Возможно, что запрос используемый для создания образца слишком обширный. Могут быть многочисленные причины и решения на этот счет.

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

3.2. Все ваши ресурсы используют похожие слова (название компании, наименования продаваемой продукции или любимые слова вашего редактора), в результате чего образец был искажен этим. Если у вас включена отладка (&debug=`1` в сниппете), вы можете увидеть информацию, соответствующую обработке слов, в результате сможете сделать вывод, все ли идет как надо. Если причина в этом, вы можете отфильтровать слова добавлением их в "getrelated.stopwords" словарь на вашем языке. Перейдите: System > Lexicon Management и в выпадающем меню замените "core" на "getrelated".

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

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

4.1. Настройте размер образца. Настройки по умолчанию сделаны после тестирования на протяжении 1 секунды, что нормально для первой загрузки (после чего вы получили результаты из кэша), но это зависит от числа полей, используемых вами, являются ли они полями ресурсов или TV и в итоге какое значение они сохраняют в базе данных.

Если вы использует много TV в &fields, вы можете “уронить ” tvSample скажем, 50-ю результатами на один TV. Если вы используете 3 TV, то можете теоретически уменьшить общее число обрабатываемых ресурсов с 375 до 150. Чтобы еще больше быть уверенными в правильности результата, вы можете изменить порядок, в котором образец обменивается данными с tvSort и tvSortDir, а также fieldSort и fieldSortDir. По умолчанию сортировка ведется по дате создания, самый новый учитывается первым.

Может быть, что returnTVs настройки содержат много TV, что влияет на производительность. Я особо не тестировал это, но вам следует попробовать ограничить результирующие настройки (см. предыдущие советы), и использовать TV только тогда, когда нужно.
Это проблема! Не смотря на то, что дополнение тестировалось на сайтах различного размера и на различных платформах, возможно, что что-то может произойти. Пожалуйста, сделайте сообщение на форуме или Github, и мы посмотрим, что можно сделать. Ссылки есть выше.