Меню

Fj related articles plus настройка



Вывода похожих материалов в Joomla 2.5

Опции темы

Здравствуйте! Подскажите название Модуля для вывода похожих материалов в Joomla 2.5?

Fktrctq

Если стандартного мало, то можно использовать этот: Extranews plugin: Older, Newer and Related Articles (_http://kythuatvatlieu.org/joomla-extensions/16-and-above.html) На оф сайте так же можно скачать и для других версий joomla.

Плагин — супер. Умеет выводить старые, новые и похожие новости. Можно добавлять к ним дату, количество просмотров, описание и картинку.

Работоспособность на 2.5 проверена у меня на блоге (в подписи). В конце каждой статьи видно его работу.

  • 2

Павел Joofaq

Спасибо сказали:

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

Fktrctq

модуль называется: Материалы — Связанные материалы

Описание модуля: Этот модуль отображает список ссылок на материалы, которые связаны с тем, что в данный момент отображается в центральной области страницы. Связи определяются по ключевым словам, введённым в параметрах материала.
Все ключевые слова данной статьи ищутся в списках ключевых слов других опубликованных материалов. Например, у вас есть материалы «Разведение попугаев» и другой материал «Руководство по разведению чёрных какаду». Если вы включите ключевое слово «попугай» в оба эти материала, модуль ‘Связанные материалы’ будет считать их связанными и покажет ссылку на материал «Разведение попугаев» при просмотре материала «Руководство по разведению чёрных какаду» и так далее

  • 1

rom_4

Спасибо сказали:

Fktrctq, Для 2.5 версии есть FJ Related Articles Plus, будет что-то вроде http://diving-union.ru/.

hammer8

Extranews plugin: Older, Newer and Related Articles — ver. 3.0.7 попробывал этот плагин в общих чертах понравился Для joomla 2.5 не нашёл — только для 3.0 Сделал перевод кому интересно брать здесь

Fktrctq

здравствуйте!
Стандартный модуль вывода joomla 2.5 похожих материалов да и все, что попадались сторонние расширения есть возможность вывода материала на страницы сайта (привязка к категориям меню) Мне нужно сделать вывод похожих материалов только на определённые страницы (на страницы с текстом)

По сути что я хочу — на страницу №1 (со статьёй определённой категории «категория 1» ) сделать вывод похожих материалов из разных категорий На страницу №2 (со статьёй из «категория 1» ) сделать вывод похожих материалов из разных категорий

На 1 и 2 странице выведенные материалы будут разными

Возможно ли такое сделать !? есть ли для этого какие нибудь расширения?

Источник

FJ Related Articles Blog and List Component

Новая версия программы для Joomla! Версия 3.2 и 3.1! Теперь FJ связанных компонент использует теги, а не ключевые слова простота обслуживания и быстрая обработка.

Освободиться от Joomla одиночной категории ограничений. Вы когда-нибудь захотите поместить статью на две или более категорий? Список избранных статей из разных категорий? Создать блог или список, основанный на автора?

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

* Создать блог или список макетов в точности как стандартная Категория блога и макеты списка, но с помощью тега или ключевое слово и автор соответствие вместо категории.
* Дополнительный матч на автора или псевдоним автора, а также ключевые слова.
* Возможность добавления статей с любой соответствующие ключевые слова или только статьи, где все ключевые слова матч.
* Возможность ограничить статей, основанных на разделе или категории.
* Возможность показать соответствующие ключевые слова и сортировку на основе лучший матч.
* 7 ноября 2013 года: версия 3.0.0 теперь доступен для Joomla версии 3.2 и 3.1.
* 7 января 2010 года: версии 1.0.10 теперь доступен. Позволяет Вам выбрать опубликованные или Заархивированы. Также позволяет редактировать с макетов.
* 29 августа, 2009: Версия 1.0.7 теперь доступен. Позволяет Вам создать блог или список без необходимости введения в статье. Кроме того, позволяет Показать все статьи, написанные пользователя, вошедшего в систему.
* 9 июня 2009 года: версия 1.0.6 теперь доступен. Это добавляет новый вариант использовать Точное совпадение ключевых слов. Так, списки ключевых слов, должны иметь те же слова и в том же порядке, чтобы соответствовать.
* 7 мая 2009 года: теперь доступен с версии 1.0.5. Это добавляет новый параметр, который позволяет создавать ссылки на другие FJ связанных элементов меню, вместо статей. Если соответствующей статье Intro статьи еще FJ связанных пункт меню, вы можете добавить ссылку на этот пункт меню, а не статья.
* 12 апреля 2009 года: версия 1.0.4 теперь доступен. Это обновление исправляет проблему с вызывая в статье, будут потеряны. Также добавляет итальянский langage.
* 12 марта 2009 года: версия 1.0.3 теперь доступен. Он исправляет незначительные проблемы с отображением.

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

Источник

Django — Урок 049. Оптимизация производительности Django на примере боевого проекта

Последнее время я посвятил много времени оптимизации сайта и теперь хотелось бы рассказать об этом.
В данной статье будет объяснено использование методов select_related и prefetch_related в QuerySet, а также их различие. Также постараюсь объяснить почему Django считают медленным, и почему это всё-таки не так. Конечно Django по многим статьям медленнее, чем тот же Flask, но в тоже время в большинстве проектов проблема заключается не в самом Django, а скорее а в отсутствии опттимизации запросов к базе данных.

Поэтому давайте оптимизируем страницу форума сайта EVILEG . А поможет нам в этом батарейка Django Silk, которая служит для измерения количества запросов к базе данных, а также измерения их длительности.

Установка и настройка Django Silk

Устанавливаем Django Silk

Добавляем его в INSTALLED_APPS

а также добавляем MIDDLEWARE

Ещё на понадобится добавить urls из django-silk, чтобы можно было просматривать статистику запросов.

И последним шагом применяем миграцию django-silk

Примечание к Django Silk

Не используйте Django Silk на боевом сервере. По крайней мере с такими настройками, как показаны в этой статье. Если у вас есть уже хорошая посещаемость на сайте, например 1400 человек в сутки, то с такими настройками Django Silk просто съест все ваши ресурсы. Поэтому экспериментируйте только на development сервере.

Работа с оптимизацией

Для начала посмотрим, насколько всё плохо с запросами к базе данных на главной странице форума. Для ясности посмотрим, как выглядит данная страница

Для этого нам нужен всего лишь загрузить интересующую нас страницу и посмотреть статистику запроса в Django Silk.

В данный момент все запросы будут показаны в дебаг режиме.

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

  • 325 запросов к базе данных
  • на которые тратится 155 мс
  • 568 мс на всю страницу

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

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

Выполняем оптимизацию

Посмотрим, как выглядит изначальный QuerySet для главной страницы форума.

Как видите ничего сложного. Именно такие запросы как правило и пишут в самом начале использования Django ORM. А уже потом начинаются вопросы, как оптимизировать производительность Django.

Дело в том, что первоначальный queryset, который требуется для отображения данной страницы забирает из базы данных только объекты ForumTopic , но не забирает остальные объекты, которые добавлены в ForeignKey поля модели данных ForumTopic . Поэтому Django вынужден автоматически подгружать все необъодимые объекты тогда, когда они требуются. Но программист знает, что потребуется для каждой отдельной страницы и может указать Django все необъодимые объекты, которые необходимо забрать заранее одним запросов. Давайте сделаем это с помощью select_related.

select_related

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

Давайте попробуем выбрать некоторые данные в одном запросе с помощью selected_related . Я знаю, что для моей модели ForumTopic в качестве related можно выбрать следующие поля:

  • article — статья, к которой относится вопрос на форуме
  • answer — ответ, сообщение, которое было помечено как ответ в теме форума
  • section — раздел, в котором был задан вопрос
  • user — пользователь, который задал данный вопрос

Изначальный запрос к базе данных можно модифицировать следующим образом:

После чего посмотрим на результат в Django Silk

Ситуация с количеством запросов уже стала лучше

  • 256 запросов к базе данных
  • на которые тратится 131 мс
  • 444 мс на всю страницу

На следующем рисунке приведена строчка с новым запросом, который имеет 4 join операции.

Как видите, длительность этого запроса составила 19,225 мс .

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

prefetch_related

prefetch_related отличается тем, что позволяет подгрузить не только объекты, которые используются в ForeignKey полях модели, но и те объекты, модели которые имеют поле ForeignKey на модель, кооторая участвует в основном запросе к базе данных. То есть можно подгрузить сообщения в топике отдельным запросом. В данном ситуации я хочу подгрузить следующие поля.

  • comments — это сообщения в топике, модель ForumPost
  • comments__user — внешний ключ на пользователя, который оставил сообщение
  • answer___parent — внешний ключ на ForumTopic, у ответа, который был помеченорешением топика. Теоретически можно было бы забрать данный объект через select_related , но структура запроса стала очень сложной, что не позволило бы эффективно использовать select_related . Да, да использование этого метода должно быть разумным. Производительность, конечно, улучшается, но иногда некоторые данные лучше забирать отдельным запросом.

Тогда запрос к базе данных уже выглядит так:

А в Django Silk я получаю следующий результат

В итоге имеем следующее:

  • 6 запросов к базе данных
  • на которые тратится 26 мс
  • 148 мс на всю страницу

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

Но это ещё не всё, заметьте что запрос, которые имет 4 join операции по прежнему находится в районе 17-20 мс. Можем ли мы с этим что-то сделать? Конечно можем, и для этого нам понадобится использование метода only .

Метод only позволяет забирать только те столбцы, которые нам нужны для отображения страницы. Но в данном случае нужно будет учесть всё столбцы, которые потребуются, иначе каждый упущенный столбец Django будет забирать отдельным запросом.

Поэтому я написал следующий запрос к базе данных

И получил следующий результат

  • 6 запросов к базе данных
  • на которые тратится 20 мс
  • 136 мс на всю страницу

Конечно, я привожу лучшие возможные результаты, поскольку всегда имеются некоторые колебания в измерениях, но по данному скриншоту видно, что длительность основного запроса снизилась с 17-19 мс до 11-13 мс . Помимо прочего выборка только нужных полей снижает и потребление памяти, если из базы данных забираются например очень крупные куски текстовых данных, которые при этом не используются в рендеринге страницы.

А теперь давайте немного поиграемся с выполнением запросов select_related и prefetch_related

Дополнительная оптимизация

Дочитав до этого момента, Вы, я думаю, убедились, что использование select_related позволяет очень классно оптимизировать запросы к базе данных. Но есть одно НО . Некоторые проблемы могут возникнуть в использованием класса Paginator , который используется у меня на данной странице. И дело в том, что для Paginatorа необходимо выполнять запрос count, чтобы подсчитать правильное количество страниц. А если запрос будет очень сложным, то и длительность запроса count может оказаться довольно большой и соразмерной с выполнением обычного запроса. Поэтому важным условием может быть написание быстрого и эффектинвого основного запроса, а все остальные объекты лучше будет подгружать с помощью prefetch_related . То есть у вас может быть ситуация, когда лучше выполнить ещё пару дополнительных запросов, чем перегружать join операциями основной запрос.

И вот такой запрос к ORM я написал для данной страницы

В тоже время я получил следующий результат по производительности

  • 8 запросов к базе данных
  • на которые тратится 14 мс
  • 141 мс на всю страницу

Конечно, Вы можете сказать, что в данном случае здесь не очень-то большой выигрыш. Тем более, что общая скорость загрузки даже немного упала (5 мс), а запросов к базе данных стало на 2 больше, но в тоже время я получил прирорст производительности запросов на 42 процента , а это уже кое-чего стоит. Таким образом, если у вас на сайте имеются очень длительные запросы, которые используются в пагинации и имеют большое количество join операций, то возможно стоит переписать использование select_related на prefetch_related . Это на самом деле может помочь сделать ваш сайт на Django значительно быстрее.

Источник

Читайте также:  Настройка canon 550d для видеосъемки
Adblock
detector