![]() |
Portals ![]() | |||||||||
|
@ Mr. Stradivarius: The recent changes to this module cause every portal that is missing a page to show up in Category:Pages with script errors. What should we do about this? Jackmcbarn ( talk) 23:07, 4 December 2014 (UTC)
@ BrownHairedGirl: Thank you for your recent addition of the subpage tracking code. :) I noticed that in Template:Portals with subpages count tracking category you have commented out categories for subpage counts of 51–100, 101–200, 201–500, 501–1000, and >1000, presumably because checking for them would exceed the expensive function count. How about using the shortcut of only checking the boundary pages exist, instead of checking that every page exists? The algorithm would go something like this:
This way you use at most 13 expensive function calls - one for each category. However, there is the drawback that the algorithm won't work properly if there are gaps in the subpage numbers. For example, if a portal has subpages #1, #3 and #4, but #2 doesn't exist, then the algorithm will put it in the "less than 2" category, when it should be in the "2–5" category. Let me know if you think this would be an acceptable trade-off or not. Best — Mr. Stradivarius ♪ talk ♪ 06:17, 2 May 2019 (UTC)
|max=
parameter; if we can find the highest subpage number from the exponential search, then we can use that for both the subpage tracking category and the random page generation, and save portal maintainers the trouble of keeping track of the number of subpages themselves. To give you an idea of how the algorithm works, consider a page with five subpages: #1, #2, #3, #4 and #5. If we start checking at subpage #1, it will work like this:
|max=
parameters anyway, if we decide that this is a good idea.) Let me know what you think. Best —
Mr. Stradivarius
♪ talk ♪
09:05, 3 May 2019 (UTC)
I've been trying to fix the expensive parser functions limit at Portal:San Francisco Bay Area, but it isn't behaving at all like how I expected. When commenting out one Random portal component call it reduces the count by one but if comment out two it removes however many subpages there are. Changing the amount of subpages used does nothing. I have no idea why this is happening and some help would be appreciated. Maybe a mode without checking if the page exsist would be useful? -- Trialpears ( talk) 22:25, 22 September 2019 (UTC)
![]() |
Portals ![]() | |||||||||
|
@ Mr. Stradivarius: The recent changes to this module cause every portal that is missing a page to show up in Category:Pages with script errors. What should we do about this? Jackmcbarn ( talk) 23:07, 4 December 2014 (UTC)
@ BrownHairedGirl: Thank you for your recent addition of the subpage tracking code. :) I noticed that in Template:Portals with subpages count tracking category you have commented out categories for subpage counts of 51–100, 101–200, 201–500, 501–1000, and >1000, presumably because checking for them would exceed the expensive function count. How about using the shortcut of only checking the boundary pages exist, instead of checking that every page exists? The algorithm would go something like this:
This way you use at most 13 expensive function calls - one for each category. However, there is the drawback that the algorithm won't work properly if there are gaps in the subpage numbers. For example, if a portal has subpages #1, #3 and #4, but #2 doesn't exist, then the algorithm will put it in the "less than 2" category, when it should be in the "2–5" category. Let me know if you think this would be an acceptable trade-off or not. Best — Mr. Stradivarius ♪ talk ♪ 06:17, 2 May 2019 (UTC)
|max=
parameter; if we can find the highest subpage number from the exponential search, then we can use that for both the subpage tracking category and the random page generation, and save portal maintainers the trouble of keeping track of the number of subpages themselves. To give you an idea of how the algorithm works, consider a page with five subpages: #1, #2, #3, #4 and #5. If we start checking at subpage #1, it will work like this:
|max=
parameters anyway, if we decide that this is a good idea.) Let me know what you think. Best —
Mr. Stradivarius
♪ talk ♪
09:05, 3 May 2019 (UTC)
I've been trying to fix the expensive parser functions limit at Portal:San Francisco Bay Area, but it isn't behaving at all like how I expected. When commenting out one Random portal component call it reduces the count by one but if comment out two it removes however many subpages there are. Changing the amount of subpages used does nothing. I have no idea why this is happening and some help would be appreciated. Maybe a mode without checking if the page exsist would be useful? -- Trialpears ( talk) 22:25, 22 September 2019 (UTC)