Vanilla 1 is no longer supported or maintained. If you need a copy, you can get it here.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

MediaWiki Integration

edited August 2006 in Vanilla 1.0 Help
MediaWiki Integration

Comments

  • I'm receiving the following error after integrating this: "Cannot modify header information - headers already sent" The problem is in the WebResponse.php file in the WikiMedia includes/ folder. I've read that this is normally caused by white space around the functions or an extra line before the <?php open, but that's not the case here. Server Specs: IIS 6 Windows Server 2003 Standard PHP 5.2.1 MySQL 4.0.22 If I go back to the original MediaWiki LocalSettings.php, the installation works without issues. Any idea what the issue could be?
  • Check the output buffering on the server. I had this issue on something else, but it was the same error. Fixed my issue.
  • Hey Krak, what do you suggest I do... Output buffering is currently turned off. Should I turn it on, say 4096?
  • Using the same user information is nice. If they can sing in and sign out togeter, it will be excellent. Does anyone has solution about it?
  • Seems like something important is missing in the instructions... there is no talk of the actual relationship between MW and Vanilla -- it says modify the LocalSettings.php in MW and then add a file to MW.

    I didn't see any variables that describe the location of the Vanilla install?

    Do they need to share a folder or something?
  • Never mind, just saw this at the bottom of the readme:

    // change these values to reflect your Vanilla database information
    $wgAuth = new AuthPlugin_Vanilla($wgDBserver, $wgDBuser, $wgDBpassword, $wgDBname, "LUM_");
  • I get lots of fun errors. I changed the information on the localsettings file to reflect my database, username, etc. I didn't touch the authplugin file. Any idea why it might throw those errors? It shows the wikifront page, but the errors are in the background. And when i try to use my login on my vanilla forum, it says no such user.

    This is what my $wgAuth looks like:
    $wgAuth = new AuthPlugin_Vanilla($wglocalhost, $wgfakelogin, $wgfakepass, $wgfreshvanilla, "LUM_");

    Warning: mysql_pconnect() [function.mysql-pconnect]: Access denied for user 'www-data'@'localhost' (using password: NO) in /var/www/wiki/AuthPlugin_Vanilla.php on line 26 Warning: mysql_select_db(): supplied argument is not a valid MySQL-Link resource in /var/www/wiki/AuthPlugin_Vanilla.php on line 27 Warning: Cannot modify header information - headers already sent by (output started at /var/www/wiki/AuthPlugin_Vanilla.php:189) in /var/www/wiki/includes/WebResponse.php on line 10
  • I just skipped the whole wgAuth thing and installed the wiki in the same database as vanilla with MW_ prefixes, and that solved those errors.

    I was still having the exact same error as Fullman, though. The header issue. Turns out there were a few line breaks not before <?php, but after the last line in the file. Probably introduced by me when copying stuff into localsettings.php

    No output buffering necessary, for me anyway.

    That said, my wiki still doesn't recognize any of my vanilla users. Do I need to change anything in authplugin.php? Like, what database it's going to use?
    Edit: FIXT (when I was trying to fix the errors I commented out the auth line since I didn't need it . . . .well, i still need it. esp the part with the prefix.)
  • Anyone ever get this working with Vanilla and Mediawiki in two different databases? I'm having the issues robert is having above.
  • And I got exactly the same error and there is no added whitespace anywhere in my files affected by this plugin. I've changed parameters around in the $wgAuth line but in vain. A solution will be much appreciated.
  • The following method works to resolve the issues: In LocalSettings.php look for the variables which set the database type, server, name, user & password. It looks like this: $wgDBtype = "mysql"; $wgDBserver = "localhost"; $wgDBname = "database_mediawiki"; $wgDBuser = "database_mediawikiuser"; $wgDBpassword = "mediawiki_password"; Copy/paste this section below so that you can declare 2 sets of databases. For example: $wgDBtype = "mysql"; $wgDBserver = "localhost"; $wgDBname = "database_mediawiki"; $wgDBuser = "database_mediawikiuser"; $wgDBpassword = "mediawiki_password"; $vgDBtype = "mysql"; $vgDBserver = "localhost"; $vgDBname = "database_vanilla"; $vgDBuser = "database_vanillauser"; $vgDBpassword = "vanilla_password"; (note: i've changed the variable name to $vgDB[] where the "v" is Vanilla instead of "w" for wiki ) And then went back and modified the following Code at the bottom of LocalSettings.php: // if Vanilla and MediaWiki are not installed on the same database // change these values to reflect your Vanilla database information $wgAuth = new AuthPlugin_Vanilla($vgDBserver, $vgDBuser, $vgDBpassword, $vgDBname, "LUM_"); *** again note that $wgAuth now calls the variables I just declared. Hope this helps!
  • I installed this plug-in, and updated the files. What happens for me is that the wiki turns blank, as in all that I can see is a white page. This happens after I tried to authenticate the wiki using this plugin. The idea is to have the wiki added to the forum using the PageManager with an iframe containing the main page of the wiki (meaning easy access for members and visitors). But here is the white page showing in the iframe, and also when I go to the main page on the server (ie: www.site.org/wiki/). I have already spendt a night bug-searching using the php kill-command... Any ideas to solve this? Is MediaWiki Integration still compatible with Vanilla and MediaWiki?
  • Installed perfectly! Looks great so far...
  • this doesn't seem to work any more... I believe i've read vanilla no longer uses straight md5() for passwords, however in AuthPlugin_Vanilla.php :93 there's

    if(md5($password) == $vanilla_userinfo['Password']) return true;

    I have 0 experience with Vanialla. Could somebody help me down the right path to correct the issue? I'm guessing I need to pull in vanilla's auth classes in somehow.
  • has anyone gotten this to work yet?
  • Check this out
    It is an incomplete method because if you log in to the forum it doesn't also log you into the wiki, but I am currently working on a project for works that provides that feature so I will post instructions when that's done.
  • @SubJunk: Thanks a lot for this! It got me half way, however it's causing an error if I try to sign in from the Wiki. I think there is a name collision:
    Fatal error: Cannot redeclare class Database in /.../forums/library/Framework/Framework.Class.Database.php on line 25
  • Has somebody found a solution for this yet?
  • Have found a serious bug with usernames - while a default Vanilla install is happy to let users take any old username (even something as crazy as "!@#&gt;"), this addon opens with an alphanumeric regexp explained as "search pattern to only accept alphanumeric or underscore characters in usernames - if they have illegal characters, their name cannot exist, period" (which doesn't actually match the regexp; the regexp does not include underscores).

    This means that if you register on the forum as "john.doe", when you try to log into MediaWiki it will tell you that your account doesn't exist (because it's got a period in it).

    One way to fix this would be to open up the regexp in AuthPlugin_Vanilla.php, but I don't know if that creates any wider MediaWiki issues. The safest solution seems to be to edit Vanilla's library/People/People.Class.UserManager.php, changing:-

    Validate($this->Context->GetDefinition('UsernameLower'), 1, $SafeUser->Name, 20, '', $this->Context);

    to:-

    Validate($this->Context->GetDefinition('UsernameLower'), 1, $SafeUser->Name, 20, '^[a-zA-Z0-9]+$', $this->Context);

    ...which means that if a user tries to create a forum username that includes anything other than alphanumeric characters, they get an error message.

    (I'll be tackling the two-cookie issue myself in the next couple of weeks, if nobody else has done so already.)
Sign In or Register to comment.