![]() | This project page does not require a rating on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | ||||||||||
|
Glitch?
I've noticed something very strange. Here's an example (from a real incident):
There are 61 stubs in Colorado road transport. I look at the graph; it say they are 66. Now here's the fishy part: I go into the history and see the diff between Imzadi's and Fredddie's edit, and I see there are 61 in that revision. What's going on? I see nothing Imzadi could have done to change it. --PCB 23:04, 11 April 2010 (UTC)
- The current version shows 61. Try purging the cache on the page if necessary to force it to reload. Imzadi 1979 → 23:07, 11 April 2010 (UTC)
- Now its changed, and its better. --PCB 23:40, 11 April 2010 (UTC)
- With anything that relies on other pages (templates that are transcluded, or numbers called through the parser function here), refreshing the browser or purging the cache for the page will usually solve display issues. The servers will call a current copy when you enter the edit screens, but the cached version that the server sends to your browser for regular display may be out of date. Sometimes all that is needed is to refresh the page on your end because the server has cached an updated version of the page, but sometimes you'll need to purge the cache yourself to get the updates. Imzadi 1979 → 23:47, 11 April 2010 (UTC)
Another glitch. As of this moment, the stub count is the FA count. (The number of FAs is shown in the stub column.) --PCB 04:00, 12 April 2010 (UTC)
- We're testing something, it will be reverted shortly. Imzadi 1979 → 04:07, 12 April 2010 (UTC)
All classes?
The number of stubs for each project is on this table. Would it be possible to add all the remaining classes to the table, from FA to start? Just looking at this from an automation perspective. If this table is providing "live" updates as all the assessment categories change, then it'd be possible to changes to all classes in somewhat real time. (I assume there is coding that looks at the other assessment categories anyway, in order to calculate the wikiwork stats.) A full table could possibly replace the current main table, eliminating the need for someone to run a bot or manually update that one on a regular basis. -- LJ ↗ 22:04, 20 April 2010 (UTC)
- It's not technically possible. The original live table attempted that, but ran into parser function limits halfway between across the North Dakota row of the table. That was plan A, and this is plan B as you see it.
- The full story is that there can only be 500 PAGESINCAT calls on the page. Each line called each of the 7 classes 5 times each, and the total was well over a thousand for the full table. Reducing the table to the current format reduced the parser calls under the limit. Now, if this were a table for CRWP, it would be possible to have a full, live updating table. Imzadi 1979 → 22:08, 20 April 2010 (UTC)
- I didn't realize that had already been tried...makes sense that it would have been though. Well, that sucks. -- LJ ↗ 01:07, 21 April 2010 (UTC)