Cobalt still memorizes pagination page between categories/search queries

Scheduled.

This topic shows the "solved" icon, but the problem still consists in latest Build 9625...

Changing category may not work but new search have to work.

Changing category may not work

Does not work ...

It was working, but now with latest update, the problem came back ... Please check again ...

Is any solution for this problem, when changing category?

but it's not a solution :(

If I would try to solve it, that is what I would do. What ideas do you have?

Sergey, а не может это все быть из-за того, что переменная limitstart хранится в сессии? Вот что у меня в сессии, если я хоть раз зашел на следующую страницу в каталоге кобальта.

registry ⇒ {"global":{"list":{"limit":5}},"com_cobalt":{"records1":{"filter":{"section_id":1},"limitstart":"5"},"fields":{"ordercol":null,"limitstart":"5"},"categories":{"ordercol":null,"limitstart":"5"}},

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

Странно, проверил как работает пагинация у других компонентов и ни один не посылает переменную limitstart в сессию, максимум отсылают limit. И непонятно в какой именно момент, в кобалте вылезает три раза limitstart в сессию. Вот мой эксперимент с решением пагинации. В component/com_cobalt/views/record/view.html.php строка 576, на данный момент там код:

        $key = sprintf('com_coblat.limit.%s_%d', $this->list_template, $this->section->id);

        $tmpl_default = $params->get('tmpl_core.item_limit_default', $glob_def_limit);

        $limit = $app->getUserStateFromRequest($key, 'limit', $tmpl_default);

        $app->setUserState('global.list.limit', $limit);

        JRequest::setVar('limit', $limit);

я поменял его на данный вариант кода:

        $key = sprintf('com_cobalt.limit.%s_%d', $this->list_template, $this->section->id);

        $tmpl_default = $params->get('tmpl_core.item_limit_default', $glob_def_limit);

        $limit = $app->getUserStateFromRequest('$key', 'limit', $tmpl_default, 'int');

        $limitstart = JRequest::getVar('limitstart', 0, '', 'int');

        JRequest::setVar('limit', $limit);

         JRequest::setVar('limitstart', $limitstart);

и вроде полет нормальный.... если не учитывать что переменной limitstart вообще не должно быть в сессии. Проверял на шаблоне simple_list, шаблон blog гн проверял.

Ну этого не может быть. Смотри в фале модели records.php есть

$context = $this->context;

$this->context .= $app->input->getInt('section_id');



$orders = explode(' ', $this->section->params->get('general.orderby'));

parent::populateState($orders[0], @$orders[1]);



$this->context = $context;

Я подменяю контекст что бы он относлся к разделу а то получается в одном разделе поставил 20 на страницу это применяется и к другому разделу. Ведь у джумлы ключ лимита и лимитстарта глобольный и один.

$value = $app->getUserStateFromRequest($this->context . '.limitstart', 'limitstart', 0);

$limitstart = ($limit != 0 ? (floor($value / $limit) * $limit) : 0);

$this->setState('list.start', $limitstart);

Вот так в родительском классе в методе parent::populateState назначается лимитстать и это сессия. Так что если компонент нативный и использует технологи джумлы лимит старт по любому окажется в сессии.

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

Я подумаю счас и если что поправлю в сделющей версии.

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

Так что я вернул все назад :)

1) Не понял насчет проблемы с сортировкой у меня вроде все правильно работает или мы о разном говорим?

У меня создано две секции с 2 категориями в каждой. Если в секции 1 я делаю сортировку по заголовку от большего к меньшему, то все мои статьи будут представлены в списке от 9 до 1. Сортировка сохраняется при переключении страниц внутри данной секции/категории и при переходе между категориями секции.

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

2) По поводу того, что лимит становится глобальным для всех секций, это я заметил, но как по мне, так это менее раздражает :), чем то что страница не сбрасывается на первую при входе в секцию/категорию + можно использовать infinite scroll, для того, что бы подгружать статьи без переключения по страницам.

"Тем более у нас на каждый раздел своя переменная." - не понял этого... Переменная разная, если для разделов использовать не одинаковые шаблоны. Если две секции с одинаковыми шаблонами (допустим simple_list), то настройки шаблона не будут индивидуальными для каждой из секции, а значит и лимит будет равным.

В моем примере для первой секции Автобусные туры я выбрал шаблон simple_list и лимит поставил 4 статьи, для второй секции Чартерные туры я выбрал шаблон default и лимит поставил 3 статьи. Если быть в секции Автобусные туры то лимит будет всегда 4 статьи, если перейти в секцию Чартерные туры то лимит будет 3 статьи, вроде все как надо, сортировка тоже запоминается для конкретной секции. Беда начинается тогда, когда в любой из секций, в переключателе limit box вручную выбрать лимит допустим 10, то тогда он станет глобальным и уже во всех секциях будет применяться только он. Но эта беда, как я уже писал выше менее раздражает, чем не переход на первую страницу, просто запретить этот limit box и нет проблем :D

Мои тестовые категории тут http://jm.cuberra.eu/

P.s. Пр**** нап****сан******** коментар****ев, постоянно глюк с буквой "и" в русском языке и буквой "b" в англ****йском языке. Результат глюка понятен ****з данных предложен****й :)

Добавил в строку 122 файло модели records.php

JRequest::setVar('limitstart', JRequest::getInt('limitstart', 0));

Это должно решить пробелму.