[Hókipóki]

Hi all,

I tried searching everywhere in this site and on the net to find a wiki module for Dragonfly. And I didn't find any. The one in the cvs version of Dragonfly 9.1.* is very rudimentary, to put it simply (I tried to use it). Am I correct?

Exists a usable wiki module for Dragonfly? Preferably a major engine, like MediaWiki, or anything widely used.

The reason I ask this question in this forum is simple. I started to integrate MediaWiki (the engine begind Wikipedia) into Dragonfly.

So far I completely ignored authentication (so one has to log in separately into MediaWiki too), but basic editing kinda works, and its displaying right in the modules space.

What I want to achieve is not only a single authentication scheme (that seems easy), but a more complete integration (embed it in the center block, but not via iframe). Special links don't work yet, and theres yet a lot, lot of work to do.

But if there exists any usable wiki module, I won't waste my time hacking away madly.

Hókipóki

[dcollis]

no there isn't one - the one in the cvs is the only one.
An integration of mediawiki would be much appreciated. Let us know how you get on.

[Hókipóki]

I've been working on it a little. But its really only a bridge, not integration. And tho I'm a programmer, but never used php in my life.

I can write down the steps required, but it can't be really automated

What I'm doing is basically this:
-I installed MediaWiki in modules/MediaWiki directory, as a standalone wiki install.
-then changed the monobook skin (default mediawiki skin) to omit the head and body tags, and only output the big div containing the wiki, so that it can be embedded in Dragonfly.
-made a basic wiki extension to handle the inclusion of header.php and changing the modheader variable as to insert the necessery css and js references into the head section, _before_ the wiki module is rendered.
-made another basic wiki extension to handle the rewriting of links (so now the local wiki links are "working" inside Dragonfly)
-had to modify the wiki index.php in 3 lines to change require() pathes
-the only change required in Dragonfly is in the index.php, we have to let Dragonfly pass the "/" sign in the urls (in GET parameters, previously it was filtered out)

So far I got a "working" wiki inside Dragonfly, but without any working css skin, and without any javascript in the wiki (I didnt have to time to import the proper head section from the monobook skin), and some special links don't work. The skin is a big difficulty as all the wiki skins I found are using position:absolute to position the numerous menus inside the page. And it breaks the layout as the wiki now is embedded inside Dragonfly.

And authentication is missing too. Authentication I plan to handle this way: disable the login in wiki, make a small Auth extension in mediawiki that will read out the Dragonfly cookie, and constantly update the wiki user tables accordingly. It will be very basic. And I've no precise idea on how the authentication works in Dragonfly, yet.

Sincerely, the biggest difficulty so far was setting up correctly the wiki paths to live inside Dragonfly (and my special case is even worse, as my site is on a subdomain).

If I _do_ succeed in get it working, and if anyone is interested, I'll make a detailed instruction list on the install and bridging.

Sorry for the long post, but any advice is much appreciated, as I'm a Dragonfly rookie.

Hókipóki

[brownas98]

this is exactly what i need!

if you succeed in porting mediawiki to dragonfly it would certainly be a very popular module. keep us informed on your progress.

[Hókipóki]

I've managed to build a (working?) bridge from Dragonfly to MediaWiki, and my wiki install is more or less embedded in Dragonfly.

I disabled the wiki login, and if a registered user accesses the wiki module, he's automatically imported into the MediaWiki database, as a registered user. If a user with MediaWiki admin rights (set up in Dragonfly authors) accesses the wiki module, he's added to the bureaucrat and sysop wiki groups (effectively making him an admin in MediaWiki).

In the evening I'll write down the list of steps needed, and upload some sample files to play with.

I need someone to test the process. It's not so simple as I imagined, but can be reproduced. My main problem is that I'm on a subdomain, so my setup is different than the majority of the users.

My wiki install seems working fine, tho it has some restrictions over the standalone version. And I didn't try to install any extensions for it yet.

Hókipóki

[dcollis]

sounds good.
I'd be happy to help out where I can.

I've heard the mambo/joomla integration works quite well, perhaps some inspiration can be got from there : mamboxchange.com/proje...mambowiki/

[SaintPeter]

I have modified a MediaWiki extension from phpBB to work with Dragonfly. What this does is authenticates all logins to MediaWiki against your Dragonfly Database. Once you are authenticated, it creates a local user in the Wiki DB. It means that you do need to login to the Wiki at least once, but with a long cookie time, this is not that bad.

Install Instructions
Unzip the attached file in your Extensions directory. Edit the file DragonflyAuthPlugin.php, Line 9 and set the relative location of your Dragonfly instalation.

PHP:

// Set the location of your Dragonfly folder relative to the wiki root 
$DRAGONFLY_LOCATION = "../";

Add the following lines to your LocalSettings.php:

PHP:

# Use phpBB Authentication 
require_once( 'extensions/dfAuthPlugin/DragonflyAuthPlugin.php' ); 
$wgAuth = new AuthDragonfly(); 

Here are two optional lines that you can use in conjunction with the plugin. One disables Anonymous editing and the other disables new account creation via the Wiki.

PHP:

# This snippet prevents new registrations from anonymous users
# (Sysops can still create user accounts)
$wgGroupPermissions['*']['createaccount'] = false;

# This snippet prevents editing from anonymous users
$wgGroupPermissions['*']['edit'] = false;

---

I am VERY interested in seeing the files that you've made to modify the Wiki input/output stuff. While I'm not an expert, I am confident that I can correct for subdomain issues. Since I'm going to be trying to do the same thing anyway, we might as well pool resoures.

[Hókipóki]

It looks like we are cruising

I looked at the Mambo integration. At a quick glance at the html source generated, it looks like an iframe embedding. Which I don't like

I'm currently working on a usable skin for the wiki inside Dragonfly.

The code I used for authentication looks like this:

Code:

$wgHooks['AutoAuthenticate'][] = 'fnAuthServerMagic';

function fnAuthServerMagic(&$user) {
        global $userinfo;
        if (is_user()) {
                $username = $userinfo['username'];
                $realname = $userinfo['name'];
                $useremail = $userinfo['user_email'];
        } else return false;
 
        session_start();
 
        $user = User::newFromName($username);
        if ($user->getID()==0) {
                $user->addToDatabase();
                $user->setEmail($useremail);
                $user->setRealName($realname);
                $user->setToken();
                $user->saveSettings();
        } else {
                $user->loadFromDatabase();
        }
        if (can_admin('mediawiki')) {
                $user->addGroup('sysop');
                $user->addGroup('bureaucrat');
        }
        return true;
}

Don't forget, I'm working inside Dragonfly, so I have access to Dragonfly variables. So I just read out everything needed about the current user, and if he is registered, automatically register him into the wiki. And if a mediawiki admin is using the wiki module, he's given admin rights.

It's a little problematic, what if a user was granted admin rights, but then revoked it? But its a minor problem only. I've got major headaches now, modifying the wiki skins

cheers,
Hókipóki

[SaintPeter]

If we can get it working inside Dragonfly, your code will be very helpful.

One thing I was looking into for my integration attempt was a pre-existing style that didn't have a side block. I found ONE.
Mini-Menu Style

Maybe that'll help?

[Hókipóki]

The mini-menu style has the same problem that I found with ALL existing MediaWiki skins:

they know for sure that as MediaWiki is not embedded in anything, they can completely control the css and the page structure. So every skin uses position:fixed, position:absolute positioning, to lay out the menus-portlets. And some floats. And these won't work inside Dragonfly, or at least not easily.

Now I'm really a design anti-talent. And my html and css knowledge is very limited. So these obstacles can probably be overcome very easily, but I lack the necessery webdesign experience. I'll have a look at Stu Nichols' website for inspiration for a simple two column design, which works in bloody IE too

But if I get really angry, I let elegance and css2 slip aside and I'll make the layout table based, which at least kinda works

Hókipóki

[SaintPeter]

I'd really appreciate it if you could post a copy of the files you have modified from the stock wiki. I'd like to be able to bang on this myself.

I am not exactly a .css guru, but I have some experience hacking CSS . . . and I know how to use global search and replace

[Hókipóki]

SaintPeter, I sent you a link to the beta site where I'm playing with MediaWiki. Its not a public site, yet.

I'm writing down the steps required to reproduce the bridging, I'll send you a copy. It's not finished yet, and I have my doubts if its useful to anyone else at all...

[Hókipóki]

What I'm doing is very simple. I installed MediaWiki in modules/MediaWiki/ as a standalone app. Made a little cpg_inst.php to create the radmin field for me.

Modified index.php in 3 places (changed required paths), and modified the LocalSettings.php file (changed paths again).

Then I edited the skin/Monobook.php file, and cut out the <head> section completely from the output, so wiki renders as a big div. Changed the corresponding skin/monobook/main.css (removed body, html references, and changed all position:absolute to position:relative).

And finally made an extension that handles the authentication, emits the necessery header.php call to produce the Dragonfly environment, and rewrites wiki urls to make them live inside Dragonfly. The complete module is this:

Code:

<?php
 
$wgExtensionFunctions[] = "wfDragonflyModule";
 
$wgHooks['GetLocalURL'][] = 'fnLinkHook' ;
$wgHooks['OutputPageBeforeHTML'][] = 'fnHeaderHook';
$wgHooks['ParserAfterTidy'][] = 'fnHeaderHook';
$wgHooks['AutoAuthenticate'][] = 'fnAuthServerMagic';
$wgHooks['SpecialPageExecuteBeforeHeader'][] = 'fnHeaderHook';
 
function wfDragonflyModule() {
        global $wgSpecialPages;
        //even if the login/logout buttons are displayed, they won't work from now on
        unset($wgSpecialPages["Userlogin"]);
        unset($wgSpecialPages["Userlogout"]);
}
 
/** this little function handles the rewriting of links inside the wiki. If you mess up the wiki settings concerning the lin
ks (prettying urls etc) in LocalSettings.php, these rules might not work, so beware!  */
function fnLinkHook(&$title, &$url, $query) {
        $url = str_replace("index.php?", "index.php?name=MediaWiki&", $url);
        $url = str_replace("index.php/", "index.php?name=MediaWiki&title=", $url);
}

/** this function has two task: include in the head section of the page the necessery wiki css and js links, and second, out
put the Dragonfly header before the wiki module. The hardcoded header style and js links are ugly, should modify it somehow
in the future. */
function fnHeaderHook($parserOutput, $text) {
        if (!defined('CPG_NUKE')) {
                exit;
        }
        global $pagetitle, $modheader;
 
        $pagetitle .= _MEDIAWIKI;
        $modheader .= '<link rel="stylesheet" type="text/css" href="modules/MediaWiki/skins/dragonfly/main.css" />';
        $modheader .= '<script type="text/javascript" src="modules/MediaWiki/skins/common/wikibits.js"></script>';
 
        require_once("header.php");
}
 
/** As we disabled the login/logout when this extension is installed, we need to do these manually. The redirect link is never executes, just leaved it there for future modification. Some problems: passwords are not imported. So if converting the module back to standalone, you will have the users in the database, but noone can log in. More important issue: case sensitiv
ity and weird characters in username. These can cause serious headache, need further investigation.  */
function fnAuthServerMagic(&$user) {
        global $userinfo;
        if (is_user()) {
                $username = $userinfo['username'];
                $realname = $userinfo['name'];
                $useremail = $userinfo['user_email'];
        } else return false;
 
        session_start();
 
        if ($username=="") {
                header('Location: https://go.there.and/login.php?back='.$enc);
                exit();
        }

/* if a user is not present in wiki database, it will be created. If the user was present, then his settings WON'T b
e updated! The key for the identification is the username. If a user has mediawiki module admin rights, he will get admin ri
ghts in wiki. */
        $user = User::newFromName($username);
        if ($user->getID()==0) {
                $user->addToDatabase();
                $user->setEmail($useremail);
                $user->setRealName($realname);
                $user->setToken();
                $user->saveSettings();
        } else {
                $user->loadFromDatabase();
        }
        if (can_admin('mediawiki')) {
                $user->addGroup('sysop');
                $user->addGroup('bureaucrat');
        }
        return true;
}
 
?>

[SaintPeter]

One thought:

In your module index.php, could you just bracket the imports to the wiki in "chdir" commands? Change the directory to the root of the wiki, let it run, then when done, change it back?

IE:

OpenTable();
chdir('/modules/wiki/');
include('index.php');
chdir('/');
CloseTable();

Or something similar?

[Hókipóki]

Uploaded the changed files. I'm working off the 1.6.8 mediawiki legacy stable release, as this is the newest stable that supports PHP4 (the new 1.7.1 supports only PHP5).

I had to fiddle a lot with LocalSettings.php to work out the paths. Now I'm too tired to work on this, hopefully tomorrow evening I can work on it.

These files are a work in progress, just to show the way I'm proceeding. the LocalSettings.php needs heavy editing of course.