Page MenuHomeMiraheze

DPL3 request: Set max results to 2,500
Closed, ResolvedPublic

Description

O.K., so now that I'm on a brief reprieve from dictionary-entry imports (pretty long story)...

As extension users will know/have known, DynamicPageList3's default result maximum is 500, long a disadvantage for wikis with higher page counts. In my case, the English-Tovasala entries in my site's conlang dictionary partially depend on two control lists--the General Service List (GSL) from the 1950s, and the much more recent but now-defunct Landau Universal Vocabulary (LND)--whose item count each hovers above 2,000. To make sure DPL3 more or less adequately covers all of their headwords in the long term, I propose a safety-net threshold of 2,500 results for that wiki (unless constraints, technical or otherwise, intervene). (At least now that an upgrade occurred last month...)⊙

This is only the beginning of my DPL3 wishlist; I already pointed out a smattering of other unaddressed shortcomings at MediaWiki last August. (Yes, I know the original developers have recently gone AWOL...) As an aside, I also have my next (long overdue) PageForm to see about, but that's for another filing.

As I've expressed before on MW, a handy, useful extension that deserves far more attention/promotion (absent Semantic MediaWiki, whose issues on Miraheze have been documented elsewhere).

Once again, many thanks!

⊙ See this resolved GitHub filing for the relevant issue at hand.

Event Timeline

Unknown Object (User) removed a project: Extensions.Oct 22 2021, 20:01
Unknown Object (User) closed this task as Resolved.Oct 22 2021, 21:05
Unknown Object (User) claimed this task.

To @Universal_Omega: Think you'll have to reopen this filing. Because while "maxResultCount" may have been set, the stats on my Dictionary's front page (and in one of its categories) are still bricked out at 500 for whatever reason. Can you or some ally of yours please investigate?

Unknown Object (User) closed this task as Invalid.EditedOct 30 2021, 08:31

There is an issue with this with DPL3 itself it would seem. I'm looking into it within DPL3, but no task needs to be opened on Miraheze for upstream issue.

I will hopefully have an answer and/or cause of this within a week.

Unknown Object (User) added a comment.Oct 30 2021, 08:36

In the meantime I have switched the config to allowUnlimitedResults which I have verified does work while testing.

Paging @Universal_Omega once again (along with @RhinosF1):

Think I've finally figured out what's causing the tally constraints upstream (and the clues might have been under my nose the whole time): count in "ParametersData.php" is set at the default 500, and needs to be raised (locally or otherwise) to get the correct result(s). (As discovered by "Karsten" back in April 2016, and [as part of the same GitHub filing mentioned above] "DesignerThan95" on July 24 this year. A similar problem was encountered back in May by @Ilias_Siachos [T7282].)

Maybe the folks at Test3 should give this a try to see what happens?

Reopening on a dare, now that a solution has already been suggested above, and a week has passed since the transition to 1.37.

Unknown Object (User) added a comment.Dec 15 2021, 17:31

Paging @Universal_Omega once again (along with @RhinosF1):

Think I've finally figured out what's causing the tally constraints upstream (and the clues might have been under my nose the whole time): count in "ParametersData.php" is set at the default 500, and needs to be raised (locally or otherwise) to get the correct result(s). (As discovered by "Karsten" back in April 2016, and [as part of the same GitHub filing mentioned above] "DesignerThan95" on July 24 this year. A similar problem was encountered back in May by @Ilias_Siachos [T7282].)

Maybe the folks at Test3 should give this a try to see what happens?

We can't modify the file locally, as we use submodules. However I do maintain DPL3 upstream. I was almost certain. I fixed this issue awhile ago and confirmed it worked. I will give it a further look though.

Unknown Object (User) added a comment.Dec 15 2021, 19:14

I looked at this again, and maxResultsCount is working. You just aren't using it. It's not meant to change the default count, you need to set |count=2500 to go beyond the default 500 count.

I looked at this again, and maxResultsCount is working. You just aren't using it. It's not meant to change the default count, you need to set |count=2500 to go beyond the default 500 count.

Ah...I get it now! (count has to be enabled in the DPL calls to get it right.) I think you may be a bit of a godsend here yet.

At least everything is back to normal layout-wise (at least in my dictionary entries)--which reminds me of another (already reported-on) issue: DPL3 doesn't seem to respect what's in the {{DEFAULTSORT}} field, meaning page sorting is a lot amiss. Furthermore, as I've recently discovered through ExpandTemplates, its Unicode/UTF-8 support leaves much to be desired--especially when titleregexp comes into play.

But as always, that's for another time, another filing, another forum. (If any other interested developers are out there reading this, then they know where to start.)

Unknown Object (User) closed this task as Invalid.Dec 15 2021, 20:29

At least everything is back to normal layout-wise (at least in my dictionary entries)--which reminds me of another (already reported-on) issue: DPL3 doesn't seem to respect what's in the {{DEFAULTSORT}} field, meaning page sorting is a lot amiss. Furthermore, as I've recently discovered through ExpandTemplates, its Unicode/UTF-8 support leaves much to be desired--especially when titleregexp comes into play.

But as always, that's for another time, another filing, another forum. (If any other interested developers are out there reading this, then they know where to start.)

I will look into all that within DPL3 itself. Thanks for bringing it up. While actually looking to maxResultsCount before I realised the issue, I did notice that allowUnlimitedResults actually doesn't work, so https://github.com/Universal-Omega/DynamicPageList3/pull/70 should fix allowUnlimitedResults as well. The other issues I will investigate. Thanks! Closing as invalid as no SRE intervention required.

Unknown Object (User) changed the task status from Invalid to Resolved.Dec 15 2021, 20:29
Unknown Object (User) moved this task from Backlog to Short Term on the MediaWiki (SRE) board.
Unknown Object (User) moved this task from Unsorted to Short Term on the Universal Omega board.

Moving to resolved as we did set the config, excluding the issue you had.