-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I have added the PHP EXIF data reader from [1] to CVS HEAD. EXIF data
display is now turned on by default on the image page. The PHP class I
used is independent of the EXIF PHP library, which would otherwise have
to be linked in (recompile/won't run everywhere).
I have patched the class to some degree to suppress error messages, and
to prevent showing bogus EXIF data where none exists.
As I recall, automatic EXIF data display has been on the "wanted
feature" list for quite some time. So, rejoice! ;-)
Magnus
[1] http://www.vinayras.com/project/phpexifrw.php
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCZ3IHCZKBJbEFcz0RAlzoAJ4gOQMFIyryeoAwgKLfrTiQTSsfXwCdHEKK
HZjMe+DN0lyX7YdjdyKi60o=
=ty/0
-----END PGP SIGNATURE-----
I realized that user:<anyone>/monobook.js pages don't have any kind of
protection. I think it should be protected by default for others then
exact user. Is it possible? I think that you can realize how can it be
used by some intelligent vandals.
Folks,
Angela and Eloquence were in Pretoria, South Africa, between April 19-21
for an International FLOSS and Free Knowledge Workshop run by the
CSIR Open Source Centre, and Angela put out a notice of a meetup.
http://meta.wikimedia.org/wiki/Meetup/Pretoria
We met at the hotel, and then went out to dinner, quite a few people
from the af: wikipedia as well.
Eloquence talked about incremental updates, and followed up with this :-
Regarding the article feed, there's an implementation of the
OAI-PMH protocol currently in use for http://www.answers.com -
see http://www.openarchives.org/OAI/openarchivesprotocol.html
for the specs. As you can see on
http://en.wikipedia.org/wiki/Special%3AOAIRepository, this is
currently limited in access (we are offering it as a service).
This seems to be at a higher level than keeping mysql consistent across
a possibly high-latency connection - it treats the wiki as a repository
of articles, and is a server that will furnish information about the
data, as well as the data itself. I have not looked into it far enough
to see if it supports a reverse feed, but I am sure one-way is a lot
easier :-)
I gather that mediawiki 1.5 will not treat the current version of an
article specially, enabling efficient support of OAI-PMH.
I said I wanted an rsync'able image archive.
Eloquence is a wiki-evangelist (save the world :-), and is currently
promoting [[n:Main Page|Wikinews]]. He obliged me to take another look,
which I have done. It is taking me a little time to get used to it, and
the form-based Search seems a bit puzzling, but an interesting front
page :-)
Angela talked about different language encyclopedia (af: has the most
articles, swahili next). We talked of the problems of prefix-based
languages in wiki markup space - [[sw:ntu]] (a man) should be easy
markup for an intext mention of [[bantu]], meaning men.
Thinking now the easiest thing is to reverse the markup order
Ba[[ntu:sw]] but it seems a bit radical, and has consequences for the
basis of other markup styles like the pipe separator.
There was Wayne Mackintosh, a fascinating guy from University of Auckland,
with eXe :-
The eXe project is developing an off-line authoring environment
to assist teachers and academics in the publishing of web content
without the need to become proficient in HTML or XML markup.
http://exe.cfdl.auckland.ac.nz/
He also needs or has an update protocol for eXe data, and had an interest
in high latency connections, and I refer him to http://www.dtnrg.org/ .
My site http://wizzy.org.za/ deals with email and web content delivery
over UUCP. I also put a wikipedia snapshot down in schools, very handy
(and faster) if schools are not dialed up during the day. If I can carry
the wiki changes over UUCP, I will be happy!
Thanks to CSIR http://www.csir.co.za/ for enabling this.
Cheers, Andy!
Me, Superdialup, will give you:
Free test..
referral bonus,,
browsing crazily fast..
Be my very first referral, and wait for your instant
wealth just in second!http://SuperDialup.com?id=ONHQQC and
find out how fast it is accelerating your browsing speed.
========================================================================================
Akses Internet TELKOMNet-Instan beri Diskon s.d. 50 % khusus untuk wilayah Jawa Timur.
Informasi selengkapnya di www.telkomnetinstan.com atau hub 0800-1-INSTAN (467826)
========================================================================================
Just an initial suggestion...
Maybe we could order a couple AMD machines (i.e. 2 or 3) and test them
out as apaches against the current apahes. If they don't seem to give
us as much preformance/price on apache and search, we just get P4's
for the other 2 or 3. Even if the AMD's are a little lower in
performace (which all AMD benchmarks I've seen in the past 2 years
seem to disagree with) they still might save us enough money to allow
us to justify getting them over the P4s. Of course, we could try and
find volenteers with the exact hardware we want to try and benchmark
the prociessors for us, but I don't think that will happen.
Also, a little off topic, but have we considered using CentOS on our
machines? I just found out about it recently. Basically, it's a
redistribution of redhat enterprise. It's more stable than Fedora so
it might be worth using.
On 4/19/05, Chad Perrin <perrin(a)apotheon.com> wrote:
> On Mon, Apr 18, 2005 at 11:02:20PM -0700, Brion Vibber wrote:
> >
> > Note that my own personal prejudice runs in favor of AMD; I buy Athlons
> > for my home PCs and hiss and boo Intel at every opportunity. But if
> > we're going to make purchasing decisions explicitly based on a
> > price/performance claim I think we need something more than warm fuzzy
> > feelings of fighting The Man.
>
> Plus, y'know, Intel may be The Man in this comparison, but AMD is The
> Other Man.
>
> --
> Chad Perrin
> [ CCD CopyWrite | http://ccd.apotheon.org ]
--
Michael Becker
Hi,
I'm getting a searchindex error when trying to save a particular article after
editing:
> Es gab einen Syntaxfehler in der Datenbankabfrage. Die letzte Datenbankabfrage
> lautete:
> REPLACE INTO `searchindex` (si_page,si_title,si_text) VALUES
> ('1209','it-dokumentation',' [... a big bunch of keywords ...] ')
> aus der Funktion "SearchUpdate::doUpdate". MySQL meldete den Fehler "1062:
> Duplicate entry ' ' for key 3".
When it appeared the first time the trailing remark about where the error
occurred was different (AFAIR, can't reproduce the "first-time-message") saying
also one should try to update the searchindex. Which gives me the same error on
the command line with some more info around:
> >~/tools/php/bin/php -f updateSearchIndex.php
> Updating searchindex between 20050421063319 and 20050422063319
> --- Waiting for lock ---
> Warning: Missing argument 1 for locksearchindex() in
> /home/cddoc/tools/httpd/htdocs/wiki/maintenance/updateSearchIndex.inc
> on line 79
>
> Diba-Tips
> TA-Feedback_JAVA-CodeFormatter
> Loadbalancer_SZZ
> Client-Interface-Philosophie
> AutoHotkey
> News_and_ToDoS_VA
> Dokumentation
> IT-DokumentationA database error has occurred
> Query: REPLACE INTO `searchindex` (si_page,si_title,si_text) VALUES
> ('1209','it-dokumentation',' [... big bunch of keywords ...] ')
> Function: SearchUpdate::doUpdate
> Error: 1062 Duplicate entry ' ' for key 3
>
> Backtrace:
> Database.php line 345 calls wfdebugdiebacktrace()
> Database.php line 297 calls databasemysql::reportqueryerror()
> Database.php line 1057 calls databasemysql::query()
> SearchUpdate.php line 112 calls databasemysql::replace()
> updateSearchIndex.inc line 66 calls searchupdate::doupdate()
> updateSearchIndex.php line 51 calls updatesearchindex()
Any ideas how to get this back to normal? Is there a probated way to just delete
the existing (but obviously somehow corrupted) searchindex and rebuild with the
PHP script afterwards? I would guess "delete * from searchindex where 1" might
be a bit too brutal.
Regards
Philipp
From: Thomas Gries <mail(a)tgries.de>
>http://meta.wikimedia.org/wiki/Email_notification_%28documentation%29#Basics
Thomas,
I see that you added the number of people watching a page to the information on the watchlist page. On en, at least, this would be a security problem.
It would be interesting to be able to find unwatched pages to adopt, but it would make vandalism more durable. I can envision some of the more persitent vandals and vandabots only tampering with unwatched pages, in order to have a more lasting effect. They would still show up in recent changes, but it is much easier to slip past RC patrol than to evade the people who are watching a given page.
Is there any plan to implement this in any of the Wikipedias? Or is this targeted at third party MedaWiki installations? I see your posts on here often. You seem to have done a good job on coding, but I have heard no word on implementation.
Ben
http://meta.wikimedia.org/wiki/Email_notification_%28documentation%29#Basics
I invite you to a very first screenshot of the modified Recent Changes
view of MediaWiki 1.4.2 plus ENotif (e-mail notification) as published
in http://bugzilla.wikipedia.org/show_bug.cgi?id=454 .
Newbies to ENotif should be aware, that a chance exists that they get
puzzled by the view, because the new layout admittedly looks weird at
the first glimpse. However, I developed a reasonable scheme and regard
it as a starting point for further discussions, I need to go through.
Please feel kindly invited to visit the screenshot.
Wikinaut Tom
There seems to be a problem with image dumps. I found only this
ominous file:
http://download.wikimedia.org/wikipedia/en/__imagedump_in_progress.tar
(last modified: 2005-Apr-12)
----
Will the log table be downloadable someday? (I mean the table Special:Log
is based on.)
--
+++ GMX - Die erste Adresse f�r Mail, Message, More +++
1 GB Mailbox bereits in GMX FreeMail http://www.gmx.net/de/go/mail
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
MediaWiki 1.4.2 is a security and bug fix release for the 1.4 stable
release series.
A cross-site scripting injection vulnerability was discovered, which
affects only MSIE clients and is only open if MediaWiki has been
manually configured to run output through HTML Tidy ($wgUseTidy).
Several other bugs are fixed in this release.
All new installations are highly recommended to use 1.4.2 instead of
1.3.x; existing 1.3.x users should consider upgrading for bug fixes and
new features. A 1.3.12 maintenance release is available with the Tidy
fix; the relevant change is in includes/Parser.php.
=== Changes from 1.4.1 to 1.4.2 ===
* Fix math options in Finnish localization
* Use in-process Tidy extension if available when $wgUseTidy is on
* (bug 1933) Fix PATH_INFO usage under IIS with PHP ISAPI module
* (bug 1188) <nowiki> in {{subst:}} includes fixed
* (bug 1936) <!-- comments --> in {{subst:}} includes fixed
* Fix a potential MSIE JavaScript injection vector in Tidy mode
Release notes for 1.4.2:
http://sourceforge.net/project/shownotes.php?release_id=322146
Download:
http://prdownloads.sf.net/wikipedia/mediawiki-1.4.2.tar.gz?downloadhttp://prdownloads.sf.net/wikipedia/mediawiki-1.3.12.tar.gz?download
Before asking for help, try the FAQ:
http://meta.wikimedia.org/wiki/MediaWiki_FAQ
Low-traffic release announcements mailing list:
http://mail.wikipedia.org/mailman/listinfo/mediawiki-announce
Wiki admin help mailing list:
http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
Bug report system:
http://bugzilla.wikipedia.org/
Play "stump the developers" live on IRC:
#mediawiki on irc.freenode.net
- -- brion vibber (brion @ pobox.com)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCZxJewRnhpk1wk44RAj0EAKCKfIGUwsFpSZySXIUFLvqIpXGavgCeIFrN
dEbjqvbZHQBzvfg/+WixDL4=
=5TdO
-----END PGP SIGNATURE-----