MediaWiki-l December 2011

mediawiki-l@lists.wikimedia.org

62 participants
55 discussions

Problem updating mediawiki
by Marlen Caemmerer 09 Dec '11

09 Dec '11

Hello, I try to run maintenance/update.php. It always fails with this error: Your system has a combination of PHP and libxml2 versions which is buggy and can cause hidden data corruption in MediaWiki and other web apps. Upgrade to PHP 5.2.9 or later and libxml2 2.7.3 or later! ABORTING (see http://bugs.php.net/bug.php?id=45996). But my versions are quite new: # php -v PHP 5.3.8 (cli) (built: Dec 7 2011 21:07:33) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies and: # ldd `which php`|grep xml2 libxml2.so.2 => /opt/ts/lib/libxml2.so.2 # ls -l /opt/ts/lib/libxml2.so.2 lrwxrwxrwx 1 root root 16 Dec 9 2010 /opt/ts/lib/libxml2.so.2 -> libxml2.so.2.7.8 Do you have any ideas what else could cause this output? Is it possible that PhpXmlBugTester() is not working simply because a PHP compile time option is not enabled? Cheers Marlen -- * Marlen Caemmerer * Richard-Sorge-Str. 82 monoro * 10249 Berlin * * Tel: 0179/733 90 72 USt-ID: DE 252684276

2 3

Memory issue
by John W. Foster 09 Dec '11

09 Dec '11

I snipped this from the terminal screen when I was running runjobs.php Seems I have a memory issue & I,m not sure what I need to do to fix it. System has 8Gb of ram so I don't think that is the problem. Perhaps a setting in PHP or Mediawiki 1.17. Any tips? frosty

1 0

Upgrade to 1.18
by Gordon Joly 07 Dec '11

07 Dec '11

I have Mediawiki installation went from 1.17 through 1.18 RC1 and to 1.18 - no problems. But another Mediawiki has had some problems going direct from 1.17 to 1.18 - I took out Recaptcha and now see this: *Fatal error*: Cannot redeclare wfprofilein() (previously declared in /xxxxxxxx/public_html/includes/profiler/Profiler.php:14) in */xxxxx/public_html/includes/ProfilerStub.php* on line *25* Not sure why... Gordo -- Gordon Joly gordon.joly(a)pobox.com http://www.joly.org.uk/ Don't Leave Space To The Professionals!

9 21

Re: [Mediawiki-l] Does wikipedia use different methods to compute the hash part of an image path?
by Daniel Friesen 06 Dec '11

06 Dec '11

You could also use Special:FilePath. Definitely a good idea. We long for a day when we can eliminate the current way we organize files and do things like renaming a file in the ui without having to rename files, handling paths in a way that don't suffer from negative caching effects and make it so the url of an old file version is the same as when it was the main file, and maybe even possibilities like using only one file instead of multiples when two files have the same contents. Those kind of changes we could make in the future would completely destroy clients that hardcode this kind of handling.me On Tue, 06 Dec 2011 06:40:12 -0800, C Stafford <c.stafford(a)gmail.com> wrote: > You may be more future proof by asking the API for the image url, > rather then trying to figure it out your self, as each wiki install > may have other factors that determine that director/hash structure > (i've seen places that have 3 levels, not 2) > > http://en.wikipedia.org/w/api.php?action=query&prop=imageinfo&iiprop=url&ti… > > On Mon, Dec 5, 2011 at 6:25 PM, Tommy Chheng <tommy.chheng(a)gmail.com> > wrote: >> I'm computing the url of an image by the following: >> (the md5 of the first char and the second two chars concat) >> >> val md = MessageDigest.getInstance("MD5") >> val messageDigest = md.digest(fileName.getBytes) >> val md5 = (new BigInteger(1, messageDigest)).toString(16) >> >> val hash1 = md5.substring(0, 1) >> val hash2 = md5.substring(0, 2) >> >> val urlPart = hash1 + "/" + hash2 + "/" + fileName >> >> Most of the time, the function works correctly but on a few cases, it >> is incorrect: >> >> For "Stewie_Griffin.png", I get 2/26/Stewie_Griffin.png but the real >> one is 0/02/Stewie_Griffin.png >> >> The source file info is here: >> http://en.wikipedia.org/wiki/File:Stewie_Griffin.png >> http://upload.wikimedia.org/wikipedia/en/0/02/Stewie_Griffin.png >> >> Any ideas why the hashing scheme doesn't work sometimes? >> >> I posted this question on stackoverflow but I might be able to get a >> better answer >> here.http://stackoverflow.com/questions/8389616/does-wikipedia-use-differen… >> >> -- >> @tommychheng >> http://tommy.chheng.com >> >> _______________________________________________ >> Mediawiki-api mailing list >> Mediawiki-api(a)lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/mediawiki-api -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

2 2

Re: [Mediawiki-l] MediaWiki-l Digest, Vol 99, Issue 5
by Ron Laufer 06 Dec '11

06 Dec '11

> On Mon, Dec 5, 2011 at 8:18 AM, Ron Laufer <gonzoron(a)hotmail.com> wrote: > > > > > I had the Replace_Text extension working fine until the upgrade to 1.18. > > I reinstalled the latest version of the extension (version 0.9.1), and > > it's showing up in Special:Version, > > but the page: > > http://fraternityofshadows.com/wiki/Special:ReplaceText > > is missing. > > > > Missing how? Does it say "no such special page"? Or "only users in this > group can perform this action: administrators"? Or do you see a blank white > page with no text or user interface at all? (check your error log / error > reporting settings in php.ini) > > Also, try 0.9.2 (the now-latest version)? > > -- brion Missing as in, if I wasn't not logged in as an admin, I got "only users in this group can perform this action: administrators", as expected. But if I _was_ logged in as an admin, I got an http 500 error. But regardless, installing 0.9.2 did the trick. Thanks! Ron -- Ron Laufer

1 0

Some problems after 1.17 / 1.18: DatabaseFunctions.php and addMessage()
by Eric K 06 Dec '11

06 Dec '11

There's two issues I'm having after upgrading from 1.16.5 to 1.18.0: 1. Some people (including me) had included "DatabaseFunctions.php" in their extensions, for example by doing: include_once './extensions/DatabaseFunctions.php'; 1.17 took that file out (file: History): === Configuration changes in 1.17 === * DatabaseFunctions.php that was needed for compatibility with pre-1.3 extensions has been removed. I was using the database functions for example: $my_query = wfQuery($this_query, DB_WRITE); I can fix that temporarily by copying that file and using it but I want to work with whatever is "new" now so I dont use any old methods. 2. I'm also getting this in a few extensions: Fatal error: Call to a member function addMessage() on a non-object in [...]/extensions/MetaDescriptionTag.php on line 72 That function is being used like this: $wgMessageCache->addMessage Anyone know any workarounds? I'm going to work on it in any case in the next few days and will report back if I'm successful.

2 2

Re: [Mediawiki-l] Custom Namespace hidden from search
by Sal Quintanilla 06 Dec '11

06 Dec '11

I'd like to create a custom namespace that isn't searchable. Defaulting search to be disabled for the namespace is easy with $wgNamespacesToBeSearchedDefault, but is there a way to keep it from showing up under the Search options of "my preferences"? This is for an intranet site, so I don't have any problem completely hiding the Search options tab for setting namespaces to search. But I do need the preferences available to users for other reasons. It would be nice to be able to accomplish this without editing any mediawiki files. I'm using MW 1.16. Thanks for reading. Sal

2 4

Wiki migration
by Stephen Berg (Contractor) 05 Dec '11

05 Dec '11

I've been tasked to migrate a MediaWiki install (V 1.5.6) to a new server. I suppose I could just install the older version but I'd rather migrate if it's possible. Is the jump from 1.5.6 to the current 1.18.0 too big a jump? I was planning on dumping the database from the old server and importing to the new if that is possible. I don't have a lot of experience here but if that will then I should be able to copy in all the images from old to new and be pretty much done. This wiki doesn't have any add-ons, just a basic wiki for some of my users to collect and share information. -- Stephen Berg Systems Administrator NRL Code: 7320 Office: 228-688-5738 stephen.berg.ctr(a)nrlssc.navy.mil

7 7

Mysql ISAM vs InnoDB
by Jim Hu 05 Dec '11

05 Dec '11

$wgDBtransactions gets set to true if using InnoDB tables. Is there an advantage to using InnoDB tables? The disadvantage is that with MySQL there is a file, ibdata1, that seems to grow endlessly if InnoDB tables are used. See http://bugs.mysql.com/bug.php?id=1341 We're wondering if we should just convert everything to MyISAM. Any thoughts? ===================================== Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054

4 4

Re: [Mediawiki-l] Context weirdness
by Lee Worden 05 Dec '11

05 Dec '11

> From: "John W. Foster" <jfoster81747(a)verizon.net> > On Sun, 2011-12-04 at 22:09 +0100, Platonides wrote: >> > On 01/12/11 00:51, John Foster wrote: >>> > > My mediawiki 1.17 installation as gone nuts. It is not correctly >>> > > identifying things where the first letter context has changed. example: >>> > > Template: tlx call does not find Template:Tlx In the past this has made >>> > > no difference. >> > >> > Did you change $wgCapitalLinks to false? > I did indeed, as per the instructions at the WorkingWiki site. I have > been advised by the author that it is actually not necessary, but for > now the damage is already done, so I will just leave it& clean up the > issues. > I would appreciate any advice as to which way is best...context > sensitive or not. It wont matter once I get finished using templates > built by others that I've borrowed from other sites. I intend to never > allow content that depends on shortcuts or acronyms and I like the > titles of everything to begin with caps. Just a personal thing LOL. > Thanks for the reply. If you prefer titles beginning with caps, you probably prefer $wgCapitalLinks = true. In that case, your WorkingWiki project titles will also begin with capitals, because they're implemented as page titles. Otherwise, as far as I can recall, it makes no difference to WW. I apologize for not being more clear in my installation instructions. I've improved them now. Did you take a backup before running cleanupCaps.php? If you did take one, you may be able to undo the damage by restoring from backup and changing $wgCapitalLinks back to true. Lee Worden >> > >>> > > Only recent changes are installation of the >>> > > Extension:WorkingWiki. The extension seems to be doing its job though there >>> > > are some issues with Latex (.sty) sheets. I just do not know if the >>> > > WorkingWiki, which did alter the editing interface, is the cause. I will be >>> > > contacting the author re: this. >> > >> > I don't think Extension:WorkingWiki would have changed the >> > $wgCapitalLinks setting for you, but it's easy to test: Comment the line >> > including the extension and check if it now works. >> >

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

MediaWiki-l December 2011