Good addition! I like it
@test: Works fine for me

Yes, PR works, BUT
Just to be mentioned. There are views in frontend that use this option as default for limit box (e.g. contact single catgeory).
It should be established an additional option in com_config like list_limit_frontend to avoid frontend crashes.

@bertmert Does this change break any extension? In my tests, it doesn't. Even in the frontend the new setting works.

There should be established an additional option like list_limit_frontend to avoid frontend crashes.

I wouldn't add a new option. The parameter already is meant to be used in frontend.
"All" rarely is a good selection, that's why it currently isn't in the list. But we could of course add it, it's just one a user never should use

"All" rarely is a good selection, that's why it currently isn't in the list. But we could of course add it, it's just one a user never should use

Well, I would use it. One extension I use implemented their own pagination using Ajax, which doesn't work with my template override. So I just want it to display all items at once. That would be possible with this change.

This option is a GLOBAL behavior. So it changes the limits site wide when adjusted. I agree that "All" isn't a good option in this context. It's an option that should be overridden at the component level when components really need or want to provide that option at their level. For component developers, it's a matter of setting the list.limit value in the model state before the pagination object gets created.

"Does this change break any extension?"
Core components com_search (results), com_contacts (single category), com_tags(?) don't have an own option for frontend like "display_num" like in com_content (category list).

Thus these views try to show ALL results/items when a user opens this views in frontend the first time. Earliest as a second step user can set custom value in limit box that's written in his/her session for next visit. If no limit box is displayed user has no chance to get rid of waiting for all results.

Now, it could be discussed if "normal" backend user is aware that this setting is also for some frontend views. I remember that I needed some time then ;-))

@Bakual Yes, you're right. Additional global option for frontend would be to much.

I agree that "All" isn't a good option in this context.

What if someone wants his lists to be longer than 100 items by default? Could we at least add some greater values like 500 and 1000?

I reverted the part of the feed limit (it makes no sense there).
Hopefully we can agree on some solution for list limit.

What if someone wants his lists to be longer than 100 items by default? Could we at least add some greater values like 500 and 1000?

Are we talking about 500 or 1000 articles per page? That doesn't sound like something anyone ever wants to do. Even 100 is far more than is reasonable.
Or are we talking about a specific extension where that would make sense. Then what Michael said is true, it should be provided on a per extension basis and you shoudl contact the extension developer to see if he can get that fixed.

That doesn't sound like something anyone ever wants to do. Even 100 is far more than is reasonable.

Well, in my scenario it does make sense. Why would you not let the user decide that? I'm not talking about changing the default, just allowing greater values.

You have a list in frontend with 100+ articles from com_content?

No, from RSEvents. It's a list with archived events. Their pagination doesn't work for me.

So isn't that a bug with RSEvents then?

Option "All" is added to Default List Limit but not to Default Feed Limit.
The new list limit applies only after beginning a a new session (Logout/Login).

Same here: Only after re-login the "all" limit is set as default in e.g. article view.

Tested Patch suchessfully

Thanks for testing - I am setting this to Needs Review based on @bakual comments so that CMS maintainers can make a decision IF this is really something that should be applied

For me option ALL is still nonsense as long some frontend views use this setting as default. AND as long as

"Core components com_search (results), com_contacts (single category), com_tags(?) don't have an own option for frontend like "display_num"..."

The test added All to the list, but did not make it default in the articles.

tested successfully.
setting "all" the first time, it didn´t work. Log Out, Log in. Now ist works fine.

it works fine
this feature was already available in Joomla 2.5 used it quite often

Tested patch successfully.

We've been down this path before and ran into issues.
Setting the limit to unlimited is not a good idea. It will make extensions crash, also core.
Has this been tested on setups with 50.000 articles?

An unlimited approach would only make sense if results are loaded via ajax in chunks, like Google Images does for instance. But loading 100+ items in a list view is asking for trouble.

Also, many extensions will trigger events for each item returned (like the category blog page). That means that certain plugins will also be triggered 100+ times!

Can we then at least add some greater values to choose from? Maybe 500 or 1000? That at least should not break the site, but would be enough for most cases.

As you have stated your issue is specific to one extension and you should take that up with that extension.

Multiple people have stated very good reasons why a global setting of ALL (and other high values) are bad ideas.

I am closing this