I just added a "special:maintenance" page to the CVS. The purpose is to provide a collection of useful functions to keep the 'pedia running smoothly and to find some often occuring obstacles.
Currently, it is limited to sysops only, as some of the functions use quite some resources. So, if anyone updates the live site, it won't collapse;) (Can somebody please check if I added that page to the sidebar in the standard skin? I know I did it for CologneBlue, which is now the standard skin;)
Existing functions on that page are: * Find articles that REDIRECT to a REDIRECT. I didn't include an "autofix" function - too dangerous, I suppose, without further testing. WARNING: This function uses the LIKE SQL statement to look for "#REDIRECT %"! * Find articles that link to themselves. Nice and fast one. Lists many user pages, though, if they signed it somewhere... * Find article that explicitely link to their own "Talk:" page. Also quite fast. * Uploaded files and where they are used. By popular demand;) WARNING: This uses LIKE "%URL%" for *every* uploaded file!!! Also, it might not work on all filenames, especially those with special chars. Needs serious workover.
BTW, I noticed that when I edit an existing article (not a new one, strangely), I am not logged in for that page, and I don't have the "minor change" option as a result. Hitting "Preview" logs me in again. I couldn't reproduce that on my local copy. Can anyone please check?
Magnus
On Sunday 16 June 2002 11:19, Magnus Manske wrote:
I just added a "special:maintenance" page to the CVS. The purpose is to provide a collection of useful functions to keep the 'pedia running smoothly and to find some often occuring obstacles.
Currently, it is limited to sysops only, as some of the functions use quite some resources. So, if anyone updates the live site, it won't collapse;) (Can somebody please check if I added that page to the sidebar in the standard skin? I know I did it for CologneBlue, which is now the standard skin;)
How about finding users who haven't contributed anything, but upload files?
phma
How about finding users who haven't contributed anything, but upload files?
Nice idea, but what if they learn to edit/save a page, changing nothing (or leaving their own "signature")? Or they fill their user page with random stuff?
I think the soultion for the upload page is as follows: * Only certain file types are allowed (JPEG/JPG/PNG, maybe) * We need a better way to link to images ([[image:xyz.jpg]], for example), so we can maintain a list of used images * A better structure is needed for storing these files (S/ST/STUFF.JPG instead of just stuff.jpg, for example) * A better "recent uploads" page. The log page is a total mess :(
This should make it easy to get rid of the vandals and still keep the "good guys" going:) But, this seems to be better suited in the new codebase (hear me, Lee?:)
Magnus
On Sun, Jun 16, 2002 at 06:34:37PM +0200, Magnus Manske wrote:
I think the soultion for the upload page is as follows:
This "solution" is very bad, I already told it to lcrocker (author of the new codebase), I'm only going to repeat it now.
- Only certain file types are allowed (JPEG/JPG/PNG, maybe)
All formats should be allowed, including: * sounds * movies * scripts * tarballs * any other multimedia files that might happen to be useful at some point * any other type of files
- We need a better way to link to images ([[image:xyz.jpg]], for example),
so we can maintain a list of used images
* not every file is image * it will break linking from more than 1 wikipedia
- A better structure is needed for storing these files (S/ST/STUFF.JPG
instead of just stuff.jpg, for example)
If you ever happen to have performance problems, just switch to reiserfs. It easily handles hundreds of thousands files in single directory. But I wouldn't expect problems with ext2 to appear anytime soon.
And it's bad solution because you'll get badly balanced tree, with some subdirectories having many times more files than others.
If you seriously think about tree structure, you should use substr(md5($name),0,2) - that is 256 well-balanced subdirectories.
On Sunday 16 June 2002 12:34, Magnus Manske wrote:
How about finding users who haven't contributed anything, but upload files?
Nice idea, but what if they learn to edit/save a page, changing nothing (or leaving their own "signature")? Or they fill their user page with random stuff?
AFAICT the most prolific uploaders of junk never contribute anything - they're looking for a place to upload files and probably did a web search for "upload". If they learn to edit a page, they may start contributing something useful, and if they don't, we can deal with them as regular vandals.
I think the soultion for the upload page is as follows:
- Only certain file types are allowed (JPEG/JPG/PNG, maybe)
- We need a better way to link to images ([[image:xyz.jpg]], for example),
so we can maintain a list of used images
- A better structure is needed for storing these files (S/ST/STUFF.JPG
instead of just stuff.jpg, for example)
- A better "recent uploads" page. The log page is a total mess :(
I think there should be a page listing all the existent files, their size, and what the "file" command says they are (which may not correspond to their extension, as in aNUK). It should be sortable by filename, date, size, filename reversed, and uploader.
phma
On dim, 2002-06-16 at 08:19, Magnus Manske wrote:
BTW, I noticed that when I edit an existing article (not a new one, strangely), I am not logged in for that page, and I don't have the "minor change" option as a result. Hitting "Preview" logs me in again. I couldn't reproduce that on my local copy. Can anyone please check?
That's the same old cookie path problem that makes going to http://www.wikipedia.com/ not show up as logged in. Assuming that the running software includes the fix by now, just log out and log back in.
Or, play with your browser's cookie file and change the path for the Wikipedia cookies from /wiki/ to /.
-- brion vibber (brion @ pobox.com)
wikitech-l@lists.wikimedia.org