I have aparantly done something with the navagation bar setting of a
global nature. It is showing up on the left side of the screen but below
the page/article content. I have tried to figure this outbut so far im
striking out.I have also been unable to find any docs that assist in
correcting this. I suspect I have somehow altered some setting, but I'm
not sure where to even look. Any help or ideas are appreciated.
Thanks!
--
John Foster
I would like to convert my wiki to use a MySQL database. It currently
uses a SQLite database. I don't know of any scripts in the maintenance
directory.
I would like to convert because of the broken SQLite search.
The wiki I am talking about is below.
Darren VanBuren
onekopaka(a)gmail.com
----------------------------------------------
Administrator of Onekopakaspace
Trunk MediaWiki install:
http://oks.verymad.net/~onekopaka/mwtrunk/
I'm using the well known StringFunctions extension but if I do, my
error logs fill up with:
PHP Notice: Use of undefined constant MW_PARSER_VERSION - assumed
'MW_PARSER_VERSION' in .../StringFunctions/StringFunctions.php on line
160
The offending part of StringFunctions.php is:
function mwSplit ( &$parser, $str, &$chars ) {
# Get marker prefix & suffix
$prefix = preg_quote( $parser->mUniqPrefix );
if( isset($parser->mMarkerSuffix) )
$suffix = preg_quote( $parser->mMarkerSuffix );
line 160: else if ( strcmp( MW_PARSER_VERSION, '1.6.1' ) > 0 )
$suffix = 'QINU\x07';
else $suffix = 'QINU';
I'm running 1.12.0. I find it hard to believe I'm the only person
running StringFunctions on this version.
GD.
Hello List,
currently I am adopting the PreviewGallery Gadget originally developed by Magnus Manske.
Now I have a problem with the API.
Is it possible to get the Timestamps from Images like in the query.php?
The old version was:
query.php?what=categories&clextended&format=xml&titles=Bild:LC80.JPG
This creates the following Output: (as you can see with "timestamp" in the cl branch)
<yurik>
<perf>
<total startup="271" dbtime="1.2" time="294.7"/>
<pageInfo dbtime="0.7" time="22.4"/>
<categories dbtime="0.5" time="1"/>
</perf>
<pages>
<page>
<ns>6</ns>
<title>Bild:LC80.JPG</title>
<id>243</id>
<touched>20080625085045</touched>
<revid>797</revid>
<categories>
<cl ns="14" sortkey="Bild:LC80.JPG" timestamp="2008-06-25 08:50:45">Kategorie:Plattform 1</cl>
<cl ns="14" sortkey="Bild:LC80.JPG" timestamp="2008-06-25 08:50:45">Kategorie:Prospektfotos</cl>
</categories>
</page>
</pages>
</yurik> ......
Now with the NEW Api I am trying the following:
api.php?action=query&prop=categories&clprop=sortkey&format=xml&titles=Bild:LC80.JPG
I am getting almost the same, but not the timestamps:
<api>
<query>
<pages>
<page pageid="243" ns="6" title="Bild:LC80.JPG">
<categories>
<cl ns="14" title="Kategorie:Plattform 1" sortkey="Bild:LC80.JPG"/>
<cl ns="14" title="Kategorie:Prospektfotos" sortkey="Bild:LC80.JPG"/>
</categories>
</page>
</pages>
</query>
</api>
The official Documentation of the API tells me to use "clprop" as a parameter to "prop=categories" but it always throws the error "<error code="clunknown_clprop" info="Unrecognised value for parameter 'clprop'"/>" after appending "clprop=timestamp" to my calling routine.
Is there somebody who can help me?
Dipl.-Inform. (FH) Tobias Heilmannseder
Softwareentwickler
In a nutshell, I've upgraded a previously working 1.5.(1?) install to
1.12.0. It seemed to go smoothly, and everything's there with no
discernible errors, but pages are taking some 20 s. to come back.
I'm not running any caching, but there are 4 wikis on this [CentOS 5] box
running under Apache virtual servers, one at least of which has been 1.12.0
for a bit and doesn't show any slowness with no caching.
I've compared the LocalSettings.php files for the OK one and my slow one,
and there's nothing obviously different that might affect this.
Bizarrely, we have a development box alongside the production one which
ought to be identical (they actually both virtual boxes on the same hopst(s)
just to confuse matters), and my wiki runs at a decent rate on that one.
Same versions, I've copied the d/b across (mysqldump --add-drop-tables), and
compared the entire 'wiki' subdirs. No obvious diff.
The only advertised diff. between the production box and the dev. one is
that the production box uses SELinux.
*Also*, I have found that I can ‘remove’ the speed problem by using
“$wgUseDatabaseMessages = false;“ (from a google around the issue).
However, the MediaWiki docs imply that this would be obviated by using
caching, and I have tried memcached temporarily, and it seemed to make no
difference at all.
I'm now down to analysing a strace of a php session between the working
wiki and mine.
Just for completeness, here's a bit of my strace that displays a lag.
Note that I can find no ref. to ‘Revision.php’ in the strace of the working
one. Also, just prio to this there's mention of ‘MediaWikiBagOStuf...’ and
then ‘MessageCache::loa...’ in what I think is a channel to mysql. There's
no mention of MessageCache, bar one to the .php file, in the working strace.
Does anyone have any ideas about what I can look at next?
----
time(NULL) = 1214560045
lstat64("/var", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/var/www", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/var/www/fwwiki", {st_mode=S_IFDIR|0770, st_size=4096, ...}) = 0
lstat64("/var/www/fwwiki/wiki", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
lstat64("/var/www/fwwiki/wiki/includes", {st_mode=S_IFDIR|0775,
st_size=12288, ...}) = 0
lstat64("/var/www/fwwiki/wiki/includes/Revision.php", {st_mode=S_IFREG|0664,
st_size=22430, ...}) = 0
open("/var/www/fwwiki/wiki/includes/Revision.php", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0664, st_size=22430, ...}) = 0
lseek(4, 0, SEEK_CUR) = 0
read(4, "<?php\n/**\n * @todo document\n */\n"..., 8192) = 8192
brk(0x8c54000) = 0x8c54000
read(4, "er = isset( $row[\'user\'] "..., 8192) = 8192
read(4, "o external storage if required\n\t"..., 8192) = 6046
read(4, "", 8192) = 0
read(4, "", 8192) = 0
close(4) = 0
nanosleep({1, 213780000}, NULL) = 0
<snip lots of these>
nanosleep({1, 70533000}, NULL) = 0
access("/var/www/fwwiki/wiki/serialized/MessagesEn.ser", F_OK) = -1 ENOENT
(No such file or directory)
access("/var/www/fwwiki/wiki/languages/messages/MessagesEn.php", F_OK) = 0
stat64("/var/www/fwwiki/wiki/languages/messages/MessagesEn.php",
{st_mode=S_IFREG|0664, st_size=188674, ...}) = 0
time(NULL) = 1214560066
--
[neil@fnx ~]# rm -f .signature
[neil@fnx ~]# ls -l .signature
ls: .signature: No such file or directory
[neil@fnx ~]# exit
get the following error after upgrading from 1.11 to 1.12 (PHP
version 5.1.2, msql version 5.1.11) in the apache error log:
"[Thu Jun 26 09:51:45 2008] [error] [client 77.121.145.109] PHP Fatal
error: Class 'DOMDocument' not
found in /var/www/html/colorist/wiki3/includes/Preprocessor_DOM.php
on line 566, referer: http://www.colorist.org/"
seems an XML error, could it be I have some extensions that are out-of-
sync with the new version?
thanks in advance.
--
Rob Lingelbach
rob(a)colorist.org http://www.colorist.org/robhome.html
-----Original Message-----
Message: 1
Date: Thu, 26 Jun 2008 17:41:45 +0300
From: "Saar Machtinger" <saar.machtinger at optitex.com>
Subject: [Mediawiki-l] How to move MYSQL from windows to godaddy.com
To: mediawiki-l at lists.wikimedia.org
Message-ID:
<a4634a470806260741g780c5c02w8874fa0ccffada83 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi all,
Been trying to move a MW database that we have stored in our LAN over to
godaddy.com hosting services (I am not promoting, it just that this is the
service I ue, and if anyone has prior experiance with it, id love to hear
it)
Anyway, my original tables and the ones on the auto install are different.
And I can not figure out how to direct the web to access my old names.
I have copied my tables to the new names strucutre. This seems to be a bad
idea, as there is also a version difference between the 2. I am not a php
guro, but where in the script does it start to mention to which table to
connect? I have looked all over in icnludes, setup, maintenance , can't find
anything.
Would love to hear your advise.
Thanks,
Saar
--
Saar Machtinger - CIO
OptiTex Ltd. | www.optitex.com | saar.machtinger at optitex.com
Tel: +972-3-904 9979 | Fax: +972-3-904 2710
* Think green before you print
------------------------------
If you upgrade the original wiki to the latest version (or the same version as your godaddy.com wiki), the tables should be identical (or very nearly so) and you will have far fewer hassles migrating.
Alternatively, depending on how much system access godaddy.com let you have, it may be easier just to import your database dump into a clean database, and move your wiki folder directly into your new system (updating database information etc as required). Upgrading is still a pretty good idea, though...
Richard
-----Original Message-----
Message: 1
Date: Thu, 26 Jun 2008 17:41:45 +0300
From: "Saar Machtinger" <saar.machtinger(a)optitex.com>
Subject: [Mediawiki-l] How to move MYSQL from windows to godaddy.com
To: mediawiki-l(a)lists.wikimedia.org
Message-ID:
<a4634a470806260741g780c5c02w8874fa0ccffada83(a)mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi all,
Been trying to move a MW database that we have stored in our LAN over to
godaddy.com hosting services (I am not promoting, it just that this is the
service I ue, and if anyone has prior experiance with it, id love to hear
it)
Anyway, my original tables and the ones on the auto install are different.
And I can not figure out how to direct the web to access my old names.
I have copied my tables to the new names strucutre. This seems to be a bad
idea, as there is also a version difference between the 2. I am not a php
guro, but where in the script does it start to mention to which table to
connect? I have looked all over in icnludes, setup, maintenance , can't find
anything.
Would love to hear your advise.
Thanks,
Saar
--
Saar Machtinger - CIO
OptiTex Ltd. | www.optitex.com | saar.machtinger(a)optitex.com
Tel: +972-3-904 9979 | Fax: +972-3-904 2710
* Think green before you print
------------------------------
<saar.machtinger@optitex.com><a4634a470806260741g780c5c02w8874fa0ccffada83@mail.gmail.com><sancelot@free.fr><mediawiki@thegadgetdoctor.com><mediawiki-l@lists.wikimedia.org><a.v.a@home.nl><rob@colorist.org><cd347288-9e8b-4871-a918-9d38716e41ae@colorist.org><borepstein@gmail.com><mediawiki-l@lists.wikimedia.org><mediawiki@thegadgetdoctor.com><onekopaka@gmail.com><mediawiki-l@lists.wikimedia.org><mediawiki@thegadgetdoctor.com><meyer7@mindspring.com><mediawiki-l@lists.wikimedia.org><christensenc@battelle.org><mediawiki-l@lists.wikimedia.org><rob@colorist.org><mediawiki-l@lists.wikimedia.org><a7d6284a-5838-4b16-98b1-ef6e45584e0b@colorist.org><rob@colorist.org><mediawiki-l@lists.wikimedia.org><ab6be61d-8865-49ba-8269-58f9b4a867a4@colorist.org><daniel.bolser@gmail.com><mediawiki-l@lists.wikimedia.org><meyer7@mindspring.com>
<saar.machtinger@optitex.com><a4634a470806260741g780c5c02w8874fa0ccffada83@mail.gmail.com><sancelot@free.fr><mediawiki@thegadgetdoctor.com><mediawiki-l@lists.wikimedia.org><a.v.a@home.nl><rob@colorist.org><cd347288-9e8b-4871-a918-9d38716e41ae@colorist.org><borepstein@gmail.com><mediawiki-l@lists.wikimedia.org><mediawiki@thegadgetdoctor.com><onekopaka@gmail.com><mediawiki-l@lists.wikimedia.org><mediawiki@thegadgetdoctor.com><meyer7@mindspring.com><mediawiki-l@lists.wikimedia.org><christensenc@battelle.org><mediawiki-l@lists.wikimedia.org><rob@colorist.org><mediawiki-l@lists.wikimedia.org><a7d6284a-5838-4b16-98b1-ef6e45584e0b@colorist.org><rob@colorist.org><mediawiki-l@lists.wikimedia.org><ab6be61d-8865-49ba-8269-58f9b4a867a4@colorist.org><daniel.bolser@gmail.com><mediawiki-l@lists.wikimedia.org><meyer7@mindspring.com>If you upgrade the original wiki to the latest version (or the same version as your godaddy.com wiki), the tables should be identical (or very nearly so) and you will have far fewer hassles migrating.
<saar.machtinger@optitex.com><a4634a470806260741g780c5c02w8874fa0ccffada83@mail.gmail.com><sancelot@free.fr><mediawiki@thegadgetdoctor.com><mediawiki-l@lists.wikimedia.org><a.v.a@home.nl><rob@colorist.org><cd347288-9e8b-4871-a918-9d38716e41ae@colorist.org><borepstein@gmail.com><mediawiki-l@lists.wikimedia.org><mediawiki@thegadgetdoctor.com><onekopaka@gmail.com><mediawiki-l@lists.wikimedia.org><mediawiki@thegadgetdoctor.com><meyer7@mindspring.com><mediawiki-l@lists.wikimedia.org><christensenc@battelle.org><mediawiki-l@lists.wikimedia.org><rob@colorist.org><mediawiki-l@lists.wikimedia.org><a7d6284a-5838-4b16-98b1-ef6e45584e0b@colorist.org><rob@colorist.org><mediawiki-l@lists.wikimedia.org><ab6be61d-8865-49ba-8269-58f9b4a867a4@colorist.org><daniel.bolser@gmail.com><mediawiki-l@lists.wikimedia.org><meyer7@mindspring.com>
<saar.machtinger@optitex.com><a4634a470806260741g780c5c02w8874fa0ccffada83@mail.gmail.com><sancelot@free.fr><mediawiki@thegadgetdoctor.com><mediawiki-l@lists.wikimedia.org><a.v.a@home.nl><rob@colorist.org><cd347288-9e8b-4871-a918-9d38716e41ae@colorist.org><borepstein@gmail.com><mediawiki-l@lists.wikimedia.org><mediawiki@thegadgetdoctor.com><onekopaka@gmail.com><mediawiki-l@lists.wikimedia.org><mediawiki@thegadgetdoctor.com><meyer7@mindspring.com><mediawiki-l@lists.wikimedia.org><christensenc@battelle.org><mediawiki-l@lists.wikimedia.org><rob@colorist.org><mediawiki-l@lists.wikimedia.org><a7d6284a-5838-4b16-98b1-ef6e45584e0b@colorist.org><rob@colorist.org><mediawiki-l@lists.wikimedia.org><ab6be61d-8865-49ba-8269-58f9b4a867a4@colorist.org><daniel.bolser@gmail.com><mediawiki-l@lists.wikimedia.org><meyer7@mindspring.com>Alternatively, depending on how much system access godaddy.com let you have, it may be easier just to import your database dump into a clean database, and move your wiki folder directly into your new system (updating database information etc as required). Upgrading is still a pretty good idea, though...
<saar.machtinger@optitex.com><a4634a470806260741g780c5c02w8874fa0ccffada83@mail.gmail.com><sancelot@free.fr><mediawiki@thegadgetdoctor.com><mediawiki-l@lists.wikimedia.org><a.v.a@home.nl><rob@colorist.org><cd347288-9e8b-4871-a918-9d38716e41ae@colorist.org><borepstein@gmail.com><mediawiki-l@lists.wikimedia.org><mediawiki@thegadgetdoctor.com><onekopaka@gmail.com><mediawiki-l@lists.wikimedia.org><mediawiki@thegadgetdoctor.com><meyer7@mindspring.com><mediawiki-l@lists.wikimedia.org><christensenc@battelle.org><mediawiki-l@lists.wikimedia.org><rob@colorist.org><mediawiki-l@lists.wikimedia.org><a7d6284a-5838-4b16-98b1-ef6e45584e0b@colorist.org><rob@colorist.org><mediawiki-l@lists.wikimedia.org><ab6be61d-8865-49ba-8269-58f9b4a867a4@colorist.org><daniel.bolser@gmail.com><mediawiki-l@lists.wikimedia.org><meyer7@mindspring.com>
<saar.machtinger@optitex.com><a4634a470806260741g780c5c02w8874fa0ccffada83@mail.gmail.com><sancelot@free.fr><mediawiki@thegadgetdoctor.com><mediawiki-l@lists.wikimedia.org><a.v.a@home.nl><rob@colorist.org><cd347288-9e8b-4871-a918-9d38716e41ae@colorist.org><borepstein@gmail.com><mediawiki-l@lists.wikimedia.org><mediawiki@thegadgetdoctor.com><onekopaka@gmail.com><mediawiki-l@lists.wikimedia.org><mediawiki@thegadgetdoctor.com><meyer7@mindspring.com><mediawiki-l@lists.wikimedia.org><christensenc@battelle.org><mediawiki-l@lists.wikimedia.org><rob@colorist.org><mediawiki-l@lists.wikimedia.org><a7d6284a-5838-4b16-98b1-ef6e45584e0b@colorist.org><rob@colorist.org><mediawiki-l@lists.wikimedia.org><ab6be61d-8865-49ba-8269-58f9b4a867a4@colorist.org><daniel.bolser@gmail.com><mediawiki-l@lists.wikimedia.org><meyer7@mindspring.com>Richard
Hi
I have just installed Mediawiki 1.12.0 on a Centos 5 machine,it says the
install was successful but when I try to add a user I get the database error
message:
"A database syntax error has occurred... from within function
"RequestAccountPage::doSubmit". MySQL returned error: "1146: Table
wiki.mw1account_requests' doesn't exist (localhost)
I went through the database diagram in the documentation and could not find
this table listed as well as in the tables created in mysql by media wiki -
all other tables did appear though. I am assuming this is some kind of
temporary table that gets created - just wondering if someone could point me
to where I may be ableto troubleshoot this further.
Thanks,
Kimberly
I (stupidly) uploaded a large image to the Wiki. Now I get php fatal errors
anytime I try to display it. How can I delete the image from the site if any
page that involves the image just gives me a white screen!
Gadgetdoctor