Меняем количество статей на странице в инстант 2

5 лет назад (29 апреля 2015) 3590

Актуально для всех версий и до тех пор, пока не введут в админке настройку "Выводить на странице по ... статей" для каждого типа контента. На момент написания актуальная версия 2.2.1

Так как константа 15 прописана в файле движка, придется применить хак. Откроем файл /system/controllers/content/frontenf.php, и в 127 строке после

Код PHP:

$perpage = self::perpage;

добавим

Код PHP:

if($ctype['name']=='news') $perpage=100;//zau4man

Все, теперь при просмотре раздела Новости (по адресу http://ваш сайт/news) будет выводится по 100 записей на страницу. По аналогии можно сделать для любого типа контента.

1. При обновлении движка на новую версию хак скорее всего слетит, придется прописывать снова.
2. И ждем когда r2 введет такую опцию в типы контента.

+25

← Тип поля для защиты номера телефона для инстант 2 | Тип поля Список со ссылкой →

Комментарии (43)

Val 29 апреля 2015 в 08:10 0

А почему бы в самом начале файла ../system/controllers/content/frontend.php просто не поменять значение const perpage = 15 на любое желаемое?

Loadырь 29 апреля 2015 в 08:23 +1

Val , наверное потому, что ваш вариант применит значение ко всем типам контента, а Zau4man показывает как это сделать только для новостей. И по аналогии можно применить для других типов контента, причём для каждого свои значения.

Val 29 апреля 2015 в 09:11 0

Да, точно

Zau4man:

Так как константа 15 прописана в файле движка, придется применить хак.

это я не внимательно прочитал zst

Тогда другой вопрос))) - зачем делать разное количество записей для вывода в пределах одного сайта? Т.е. для единообразия, вроде как, лучше выводить одинаковое количество записей разных типов контента.

Zau4man 29 апреля 2015 в 09:36 0

Все верно. Если на сайте только статьи, то да. Новости я указал для примера. Мне, например, понадобилось для раздела сайты. Хочу сделать его одной страницей. Вот так

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

Luxin 29 апреля 2015 в 12:32 0

Создание одного компонента для всего контента, наверно самое слабое звено в данной цмс. Чем это обосновывается, не знаю? Хотя в целом движок хорош.

Zau4man 29 апреля 2015 в 12:35 0

Тогда и Битрикс, и Друпал тоже слабые цмс.
Шаблоны, поля у типов контента настраиваются очень гибко, можно сваять многое. А чего нельзя - можно написать свой компонент.

Luxin 29 апреля 2015 в 12:52 +1

ЦМС хорошая, идея совместить весь контент в одном компоненте, неудачная. Если необходимо внести какие-то изменения только для одного контента, то добавляется много лишнего кода, а это дополнительные затраты времени на выполнение движка и вероятность появления лишних ошибок.

r2 29 апреля 2015 в 13:28 +2

добавляется много лишнего кода, а это дополнительные затраты времени на выполнение движка и вероятность появления лишних ошибок

Ага, то есть иметь кучу одинакового кода (просмотр категории, записи, фильтрация, создание, редактирование, удаление) для одинаковых типов контента, отличающихся, по сути, только набором полей, это не "много лишнего" получается? С лишними ошибками то же самое. Править ошибки в одной точке вроде бы проще, чем в десятке разных?

Luxin 29 апреля 2015 в 14:03 +1

Частично Вы правы, если делать в лоб.
ООП помогает этого избежать. А дублирования в коде и так хватает.
Да хотя бы, то решение, что привели в данном блоге - это не дублирование?

r2 29 апреля 2015 в 14:26 0

То есть вас смущает что свою правку нужно обернуть в один IF чтобы она действовала только на нужный тип контента? И вы считаете что иметь отдельный компонент для каждого вида контента (на 98% целиком дублирующий все остальные) это более грамотно чем необходимость обернуть в IF?

Luxin 29 апреля 2015 в 14:48 0

Таких "IF" хватает и в контроллерах и в шаблонах.
Из-за таких "IF" очень много возникает вопросов на форуме, потому что в одном месте учли, а в другом нет.
А дублировать я не предлагаю.
Я только уже писал:

ООП помогает этого избежать.

Расшифрую, если непонятно. Создается класс компонент, а все компоненты наследуются от данного класса, где и реализуется их различие без всяких "IF".
Давно хотел сделать ответвление ветки, но лицензия GPL и моя лень мне мешают. ;)

Luxin 29 апреля 2015 в 15:17 0

Тот, кто знает хорошо php, думаю, что со мной согласятся. Во всяком случае я так реализовал бы, если бы был в команде разработчиков.
Дальше не вижу смысла спорить.
Успехов в развитии.

r2 29 апреля 2015 в 15:34 0

Создается класс компонент, а все компоненты наследуются от данного класса, где и реализуется их различие без всяких "IF"

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

Evanescence 29 апреля 2015 в 17:00 0

Не понимаю из за чего спор smile

но думаю решения очень простая
Добавить поле в настройках контента, допустим perpage (по умолчанию 15)
Потом в \system\controllers\content\frontend.php строку 127

Код PHP:

$perpage = self::perpage;

Заменить на

Код PHP:

$perpage = $ctype['perpage'];

Так у каждого типа контента будет свой perpage

r2 29 апреля 2015 в 17:25 +1

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

Luxin 29 апреля 2015 в 12:24 0

По мотивам темы Количество записей в списке типа контента (2.2.1)

Oleg_z75 29 апреля 2015 в 13:47 0

Luxin # Я в шоке от ваших изречений! А Вы не заметили, что разработчики создали ЦМС (instant 2.х.х) равную платной, хорошей платной цмс по функционалу и я надеюсь, судя по разработкам форума и конструктора форм, что этим дело не закончится. Если Вы такой профи - значит Вы с лёгкостью сможете вырезать с кода, что, что Вам не нужна и написать свой "Нужный" компонент или что то вроде этого. Или я Вас не правильно понял. Поправьте...

Luxin 29 апреля 2015 в 14:11 0

А я что утверждал обратное? То, что ЦМС хорошая, полностью согласен. Разработчики молодцы!
Не ошибается только тот, кто ничего не делает. Я только указал слабое место в этой ЦМС с моей точки зрения.
А соглашаться или нет, каждый решает сам.

Luxin 29 апреля 2015 в 15:06 0

Я не пытаюсь обидеть разработчиков.
Вся критика в рамках улучшения ЦМС.
Для себя я и сам могу исправить.

Колян 29 апреля 2015 в 15:47 0

Почему нельзя сделать по уму? Без этих переходов постраничных, крутишь колесо и подгружаются превьюшки контента по мере прокрутки и не нужно вообще никаких количеств выставлять (про списки пользователей не забыть и мапс)

Val 29 апреля 2015 в 17:11 +1

Вам сюда: http://instantcms.ru/blogs/bitblog/modul-avtopodgruzki-stranic-dlja-instantcms-2-x.html - один из вариантов решения joke

Колян 29 апреля 2015 в 17:59 0

Спасибо! Спасибок накоплю вышлю, а пока плюс.

lokanaft 29 апреля 2015 в 17:50 0

Можно было бы хуком сделать, но всё равно надо идти в файлы и добавлять в манифест строку...

Evanescence 29 апреля 2015 в 18:59 0

А можете подсказать, как с помощью хука, повлиять на запрос?

PIN 29 апреля 2015 в 21:59 0

не понял как собрались хукать. посмотрел, что формирование списка в

Код PHP:

public function renderItemsList(...

начинается раньше штатно вложенного вызова хука

Код PHP:

...
$this->model->limitPage($page, $perpage);
 
		list($ctype, $this->model) = cmsEventsManager::hook(...

lokanaft 29 апреля 2015 в 22:59 0

Посмотрите на приведённый вами же код и догадайтесь сами

PIN 29 апреля 2015 в 23:27 0

Странный разговор... Тогда догадайтесь что я вам сейчас ответил.

Ни каких хуков/хаков не нужно!
Сделать постраничный вывод списка контента с персональным для каждого типа количеством элементов на страницу можно и так. И не надо будет бояться очередного обновления.

r2 30 апреля 2015 в 11:23 +1

в хук передается $this->model, в котором можно переопределить лимит, т.к. непосредственно сам запрос происходит ниже

PIN 30 апреля 2015 в 12:24 0

заметил, поспешил, каюсь

PIN 29 апреля 2015 в 23:49 0

Для тех у кого кипит постраничный вывод с произвольным количеством записей.
Работаем со стилями вывода списка контента: /templates/{шаблон}/content/
далее берём любой стиль списка, например default_list_featured.tpl.php и делаем его копию с новым именем файла, например default_list_featured_43.tpl.php
В самом начале этого фала вставляем:

Код PHP:

<?php 
    $perpage = 43; 
    $content_model = cmsCore::getModel('content');
    $content_model -> limitPage($page,$perpage);
    $items = $content_model->getContentItems($ctype['name']);
?>

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

maxisoft 30 апреля 2015 в 07:24 +1

И это правильное решение? То есть 2 раза дергать базу на получение контента правильно? facepalm

PIN 30 апреля 2015 в 09:51 0

Разве разговор о правильности?! Вопрос избавить себя от рутины при обновлении. С другой стороны +1 повторный запрос на который потратится 0.0004 сек. что-то решает или чему-то мешает? на общем фоне запросов от 40 до 60-ти штук

maxisoft 30 апреля 2015 в 10:36 +1

Честный и открыты подход разработчика, просто откуда взялась цифра 0.0004 сек, откуда взялся 1 запрос, если кол-во запросов будет равно кол-во пользователей, НУ ДА ВСЕХ спасет кеш.

Просто это очередной костыль для решения простой задачи которая и так должна быть в системе. R2 правильно сказал что ее нужно будет сделать по умолчанию, поэтому чем Ваше решение круче предложенного lokanaft - его решение тоже не зависит от обновления системы.

PIN 30 апреля 2015 в 11:21 +1

) "Для тех у кого кипит..." - начало данной ветки, должно было что-то сказать. Или так все пишут когда находят самое правильное решение?!

Сообщение от R2 видел. Давно просили и он подтвердил что это будет реализовано. Просто отлично.

Не ужели выше представленное решение вы противопоставили ... !? shock

хотя я не понял зачем пользователей приплели, ну если надо.. то тогда на фоне суток посмотрим
1 запрос * 1000 пользователей в минуту * 24 часа = 576 сек. в сутки))

Loadырь 30 апреля 2015 в 11:16 0

PIN:

С другой стороны +1 повторный запрос на который потратится 0.0004 сек. что-то решает или чему-то мешает? на общем фоне запросов от 40 до 60-ти штук

Когда на фоне 40-60 запросов, поневоле задумываешься, где их можно сократить, а про добавление очередного дважды приходится подумать, стоит ли оно того. Ваш код действительно спасает от некоторой "рутины при обновлениях". Однако при смене шаблона придётся делать не только новую вёрстку, но и восстанавливать, тот алгоритм который прописан в файлах шаблонов. А представьте, если это будет делать другой человек. Поэтому лучшее решение будет от r2, но на данный момент мне больше нравится вариант от lokanaft.

PIN 30 апреля 2015 в 11:32 0

сам постоянно кошусь на это число, а особенно когда еще и виджеты особо активны. 72 видел как-то.
У R2 все карты. И я за внедрение функции в коробку.
Заплатка есть заплатка. Хотя... каждому шаблону своя длина контента ))), ура!

PIN 30 апреля 2015 в 11:41 0

а самое лучшее решение, если на то пошло, у Zau4man, вставил строчку и без сторонних запросов и переходов все нормально отрабатывает

Loadырь 30 апреля 2015 в 11:53 0

PIN:

если на то пошло, у Zau4man, вставил строчку и без сторонних запросов

точно, я его и имел в виду когда писал слово lokanaft laugh

PIN 30 апреля 2015 в 12:22 0

))

Luxin 30 апреля 2015 в 12:30 0

В системе мало хуков. Было бы больше, многое можно было бы реализовать.
Но хуки такая штука, что на все случаи не предусмотришь. :(

PIN 30 апреля 2015 в 13:56 +2

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

Luxin 30 апреля 2015 в 14:01 +1

Да, это их недостаток.

Старый балбес 30 апреля 2015 в 13:37 0

Решений много, столько будет и толкований.
Не проще считать в конфигурации опций контроллера "content" ключ массива [лимит выборки] для типа контента ?
Ни одного лишнего запроса, нет правок шаблонов, не зависит от обновления,
Для каждого нового типа контента создается - редактируется своя настройка perpage!

Добавить комментарий RSS-лента комментариев