I've added two new lists to focus some of the discussion around the XML
Database dumps
Xmldatadumps-admin-l <-- An operations centered list where Dumps
failures, updates, changes will be mailed
Xmldatadumps-l <-- General discussion list
--tomasz
Hi,
Is the rollback feature available to sysops MEANT to remove all the
consecutive contributions of a certain user? Shouldn't it erase just the
latest change?
Here is an example:
http://ro.wikipedia.org/w/index.php?title=Facultatea_de_Mecanic%C4%83_a_Uni…
changes marked with "Revenire
la ultima modificare..." are made using this feature). You can see that it
reverted 2 or 3 versions back.
Thanks,
Strainu
Hi!
I've developed my extension and I am not yet sure it's stable enough to
be uploaded to MediaWiki SVN. Also, I don't have SVN commit access,
and I am not sure that I will be able to continuousely support my
extension
in the future (to make sure it will be compatible with the future
versions
of MediaWiki).
I've created a documentation page for my extension at mediawiki.org,
then tried to upload tgz archive with it. But, MediaWiki refuses such
upload by default, and there's no way to enable it besides adding
some obvious settings to LocalSettings.php file (I've done it for
my local wikis).
In #mediawiki IRC channel I've been told that tgz upload is insecure
and poses a risk.
I am a bit in doubts about that. First of all, tgz files are so much
integral part of unix/linux distributions, that most of possible
overflow
and injections bugs should be fixed already.
Second, anyway, user has to follow a some link (let's say on the
external site). Risk (if there's any?) isn't really going away.
Dmitriy
Hi all,
I am trying to upgrade an old mediawiki installation (version 1.5.8) to
the latest version, following the upgrade instructions here:
http://www.mediawiki.org/wiki/Manual:Upgrading_to_1.14
I backed up the database and files from the old installation and
unpacked the new version over the top of my existing installation using
the following command:
tar xvfz mediawiki-1.14.0.tar.gz -C /path/to/my/wiki/ --strip-components=1
I then updated AdminSettings.php to be my root mysql user, changed to
the maintenance directory and ran:
php update.php --aconf ../AdminSettings.php
This gave me the following output:
> # php update.php --aconf ../AdminSettings.php
>
> MediaWiki 1.14.0 Updater
>
> Going to run database updates for ccbi_micklem
> Depending on the size of your database this may take a while!
> Abort with control-c in the next five seconds...0
> ...have ipb_id field in ipblocks table.
> ...have ipb_expiry field in ipblocks table.
> ...already have interwiki table
> ...indexes seem up to 20031107 standards
> ...hitcounter table already exists.
> ...have rc_type field in recentchanges table.
> ...have user_real_name field in user table.
> ...querycache table already exists.
> ...objectcache table already exists.
> ...categorylinks table already exists.
> Already have pagelinks; skipping old links table updates.
> ...have rc_ip field in recentchanges table.
> ...image primary key already set.
> ...have rc_id field in recentchanges table.
> ...have rc_patrolled field in recentchanges table.
> ...logging table already exists.
> ...have user_token field in user table.
> The watchlist table is already set up for email notification.
> ...watchlist talk page rows already present
> ...user table does not contain old email authentication field.
> ...page table already exists.
> ...have log_params field in logging table.
> logging table has correct log_title encoding.
> ...archive table does not exist, skipping new field patch
> ...have page_len field in page table.
> revision timestamp indexes already up to 2005-03-13
> ...rev_text_id already in place.
> ...have rev_deleted field in revision table.
> ...have img_width field in image table.
> ...have img_metadata field in image table.
> ...have user_email_token field in user table.
> ...archive table does not exist, skipping new field patch
> ...page_namespace is already a full int (int(11)).
> A database query syntax error has occurred.
> The last attempted database query was:
> "SHOW COLUMNS FROM `archive` LIKE 'ar_namespace'"
> from within function "".
> MySQL returned error "1146: Table 'mywiki.archive' doesn't exist
> (localhost)".
When I then browse to the wiki I get the following error:
from within function "Job::pop". MySQL returned error "1146: Table
'mywiki.job' doesn't exist (localhost)".
Having failed on this tack, I wiped everything and restored from backup
to attempt "Alternative 2". The web installed gave the following output:
Checking environment...
/Please include all of the lines below when reporting installation
problems./
* PHP 5.2.5 installed
* Found database drivers for: MySQL
* PHP server API is apache2handler; ok, using pretty URLs
(index.php/Page_Title)
* Have XML / Latin1-UTF-8 conversion support.
* Session save path (/var/lib/php/session) appears to be valid.
* PHP's memory_limit is 128M.
* eAccelerator <http://eaccelerator.sourceforge.net/> installed
* Found GNU diff3: /usr/bin/diff3.
* Found ImageMagick: /usr/bin/convert; image thumbnailing will be
enabled if you enable uploads.
* Found GD graphics library built-in.
* Installation directory: /var/www/WIKI
* Script URI path: /wiki
* Installing MediaWiki with php file extensions
* Environment checked. You can install MediaWiki.
*
*Generating configuration file...*
* Database type: MySQL
* Loading class: DatabaseMysql
* Attempting to connect to database server as ccbi_wiki...success.
* Connected to mysql 5.0.27; enabling MySQL 4.1/5.0 charset mode
* Database mywiki exists
* There are already MediaWiki tables in this database. Checking if
updates are needed...
* *Warning:* you requested the mysql5-binary schema, but the
existing database has the mysql4 schema. This upgrade script can't
convert it, so it will remain mysql4.
* *Warning:* you requested the InnoDB storage engine, but the
existing database uses the MyISAM engine. This upgrade script
can't convert it, so it will remain MyISAM.
...have ipb_id field in ipblocks table.
...have ipb_expiry field in ipblocks table.
...already have interwiki table
...indexes seem up to 20031107 standards
...hitcounter table already exists.
...have rc_type field in recentchanges table.
...have user_real_name field in user table.
...querycache table already exists.
...objectcache table already exists.
...categorylinks table already exists.
Already have pagelinks; skipping old links table updates.
...have rc_ip field in recentchanges table.
...image primary key already set.
...have rc_id field in recentchanges table.
...have rc_patrolled field in recentchanges table.
...logging table already exists.
...have user_token field in user table.
The watchlist table is already set up for email notification.
...watchlist talk page rows already present
...user table does not contain old email authentication field.
...page table already exists.
...have log_params field in logging table.
logging table has correct log_title encoding.
...archive table does not exist, skipping new field patch
...have page_len field in page table.
revision timestamp indexes already up to 2005-03-13
...rev_text_id already in place.
...have rev_deleted field in revision table.
...have img_width field in image table.
...have img_metadata field in image table.
...have user_email_token field in user table.
...archive table does not exist, skipping new field patch
...page_namespace is already a full int (int(11)).
This script does not seem to have finished and there was no LocalSettings.php created. When I moved the LocalSettings.old.php to LocalSettings.php and browse to the wiki I get the following error:
from within function "Job::pop". MySQL returned error "1146: Table 'mywiki.job' doesn't exist (localhost)".
So thats it, I'm currently stuck at version 1.5.8 :(
Does anyone have any idea how I can get past this and upgrade to the latest version? Please do not hesitate to ask if you need more information to debug this.
Many thanks in advance,
Dan T.
Hello,
I have been looking at some of the bugs relating to PostGreSQL, and have
found that I am not sure if some of them could be considered to be bugs
with MediaWiki. For example
https://bugzilla.wikimedia.org/show_bug.cgi?id=16937
As they relate to it not working with a particular version of PostGreSQL
which is 7 years old or so.
Do we have a minimum version of PostGreSQL that MediaWiki should work
with?
Regards
--
Karun Dambiec
karun(a)fastmail.fm
Brion Vibber <brion <at> wikimedia.org> writes:
> $wgUploadUrl is set incorrectly on this site to "images" instead of
> "/ProjectWiki/images".
>
> This reliative URL is resolved by the browser from /ProjectWiki/index.php
> ok, but not by anything else -- your code snippet simply adds a "/" on
> the front, making it "/images". (Note this will also fail if
> $wgUploadUrl is a fully-qualified URL, such as on sites which serve
> their images from a separate domain.)
>
I think you mean $wgUploadPath instead of $wgUploadUrl.
I found nothing about $wgUploadUrl at
http://www.mediawiki.org/wiki/Category:Upload_variables
Adding the starting slash if not existent was only a quick and dirty
workaround, because at first the problem seemed to be a missing slash
in the middle of the URL. Maybe no good idea.
The Wiki sysop told me he had to set $wgUploadPath="/images" (or "images"?)
to get another extension to work. I thought this would cause no problems:
Uploads go to the new directory http://robertfant.com/images (or better,
one of its subdirectories) and files are retrieved by getURL() from the
same place. Seems not to be true. New uploads still go to
http://robertfant.com/ProjectWiki/images/<subdir>/subdir>/... Why?
Just for sake of clarity:
What is the difference between $wgUploadPath="/images" and
$wgUploadPath="images"?
What will the Wiki sysop have to do that uploaded files go to the same place
where my extension will retrieve them?
Does it help to change both $wgUploadPath and $wgUploadDirectory?
How did you know so quickly about the content of $wgUploadPath without
access
to LocalSettings.php? Maybe there is a Special:XYZ page showing the content
of all $wgXYZ variables.
--Rudi
http://www.formelapplet.de