Are there any signigicant server load issues relating to extensive use of
templates or use of templates within templates on a mediawiki installation?
What (if anything) relating to use of templates would be bad for server
load?
The following changes have been made in the Python Wikipediabot
framework in the last 2 weeks (since January 19, to be precise). The
bot can be downloaded at
http://cvs.sourceforge.net/viewcvs.py/pywikipediabot/pywikipedia/; for
each change it is specified which version of which file is needed.
Later versions are always okay too. I will try to upload
BUGFIXES (please download when using the specified bot):
For all bots (change in Wikimedia software makes submitting impossible
otherwise):
* wikipedia.py 1.391
* login.py 1.21 (security fix: login.py does not show login data on the screen)
For bots using categories:
* catall.py 1.11
* category.py 1.29
* category.py 1.30 (only outside wikimedia)
For interwiki.py:
* titletranslate.py 1.35 (when used for years)
For specific wikis:
* wiktionary_family.py 1.20 (on Sicilian Wiktionary or Wiktionary interwiki)
NEW BOTS
* pagefromfile.py: Reads a file consisting of a (large) number of wiki
pages, and submits those to the site. Currently being used on the
Sicilian Wiktionary. Strangely, this goes wrong on non-ASCII
characters on Windows 2000, but works correctly on Windows XP (not
checked on Linux yet).
MAJOR CHANGES
* New system for waiting after an edit. The new system also looks at
the time the previous edit took, and the number of bot processes you
are running. In most cases the new version will wait less than the old
one, but if the Wiki is slow or if you are running many bot processes,
it will be slower. You need to upload new versions of all bots you
use, because otherwise they will not remove themselves from the list
of running bot processes when they are ended! (basic: wikipedia.py
1.394, config.py 1.41 * separate bots: brackethttp.py 1.8, catall.py
1.12, category.py 1.61, check_extern.py 1.10, config.py 1.39,
copy_table.py 1.26, editarticle.py 1.17, extract_wikilinks.py 1.5,
find.py 1.3, getimages.py 1.7, imageharvest.py 1.4, imagetransfer.py
1.25, interwiki.py 1.133, login.py 1.22, mediawiki_messages.py 1.21,
pagefromfile.py 1.6, pagelist.py 1.17, recirect.py 1.18, replace.py
1.34, saveHTML.py 1.5, solve_disambiguation.py 1.124, splitwarning.py
1.4, sqldump.py 1.16, standardize_interwiki.py 1.5, table2wiki.py
1.60, template.py 1.11, test.py 1.17, touchall.py 1.4, upload.py 1.19,
us-states.py 1.9, warnfile.py 1.13, wikipedia.py 1.392,
windows_chars.py 1.19)
* New functionality for imageharvest.py, which can now be used to get
a number of images where the URL the same except for a numerical part
(imageharvest.py 1.3)
* New option on extract_wikilinks.py to get the pages sorted by title
(extract_wikilinks.py 1.4)
* The -wiktionary option for interwiki.py now works for capitalised
wiktionaries too (titletranslate.py 1.37)
* summaries in Portuguese added (catall.py 1.10, redirect.py 1.17)
* bot can be used on wiki.mozilla.org (family mozilla) (mozilla_family.py 1.2)
MINOR CHANGES:
* contents has been updated (CONTENTS 1.35)
* Spanish titles of day pages added (date.py 1.17)
* namespace names in Spanish (family.py 1.19)
* bot does not ask for copyright and source when uploading (lib_images 1.61)
* removing a resolved issue in nl-exceptions (nl-exceptions.dat 1.21)
we have been having serious problems with spam on meta for now two days.
Each time I block the ip and delete the pages. They are recreated.
So, I kept the pages and protected them, but the spam moved on to other
pages.
What should we do ?
Anthere
Angela (beesley(a)gmail.com) [050207 07:07]:
> We can host them. We just can't allow anyone to upload potentially
> dangerous files. See Brion's email on this when pdf was first
> disallowed: http://mail.wikipedia.org/pipermail/wikitech-l/2004-September/025472.html
Oh, good lord. TEXT is forbidden?!
/me curses IE's crackmonkey authors
Looks like if I want SVG uploads on Commons I'll need to write a
mathematically-watertight validity checker myself. Barring no new exploits
found that use perfectly valid SVG files. Grah!
- d.
The Main Page on en: was vandalized yesterday, when a penis image
remained on the page for many minutes. It was vandalized again today
-- a goatse image remained there for almost /20 minutes/.
Today it happened during a particularly slow time of the morning,
around 14:35 UTC, perhaps in combination with other use of the site
that slowed it down. It was noticed quickly, but it took a good 17
minutes for it to be successfully deleted once the problem had been
announced on IRC, by the seemingly-omniscient Jimmy Wales.
While everyone was fretting over the site's slowness, a few problems
presented themselves:
* There was no one-click way to remove or delete an image
* There was no packaged way to shut down all access to the site in an emergency
* There was no packaged way to quickly redirect all visitors (to en:,
say) to another site or page
* There was no way to bring the site[s] to (or restart the site in) an
'emergency mode' that only allowed limited access (say, by logged-in
users)
** Even had there been such a way, there were few (only 1-2) people
with shell access who would have been able to run shell scripts, and
it took an extra minute or two to get someone's attention.
* There were a limited number of ways to reach the collection of devs
to let them know there was an emergency.
This was not the worst emergency in the world, so the last point in
particular was not as big a deal as it might have been.
===========
Possible solutions:
1) Documentation: write down a standard way to quickly block all
incoming requests / take down a site in an emergency / put up in its
place a try-back-soon message or redirection to a static snapshot (see
3)
2) Code: add an 'emergency mode' that redirects all visitors to a
static read-only snapshot of the site taken once a day
2.1) Code: add a text-only mode that only produces text
2.2) Code: add a one-click (js widget?) option [maybe 2 clicks with
some kind of pop-up confirmation that doesn't require rendering
another whole WP-page] so that even when the site is very slow, evil
images can be deleted in under 15 minutes
2.3) More Code: add a different 'emergency mode' that only allows a
limited set of users [logged-in users? users on a specific list?] to
use the site.
3) Code + Image Policy: add an IMAGE REVIEW step that imposes a time
delay (or requires user approval) before an image can be displayed
live on a page [until then the image could still be linked to via an
html link]
4) Offer pagers <s>and implantable homing devices</s> to devs who are
going to be in the vicinity of computers anyway and are willing to be
on-call for certain parts of the day; something more reliable than the
blinking of an IRC window.
============
1), 2), and 3) seem important to me. 2) also has useful
implications for periods of deep sloth, and for taking things down to
make changes. 3) addresses many problems we are having, not just on
the main page.
Please comment or suggest implementations.
--
+sj+
I can't get the bot to handle wpEditToken correctly. It worked
correctly before, but now it always gets preview instead of submit
pages.
I added code to find the wpEditToken, and to send it with the post,
but that had no result.
Here are the data that were sent in one attempt:
wpSave=1&wpPreview=0&wpSummary=robot%20%20Erbij%3Aen%2Cja%2Cda&wpTextbox1=%27%27%27Lord%20Howe-eiland%27%27%27%20is%20een%20%5B%5Beiland%5D%5D%20van%20%5B%5BAustrali%EB%5D%5D%20en%20werd%20in%20%5B%5B1982%5D%5D%20op%20de%20%5B%5BWerelderfgoedlijst%5D%5D%20geplaatst%20vanwege%20zijn%20zeldzame%20collectie%20van%20planten%2C%20vogels%2C%20zeeleven%20%28%5B%5Bkoraal%5D%5D%29%2C%20en%20uitzonderlijke%20natuurlijke%20schoonheid.%0D%0A%0D%0AHet%20is%20%E9%E9n%20van%20slechts%20vier%20eilandengroepen%20die%20tot%20%5B%5BWerelderfgoed%5D%5D%20is%20uitgeroepen.%0D%0A%20%0D%0AHet%20eiland%20is%20te%20bereiken%20door%20een%20vliegreis%20van%202-uur%20vanaf%20%5B%5BSydney%5D%5D%20of%20%5B%5BBrisbane%5D%5D.%0D%0A%0D%0A%3D%3DExterne%20link%3D%3D%0D%0A%2Ahttp%3A//www.lordhoweisland.info/%0D%0A%0D%0A%5B%5Bcategorie%3AAustrali%EB%5D%5D%0D%0A%5B%5Bcategorie%3AEiland%5D%5D%0D%0A%5B%5Bcategorie%3AWerelderfgoed%5D%5D%0A%0D%0A%5B%5Bda%3ALord%20Howe%20Island%5D%5D%0D%0A%5B%5Ben%3ALord%20Howe%20Island%5D%5D%0D%0A%5B%5Bja%3A%26%2312525%3B%26%2312540%3B%26%2312489%3B%26%2312539%3B%26%2312495%3B%26%2312454%3B%26%2323798%3B%5D%5D%0D%0A&wpSection=&wpEdittime=20050204103625&wpMinoredit=1&wpWatchthis=0&wpEditToken=16061ded2f1a5b0b
Andre Engels
In trying to run the code currently in HEAD, I find that it needs a
table called "group". Is there a mechanism for building this table?
Barring that, is there information on what the table is supposed to
look like?
-Rich Holton
__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail
Here's a patch to add the smart block table query from HEAD to
mediawiki 1.4beta. The current implementation is painful when checking
if logged in users are on the block list as the query cannot use
indexes and has to scan the entire table, which is apparantly causing
big pain for en.wikipedia. Please apply.
--
Frank v Waveren Fingerprint: BDD7 D61E
fvw(a)[var.cx|stack.nl] ICQ#10074100 5D39 CF05 4BFC F57A
Public key: hkp://wwwkeys.pgp.net/468D62C8 FA00 7D51 468D 62C8
Dear firends,
I need some (4-5) simple [[meta:Write your own MediaWiki extension]]s.
One example:
<UNDERSCORES> respektive </UNDERSCORES> to replace all spaces in a text with underscores. The result would be used in same context as {{PAGENAMEE}} for the generation of direct links to existing MediaWiki functions.
Please let me know in which of the following languages you would like to have the specifications, explanations etc.:
English, German, Esperanto, Romanian.
Thanks in advance for your efforts
Regards
Reinhardt [[User:Gangleri]]