What I'd like to do is convert the PHP setting of "$wgCategoryPagingLimit" into something we can apply to our categories.
So you want to control the number of category members displayed on a Category page? Hmm... that would take some heavy duty CSS/JS, I think. It might be better to look into using DPLforum (enabled on all Wikia wikis) or DPL (you need to ask Wikia to enable it on your wiki). This allows you to filter and control the listing of pages by several criteria.
It would be much easier just to ask staff if they're willing to change the setting, although I imagine it's set to 200 due to pageloads or server strain.
As far as DPL goes, it's relatively easy to pick up. With the extension installed something like
<DPL> category=CATEGORYNAME offset= </DPL>
will output 500 pages in your category, bearing in mind the category name is case sensitive. If you have more than 500 pages in the category repeat the code above and change the offset to 500. Just repeat until you have all the members of the category in the list. The full manual can be seen here.
Thank you both for your help! I'll keep this in mind if this is the way our wiki decides to go.
At our wiki (w:c:wot) we have two sides to our categories: Real-world and In-universe. For this function, I'm more focused on In-universe content.
We have about 520 categories there. Of those, seven are not able to be displayed on one page with at least one category a few pages away from the limit. Those seven categories range from 211 pages up to 969 pages. With the release of a new book in January, as well as actually getting all of the pages created, I would estimate that three to five more categories would reach the 200 limit.
I know that, relatively speaking, even ten categories over the 200 limit isn't a lot.
Pecoes, you've helped me out recently with the category sort option, and this is related to it. If I can get the limit raised, the code you wrote would be utilized on all of our categories instead of selectively.
This isn't something that needs to be done right away, as I'm still waiting on a discussion about this to end. I'm just trying to explore all of our options, and to see if anyone had any code that did something similar. I don't expect that we'll do this, but I wanted to see what was available.
That's all within reasonable limits. You should contact Staff and ask them to increase $wgCategoryPagingLimit for you. Since you have a good idea how many categories would be affected and how much growth you can expect in the forseeable future, you should be able to make a strong case for your request. Your situation is definitely an edge case. Your category tree is too large to neatly fit within the limits. But it's also too small to cause trouble if the limits were raised.
As an addendum to our previous discussions: It is possible to gather the off-page category data with JavaScript and add it to the entry page, but that's slower and more resource-intensive than simply raising the cap. Given the choice staff would surely prefer the latter.
How much more resource-intensive would it be? To give you an idea, I have never had any of our pages take more than a second or two to load up on the various computers I've used. I've also used the sorting JavaScript on some of the large pages and it seemed to change over instantly.
The sorting is not the problem. The problem is that the script would have to make one or more API requests to fetch all the category members. The script that I wrote for you only sorts. It does not collect any off-page data. That's why it's fast.
If I were to add that, the script would still be reasonably fast, but you would start to notice it. You would be able to see the page change while it loads. It wouldn't be dramatic, but noticeable. The main stress would be on the server side however. That's why I said staff might be interested in helping you avoid such dirty hacks.
In case they do tell you this is impossible, you might want to ask them what they're opinion on circumventing that limitation with JavaScript is...
EDIT: I should add that I'm not familiar with the DPL extension. If the DPL extension offers an easy solution, go for it :)