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
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
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!
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]
> 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
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.
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
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
$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
> 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.
>> >
