I'd like to edit some Wikipedia articles on March 6th from about 9 to 15
o'clock CET (8-14 UTC), and I'd like to do it smooth. So please make
sure that the servers are in top condition and everything's running
really fast.
You think that I'm sounding a bit selfish? You're right, but the problem
is that I'll be in a German tv-studio (3sat) at that time. :-) Please
don't make me sweat and put off experiments until the weekend. Thanks!
Kurt
--
http://leihnetzwerk.de -- Vielleicht hat Dein Nachbar das Buch, das Du
schon immer lesen wolltest - leih es Dir aus!
http://wikipedia.de -- Die freie Enzyklopädie
http://jansson.de -- Icke
>Yes, of course this would be possible. And of course
>people have already
>had this idea. It's just that nobody has gotten around to
>actually
>coding it yet.
Happens sometimes :)
>I imagine this would require some detailed specification
>and planning
>before implementation, or else we run into flexibility
>problems later.
<snip snip>
>It only gets more and more complicated. :)
Some users have expressed their concern about the complexity of WikiSyntax, getting more & more complicated... And this would make it even more complicated ^.^
>Timwi
Nicolas
Somebody today put GetWiki into the user-agent block list. Please don't
do this; that's Wikinfo's import script and it only goes to our
Special:Export.
-- brion vibber (brion @ pobox.com)
"Brion Vibber" <brion(a)pobox.com> schrieb:
> The problem is that pages are purged from the cache when *that page* is
> updated, but the Main Page on en.wikipedia.org has been restructured in
> a way that its content isn't *in* the page. The actual content is
> imported from other pages, and when those pages are edited, *those
> pages* are purged from the cache, but the Main Page isn't.
>
> It's easy not to notice this if you're logged in or doing editing,
> since you'll have engaged a mode that only uses your browser's own
> cache and it's easy to reload, but visitors who have never logged in
> and not edited in this session will see the old cached version from the
> site-wide cache, which gets more and more out of date until somebody
> edits the page or does something else to purge it.
>
> Tim's been working on a fix for this which will record the inclusion as
> a specially-marked link and then including pages can be purged when
> included pages are edited. I'm not sure if this is ready to go yet.
As far as I can see, one does not need to do such edits to get the cache
'corrected' - a forced reload while logged out seems to do the trick as
well. I'm not sure about it, but I cannot remember any case that I did
not get the newest version that way. Now this _could_ mean that there is
simply nobody ever watching our Dutch frontpage, but I do hope that that's
not what's the problem... At the very least, those who want to do an edit
like mentioned above might try the logged out reload first to see whether
an edit is necessary.
Andre Engels
Hello.
I was wondering whether it would be possible or not to have extended {{msg:}}
syntax which could include parameters. Maybe the name of the page (so we could
link to discussion/article page easily), or any user-defined parameter.
The aim would be to use {{msg:}} as a template, so that if you decide to change
something, it'll change on all pages - with specific text to each page.
Example: a {{msg:MovieHeader}} message would do a small table with movie title,
original title, country, duration, director. It'd be inserted in movie articles,
so you could have a quick glance at the movie's 'basic' information, and still
since it's a {{msg:}} it's easy to change the format as needed.
Of course, since bots are becoming powerful, they could be used to replace text
in case of a format change. But it'd be easier.
On the other hand, the syntax for parameters may be harder to understand for a
beginner. Something like {{msg:MovieHeader {title} {country} ...}} may look
confusing ^.^
Just my 2 cents of €
Nicolas 'Ryo'
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I just finished coding an extension that enables deletion of single
revisions of an article. This might be useful for copyright violations.
I added the files to sourceforge in the "feature request" section (id
908150) and attached them to this mail (hope this works via gmane).
The extension enables the following:
- -needs confirmation by the sysop who makes the deletion
- -writes the deleted revision to the "archive" table and
replaces the text of old_text with something like "This
revision has been deleted". Additionally old_user_text is
replaced by "deleted" and the link to the user is removed
(todo: check the username during registration so that noone
can register as "deleted")
- -adds an entry to the deletion log
What is missing:
- -undeletion is not possible (and I have no idea how to
implement this)
Hope this is useful
Regards
Thomas aka Urbanus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFAR8DQUfI+mHkmMg8RAkB6AKCkWplmjjFI/Z/KcynzHi5dAwqi9gCfRALr
4bAstY3EnVCZT3xVO01tViI=
=gCj7
-----END PGP SIGNATURE-----
I've just experimented a bit with ZWiki. ZWiki has a very basic WebDAV
editing capability. That means that I can, say, use the KDE text editor
Kate, select "Open file .." and enter
webdav://zwiki.org/SandBox
to edit the SandBox. Strangely enough that returns an HTML file instead of
the wiki source, but otherwise it works reasonably well -- I can save
directly to the server.
WebDAV can also be mounted via DavFS or gnome-vfs and be treated like a
regular FS. On Windows systems WebDAV folders can be viewed almost like
normal ones (although I'm told that editing files isn't transparent - you
get a local copy which you have to copy to the server manually).
So I think it would be quite neat to have WebDAV editing capabilities for
Wikipedia. Is there someone who wants to take that project? If not I might
hack together a proof-of-concept, but I've got lots of other stuff in my
queue ..
On CPAN I found HTTP::DAVServer - "allows you to write server-side
functions to accept, process and respond to WebDAV client requests." It
appears to hook into the Apache module mod_dav.
The tricky part would be stuff like authentication (the DAV server would
have to reimplement our password hashing function), CUR/OLD table queries
for revision storage, and handling edit conflicts reasonably well (could
use the unix command line tool merge, or various libraries, to generate an
auto-merged version with conflict markers). But I think it's very much
doable, and probably no more than a weekend's work. It could make editing
a lot of more fun and lead to other interesting developments (WebDAV
editing with realtime chat, WYSIWYG ...).
So - any takers?
Regards,
Erik
Hi,
it seems that sysops often submit edits to the Main Page that don't
actually change anything, and in their edit summary they give vague
indications of caching problems.
Now apparently they came up with the idea of placing an HTML comment in
the Main Page, <!-- cache purging value: red-->, and keep changing that
word ("red" in this case) to something else.
This strikes me as a major pollution of the article history as well as
wasted effort.
What is this all about? What is the caching problem? Can it not be
solved by technical means?
Thanks,
Timwi
We had some discussion about this on nl: since several people have related
problems recently.
Yesterday I experienced this on XP - MSIE 6:
A page was clearly out of date, the last edits I saw on the history page
were not showing.
Refresh didn't work. So I cleared the whole MSIE cache.
Low and behold the next refresh produced a page that was even older than the
one I already had.
Missing all updates after Feb 28 (It is our 'Village pump' page, updated
frequently).
Might it be that one of the squids does not realize its content is obsolete?
Erik Zachte