Sounds like #4488, or not?

Nope. The issue is, that I send a GET request in the frontend with no start parameter in the pagination set for the first page. (Compared to a POST in the backend) That means that it will still retrieve the data from the session and that will be non-zero as long as some other page has been visited. We don't have that issue in our core extensions in the frontend, because we don't call JModelList::populateState().

I know, but it is broken in 3.3.6 and reverted in staging. In staging and before 3.3.6 this works fine.

Is this still an open issue then?

This is indeed still an issue. While in the backend, you can do a parent::populateState() and have most stuff taken care of, this will break your component in the frontend and for example prevent pagination from working.

Resetting to open

Is anyone fixing this?

I doubt that someone is working on this right now. It is not easy to solve, when I looked into it.

I don't know if related but try to set e.g. limit = 2; directly to frontend populateState and see that nothing actually happens. The same goes for any other filter as well (e.g. catid). On the other hand, at backend everything works as expected. Please verify that problem indeed exists.

The issue is, that the backend expects a form to be submitted via POST with the values when moving through the pagination, while the frontend uses GET URLs instead. This is not easily solvable currently. The best bet would be to fix this with new MVC classes.

How do you explain the following:
$limit = $app->getUserStateFromRequest('global.list.limit', 'limit', $app->getCfg('list_limit'));
$limit = 2;
$this->setState('list.limit', $limit);

I would expect to get only 2 items but that's not the case...
It's like parent::populateState overrides everything else...

Sorry if I miss the forest here but I am really confused

One difference between front- and backend is that the backend uses the session (UserState) to store the current value. That means if you don't pass a limit, the value from the session is used.

It's like parent::populateState overrides everything else...

Yes, parent::populateState will set the limits again, overriding your value. See https://github.com/joomla/joomla-cms/blob/staging/libraries/legacy/model/list.php#L551

If you need to adjust them different in your extension, you need to do it after that call.

So is this a bug or we just need to abandon in are code the use of the set state?

It's not a bug that parent::populateState does set the limit. It's part of the job of that method.

You can set your own limits after you have called the parent method, or you just don't call it in your own method.

Hello @Hackwar

Thank you for your contribution.

The last comment here was on February 17th. So the question is, Is this issue/pull request still valid?
If no reply is received within 4 weeks we will close this issue.

Thanks for understanding!

closed as per the last comment