Teammates,
While trying a fresh install of MW 1.19.2 on Windows 2003 (IIS 6.0/PHP 5.2.5/MySQL is remote) although I get the initial MW
index.php with the "set up the wiki" link, when I click on that I get this big backtrace.
Does anyone have any idea what this means ? I haven't created the database yet, since I can't get to the setup
page. So I'm not sure why it is complaining about database ??
thanks,
L
>From url: http://<myDomain>/mediawiki-1.19.2/mw-config/index.php
Mediawiki tried to access the database via wfGetDB(). This is not allowed.
Backtrace:
#0 G:\www-wiki-test\mediawiki-1.19.2\includes\GlobalFunctions.php(3484): LBFactory_Fake->getMainLB(false)
#1 G:\www-wiki-test\mediawiki-1.19.2\includes\GlobalFunctions.php(3474): wfGetLB(false)
#2 G:\www-wiki-test\mediawiki-1.19.2\includes\User.php(1025): wfGetDB(-2)
#3 G:\www-wiki-test\mediawiki-1.19.2\includes\User.php(300): User->loadFromDatabase()
#4 G:\www-wiki-test\mediawiki-1.19.2\includes\User.php(266): User->loadFromId()
#5 G:\www-wiki-test\mediawiki-1.19.2\includes\User.php(2025): User->load()
#6 G:\www-wiki-test\mediawiki-1.19.2\includes\User.php(985): User->getToken(false)
#7 G:\www-wiki-test\mediawiki-1.19.2\includes\User.php(269): User->loadFromSession()
#8 G:\www-wiki-test\mediawiki-1.19.2\includes\User.php(3972): User->load()
#9 G:\www-wiki-test\mediawiki-1.19.2\includes\User.php(2154): User->loadOptions()
#10 G:\www-wiki-test\mediawiki-1.19.2\includes\context\RequestContext.php(274): User->getOption('language')
#11 G:\www-wiki-test\mediawiki-1.19.2\includes\StubObject.php(160): RequestContext->getLanguage()
#12 G:\www-wiki-test\mediawiki-1.19.2\includes\StubObject.php(105): StubUserLang->_newObject()
#13 G:\www-wiki-test\mediawiki-1.19.2\includes\parser\ParserOptions.php(334): StubObject->_unstub()
#14 G:\www-wiki-test\mediawiki-1.19.2\includes\installer\Installer.php(360): ParserOptions->__construct()
#15 G:\www-wiki-test\mediawiki-1.19.2\includes\installer\WebInstaller.php(114): Installer->__construct()
#16 G:\www-wiki-test\mediawiki-1.19.2\mw-config\index.php(23): WebInstaller->__construct(Object(WebRequest))
#17 G:\www-wiki-test\mediawiki-1.19.2\mw-config\index.php(18): wfInstallerMain()
#18 {main}
Hi there, MediaWiki-l folks. For this wiki version...
MediaWiki 1.19.1
PHP 5.2.17 (cgi-fcgi)
MySQL 5.5.23-55
...by any chance is there a way (that a non-programmer, like me, would
understand) to prevent the "contribslink" from existing? Or at least
stop some user groups from getting it? This is the link with text
that's controlled by the "MediaWiki:contribslink" page; it appears as
"contribs" by default, in various places. I'm never going to need
that link.
Thank you very much.
-- John
So I think it's really kool, that during installation of MediaWiki 1.19.2 you can choose to install some
extensions by Default. I selected ParserFunctions and Renameusr, for instance.
The first time around, I had not selected (checked) Gadgets, but now I would like to add it.
I'm not sure of how to add it after the fact ?? Since I have already installed MediaWiki and didn't check
the Gadgets box.
Let me know if you know how I can do it.
thx,
Lori
Hello Out There,
my english isn't that good, I've added the discription of my problem in german below.
I'm trying to integrate multiple MediaWikis into my own page. I've some own login-structures and mutiple projects which can have a wiki. If a user is a member in a project holding a wiki, he may access this trough my own site.
The wiki-farm is set up via database-prefixes, so every "sub-wiki" has its own prefix. I think I need this, because I have to generate new wikis in runtime from my page. When calling the wiki (via IFrame from my own site) I'm adding an get-parameter which indicates which wiki should be loaded and set the database-prefix as needed. In Mediawiki's config I'm saving this parameter in a Cookie, so that wiki-internal links will work (they don't have the get-parameter). Like this it's possible to access multiple wikis at the moment.
One Issue here: If a user accesses my page via multiple tabs or browser-windows, they get strange errors if editing a page on one tab and surfing an other wiki on an other tab. Like this they get the cookie of the other wiki while editing the first. If they hit save on the first tab, it seams that they override the content in the second wiki (second tab) with the one supposed to come to the first. It seams logic that this happens, but I have no clue how to prevent this. Is it possible to add an additional parameter to every wiki-generated link, so that I can add the "db-prefix" into every link? That way I wouldn't need the Cookie.
Additionally I have some (not completly working) autentication-extension running that checks if the sessionCookie of my own site is set properly and if this user may have access to the actual wiki. If everything is ok, I'm checking If the user is currently logged in and if not I try to do so. This seams to work, but sometimes users get an error while editing a wiki saying that "Session-Data" is lost and that they should try to log off and on. Mostly its enough to cklick "save" again and everything works as expected.
This is why I think that there could be some errors in my authentication-function.
After hours of reading documentation and other working examples I came to the following. But because of missing documentation (or me not finding it) I'm not sure if this is the right approach to login a User correctly.
Now my login-hook looks that way: (sorry for some german comments)
function Auth_internal_user_hook() {
global $wgUser;
global $wgRequest;
global $_REQUEST;
global $wikiName;
// For a few special pages, don't do anything.
$title = $wgRequest->getVal('title') ;
if ($title == 'Special:Userlogout' || $title == 'Special:Userlogin') {
return;
}
//Prüfen ob eine session existiert.
$wgUser = User::newFromSession();
if ($wgUser->isLoggedIn()) {
if ($username != $wgUser->mName) {
//hier ist der falsche am Werk
$wgUser->logout();
}
}
if ((isset($_COOKIE['INTERNAL_SESSION_ID']) && $SID = $_COOKIE['INTERNAL_SESSION_ID']) || (isset($_GET['sid']) && $SID = $_GET['sid'])){
$user = db_getUserBySessionId($SID);
$project = db_getProjectByWikiName($wikiName);
if (is_array($project) && is_array($user)){
if (db_isActiveUserInProject($user['UId'], $project['PId'])){
$username = $user['userName'];
} else {
//keiner eingeloggt
$wgUser->logout();
return;
}
} else {
//keiner eingeloggt
$wgUser->logout();
return;
}
} else {
//keiner eingeloggt
$wgUser->logout();
return;
}
//Benutzer anlegen
$u = User::newFromName( $username );
if (is_null($u)) {
# Invalid username or some other error
return;
}
//und diesen Benutzer als 'normalen' user fürs System setzen
$wgUser = $u;
//wenn der user in der WikiDB existiert hat er da auch eine id.
if ($u->getId() != 0) {
# also return, but user is known. set Cookies, et al
$wgUser->setCookies();
$wgUser->saveSettings();
return;
}
//er hat keine Id, also müssen wir den erst erstellen.
include 'includes/SpecialUserlogin.php';
$form = new LoginForm( $wgRequest );
$form->initUser( $wgUser );
$wgUser->saveSettings();
return;
}
Has anyone an Idea how to fix this Issue? Maybe I have to do it an other way?
I hope you can understand my problems.
Thanks,
Markus
---
Und alles nochmal auf Deutsch:
Ich arbeite Momentan an einer Seite in der mehrere Mediawikis eingebunden werden sollen. Ein user kann dort Mitglied in mehreren Projekten sein, die ihrerseits ein wiki haben können. Da bereits zum Eintritt in meine seite ein Login erfolgt, möchte ich den vom Media-Wiki umgehen.
Ruft ein Benutzer meine eigene Seite auf, in der das Wiki eingebunden wird (per IFrame), hänge ich an die Iframe-src einen get-Parameter an, mit dem ich an die Wiki-Software übermittle welches wiki der Farm geladen werden soll. Alle wikis haben also die selben Source-Dateien, und werden über verschiedene Datenbank-Prefixe getrennt. Das ist notwendig, weil ich zur Laufzeit neue Wikis erstellen muss.
Aus dem angesprochenen Get-Parameter wird also der DB-Prefix erstellt und damit die DB geladen. Damit auch weitere Seitenaufrufe intern funktionieren (die links vom Media-wiki haben ja meinen Parameter nicht) setze ich einen Cookie der alternativ abgefragt wird.
Ich stoße hiermit natürlich an Grenzen, wenn jemand über mehrere Fenster in meiner Seite surft. Öffnet er in Tab1 eine Wiki-seite zum editieren, beginnt damit und öffnet in Tab2 eine Seite eines anderen wikis meiner Farm, so ändert sich der Cookie und beim Speichern in Tab1 wird der Inhalt vom Wiki aus Tab2 überschrieben, sofern es dort eine gleichnamige Seite gibt. Zumindest ist das meine Erklärung für einige Bug-Berichte meiner User. Hat hier jemand eine Idee wie man das Problem lösen kann? Gibt es eine Möglichkeit an alle intern erstellten Links einen eigenen Parameter anzuhängen?
Ein Weiteres Problem scheint vom Login her zu kommen. Ich umgehe die Login-Routinen, indem ich über eine Extension in "$wgExtensionFunctions[]" eine funktion (siehe oben) aufrufe, die meinem Verständnis nach den User einloggen sollte. Die Dokumentation ist da aber nicht berauschend, oder ich habe sie nicht gefunden. Das Problem ist folgendes:
Wenn ich ein wiki aufrufe funktioniert alles Einwandfrei. Ich kann dort alles lesen wie ich soll, funktioniert. Editiere ich jetzt eine Seite, klappt auch alles, bis zum Speichern. Dort bekomme ich einen Fehler, dass "Sitzungsdaten verloren gegangen" sind. Ein erneuter Klick auf Speichern funktioniert dann aber meistens und die Daten sind korrekt gespeichert. Leider war es mir nicht möglich das Problem noch weiter einzugrenzen. Wenn mir jemand von euch sagen kann wie ich einen User korrekt einlogge, bzw wenn er nicht existiert einen entsprechenden in der Wiki-software erstelle oder einen anderen Ansatz hat um mein Problem zu lösen würde mich das sehr freuen.
Vielen Dank für eure Mühe
Markus
Hello, MediaWiki-l folks.
For my wiki, I would like to achieve an effect similar to what
Wikinews does, with this JavaScript:
http://en.wikinews.org/wiki/MediaWiki:Comments.js
It puts a new tab, for a previously-created "Comments" namespace, to
the right of the main and talk tabs. But for my wiki, I'd prefer a
new tab in between the main and talk tabs. Not to the right.
Therefore, my question is: what lines of (presumably) JavaScript code
would Wikinews developers add, delete, or modify, to put their
Comments tab in the middle instead of to the right? If possible--?
I'm not proficient in JavaScript; I hope your answer's suitable for a
beginner. Thanks so much.
-- John
Hello guys, its my first email here, so, i'll try to be as clear as
possible!
Well, im upgrading my mediawiki, from 1.12.0 to 1.19.2, using Apache 5.3.3
and Mysql 5.5.14.
Everything went ok, sphinx, database, all extensions but Lua.
I notice that Lua extension needs LanguageGetMagic hook, but looking after
it, just notice that LanguageGetMagic was deprecated in version 1.16 (
http://www.mediawiki.org/wiki/Manual:Hooks/LanguageGetMagic ), and i cant
find a way to enable it on 1.19.2.
So, here goes three questions:
Is it possible to use LanguageGetMagic on 1.19.2? How?
Anyone here uses this extensions on newers MediaWiki versions?
Someone knows another way to make it works?
Thanks!
Best Regards,
Stephan Gomes Higuti
Hello,
I am new to Mediawiki, in fact wikis generally, so apologies if this is
not the right list to ask for help. (If it isn't, then where do we get
general help from?)
We are using version 1.19.2 with the LDAPAuthentication extension.
However, we are also allowing some local (wiki) accounts (we've modified
the extension a little). What we would like is a 'Special' page to allow
the local account users to be able to change their password (on their
wiki account).
I can see that there is mention of a 'passwordreset' permission in the
Mediawiki code, and it looks like a special page already exists to allow
password changes. However, I cannot get this to work - setting the
permission and logging in, I see no special page relating to password
changes. Could someone please let me know what is required in order to
see this special page?
Thanks,
John.
--
John Horne Tel: +44 (0)1752 587287
Plymouth University, UK Fax: +44 (0)1752 587001
I have a very old mediawiki at a legacy company, I think version 1.9. I am trying to migrate this to a new server, including new hostname/domain. I just want to keep the legacy data in there around as its pretty useful. Read only is fine. I really don't want to print out a few hundred pages and stick them in a book ;-)
Old server(s) : web.olddomain.tld, mysql.olddomain.tld - CentOS 4.9 w/PHP 5.2.6
New Server: web.newdomain.tld - CentOS 6.3 w/PHP 5.3.3
I put a new NameVirtualHost in the new server and it works as expected. Time to move the old mediawiki over. DB dumped (mysqldump), old web files tarred and both are scp'd over to the new server. New DB is created and the old data imported. Username created and given access to DB, same as existed on the old server. The only change I make on the new server is in the LocalSettings.php file, I point at the new DB on localhost, username and the rest of the info stays the same. If I try to run this as is, without upgrading the mediawiki code, I get an error in Apache. "Parse error: syntax error, unexpected T_NAMESPACE, expecting T_STRING in /var/www/html/documentation/includes/Namespace.php on line 44" According to the FAQ this is due to upgrades in PHP and old code. I figured at this point I needed to upgrade to a newer version of mediawiki code.
I download the new mediawiki code and follow the upgrade script/process here : http://www.mediawiki.org/wiki/Manual:Upgrading#How_do_I_upgrade_from_a_real…
New files are untarred over the old files.
I run the update.php script from maintenance directory.
I made one additional change, which is the file under the web root 'StartProfiler.php' contains the line 'require_once( dirname(__FILE__).'/includes/ProfilerStub.php' );' and I change that to 'require_once( dirname(__FILE__).'/includes/profiler/ProfilerStub.php' );' as the new Profiler code seems to be running from includes/profile and not just includes.
The server now serves a "Not Found" error, "The requested URL /wiki/Main_Page was not found on this server." Nothing shows up in error_log.
Not sure if what I am doing is "too many steps at once" and if there is any way to upgrade to 1.19 on the existing server (with the older version of php) and THEN move it, or if I can get the older mediawiki running with the newer version of php, and THEN upgrade it. It seems like the move+upgrade makes things go a little wonky.
Any advice?
Thank you,
Nick
PS - If this is a dupe, sorry. I subscribed and then something happened and my post was rejected as I wasn't subscribed. I resubscribed a few days ago and made sure I was getting mail from the list before sending this time :)