Support ⇒ Modules & Blocks ⇒ MediaWiki integration? ⇒ Community Forums ⇒ CPG Dragonfly™ CMS
Forum IndexModules & Blocks

MediaWiki integration? Reply to topic

Go to page 1, 2, 3, 4 Next

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

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Debian sarge/Apache1/4.1.11/9.1 cvs version


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.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Linux//4.0.27/4.4.2/9.0.6.1


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 Sad

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

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Debian sarge/Apache1/4.1.11/9.1 cvs version


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.

•●••●••●••●••●••●••●•๑۩۞۩๑•●••●••●••●••●••●••●•
Reality checks don't bounce

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
XP Pro/Apache 2/MySQL 5.0.18-nt/PHP 5.1.2/Dragonfly CVS/phpMyAdmin 2.7.0-pl2


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

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Debian sarge/Apache1/4.1.11/9.1 cvs version


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/

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Linux//4.0.27/4.4.2/9.0.6.1


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.
// Set the location of your Dragonfly folder relative to the wiki root 
$DRAGONFLY_LOCATION = "../";


Add the following lines to your LocalSettings.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.
# 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.
Attachment: dfauthplugin.zip
Description Dragonfly Authorization Module for Mediawiki
Filename dfauthplugin.zip
Filesize 10.30 KiB
Downloaded 448 Time(s)
You are not allowed to view/download this attachment

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Linux 2.6.9/Apache 1.3.36/MySQL 4.1.18/PHP 5.1.4/CPG Nuke 9.1.0.8 (Modified)


It looks like we are cruising Mr. Green

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 Rolling Eyes

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

The code I used for authentication looks like this:

$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 Very sad

cheers,
Hókipóki

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Debian sarge/Apache1/4.1.11/9.1 cvs version


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?

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Linux 2.6.9/Apache 1.3.36/MySQL 4.1.18/PHP 5.1.4/CPG Nuke 9.1.0.8 (Modified)


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 Sad

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 Evil or Very Mad

Hókipóki

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Debian sarge/Apache1/4.1.11/9.1 cvs version


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 Smile

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Linux 2.6.9/Apache 1.3.36/MySQL 4.1.18/PHP 5.1.4/CPG Nuke 9.1.0.8 (Modified)


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...

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Debian sarge/Apache1/4.1.11/9.1 cvs version


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:

<?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; } ?>

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Debian sarge/Apache1/4.1.11/9.1 cvs version


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?

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Linux 2.6.9/Apache 1.3.36/MySQL 4.1.18/PHP 5.1.4/CPG Nuke 9.1.0.8 (Modified)


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.
Attachment: modifiedfiles.tar.gz
Description
Filename modifiedfiles.tar.gz
Filesize 14.12 KiB
Downloaded 453 Time(s)
You are not allowed to view/download this attachment

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Debian sarge/Apache1/4.1.11/9.1 cvs version

All times are UTC
Go to page 1, 2, 3, 4 Next


Jump to: