integration with mediawiki

[arowland]

hello,

so i'm using the wikichat.php extension from http://www.wikichat.org so that i can integrate php free chat into my mediawiki installation at http://www.southeastlawwiki.com, but for some reason it gets stuck at the "chat loading" message. i pasted the contents of the wikichat.php file below. any ideas why it's messing up? i tried commenting most of the parameters to see if that fixed anything, but that didn't work either. is there anything here that looks amiss?

<code>
<?php
/**
* MediaWiki WikiChat extension
* See: http://www.mediawiki.org/wiki/Extension:Chat for installation
* Licenced under LGPL (http://www.gnu.org/copyleft/lesser.html)
* Author: http://www.wikichat.org/User:Firebreather
*/

require_once "$IP/extensions/phpfreechat-1.0-final/src/pfcglobalconfig.class.php";
require_once "$IP/extensions/phpfreechat-1.0-final/src/phpfreechat.class.php";


/* Global variables */
$wgAllowAnonUsers = false; # set to false to deny access to anonymous users

# message shown when denying anonymous users. Change if you want a different message. WikiText ok..
$wgDenyAccessMessage = 'You must [[Special:Userlogin|login]] to be allowed into this chatroom';

/* Extension variables */
$wgExtensionFunctions[] = 'wfSetupWikiChat';
$wgExtensionCredits['other'][] = array(
'name' => 'WikiChat',
'version' => '0.2.2, 2007-07-25',
'author' => '[http://www.wikichat.org/User:Firebreather User:Firebreather]',
'url' => 'http://www.wikichat.org/',
'description' => 'Adds a tab to each article that switches to a chatroom',
);

class WikiChat {

// Constructor
function WikiChat() {
global $wgHooks;

# Add all our needed hooks
$wgHooks['UnknownAction'][] = $this;
$wgHooks['SkinTemplateTabs'][] = $this;
}

function onUnknownAction($action, $article) {
global $wgOut, $wgSitename, $wgCachePages, $wgUser, $wgTitle, $wgDenyAccessMessage, $wgAllowAnonUsers;

$wgCachePages = false;

if($action == 'chat') {

$wgOut->setHTMLTitle("WikiChat");
$wgOut->setPageTitle("WikiChat");

if($wgUser->isAnon()) {
if(!$wgAllowAnonUsers) {
$wgOut->addWikiText($wgDenyAccessMessage);
return false;
}
else {
$nick = "Guest";
}
}
else {
$nick = $wgUser->getName();
}

$params["title"] = "WikiChat";
$params["nick"] = $nick; // setup the initial nickname
$params["serverid"] = "md5(__FILE__)";
# $params["openlinknewwindow"] = true;
$params["channels"] = array("MyChatRoom");
# $params["frozen_nick"] = true; // do not allow to change the nickname
# $params["shownotice"] = 0; // 0 = nothing, 1 = just nickname changes, 2 = connect/quit, 3 = nick + connect/quit
# $params["max_nick_len"] = 30; // nickname length could not be longer than 10 caracteres
# $params["max_text_len"] = 300; // a message cannot be longer than 50 caracteres
# $params["max_channels"] = 3; // limit the number of joined channels tab to 3
# $params["max_privmsg"] = 1; // limit the number of private message tab to 1
# $params["refresh_delay"] = 2000; // chat refresh speed is 2 secondes (2000ms)
# $params["max_msg"] = 30; // max message in the history is 15 (message seen when reloading the chat)
# $params["height"] = "230px"; // height of chat area is 230px
# $params["width"] = "800px"; // width of chat area is 800px
$params["debug"] = false; // activate debug console
# $params["timeout"] = 600000; // msecs until user is disconnected

$pfc = new phpFreeChat($params);
$wgOut->addHTML($pfc->printChat(true));
$wgOut->addHTML('<br><br><p>Type /help for a list of all commands</p>');

return false;
}
else {
return true;
}
}

function onSkinTemplateTabs( &$skin, &$content_actions ) {
global $wgRequest;

$action = $wgRequest->getText( 'action' );

$content_actions['chat'] = array(
'class' => ($action == 'chat') ? 'selected' : false,
'text' => "chat",
'href' => $skin->mTitle->getLocalURL( 'action=chat' )
);

return true;
}

# Needed in some versions to prevent Special:Version from breaking
function __toString() { return 'WikiChat'; }
}

/* Global function */
# Called from $wgExtensionFunctions array when initialising extensions
function wfSetupWikiChat() {
global $wgWikiChat;
$wgWikiChat = new WikiChat();
}

?>
</code>

[arowland]

i should also note that it works fine when i load the simple demo php file included with php free chat.

[biomeum]

HI,
Did you ever get to the bottom of this? I am having exactly the same problem and am on the verge of giving up!

[twocs]

Many things to change to get to the bottom of this. But one thing might be solved by changing:

$params["serverid"] = "md5(__FILE__)";

to

$params["serverid"] = md5(__FILE__);

[bluecarrot16]

I've had this same problem, and haven't been able to resolve it. The issue seems to be that the requisite script files (prototype.js, and the mountain of phpFreeChat scripts) don't get loaded, because the data_public_url doesn't get calculated wrong (perhaps related to URL rewriting. Anyhow, the solution appeared to be to manually set data_public_url and/or data_public_path like this:

$params["data_public_url"] = "[absolute URL to phpfreechat/data/public]"
$params["data_public_path"] = "[absolute path to phpfreechat/data/public]"

But that didn't work. Digging into the chat.js.tpl file for the Default theme, I found that indeed, the src attributes for the JS files were indeed generated from data_public_url + something else. However, even when I changed the data_public_url in the WikiChat.php file, as described above, viewing the page in firebug after the chat load had stalled showed that phpFreeChat wasn't honoring the data_public_url I had set in WikiChat.php.

Becoming increasingly frustrated, I tried (to no avail) changing the data_public_url manually in the default phpFreeChat settings file (I forget exactly what it was called, but I was at the point where I was modifying phpFreeChat core code to set a path default that made sense). That also didn't work; phpFreeChat just didn't honor the data_public_url I set. Anywhere.

I tried all of the above steps again, rehashing the chat and clearing my browser cache each time, but never any luck. Pissed off and bored, I gave up.

If anybody finds the solution, you'll be my hero. Otherwise, screw this.

[OldWolf]

Essentially, that's not our software, so it's dificult to say what part of wikimedia might be obscuring phpfreechat's abilities. I can tell you that normally, if you change the parameters, save and upload, and manually rehash the chat (by physical deletion), the parameters WILL change to the new settings. Beyond that I can't say why when using mediawiki it would have dificulties doing so.

Are the other parameter's doing anything?
Where are you placing yours?

[bluecarrot16]

Fair enough; can you elaborate a bit on what "manually rehash the chat (by physical deletion)" means? I was just opening the phpfreechat/index.php file in a different tab and typing /rehash.

As for where the parameters are set, basically there is an "extension file" which is loaded by MediaWiki, which includes a function that is called at a specific point in the MediaWiki request cycle. From there, the phpFreeChat $params array is constructed, then a new phpFreeChat instance is created and ->printChat'd to the MediaWiki output stream. I can't see whether any of the parameters passed in this way take effect, because the chat doesn't load (it just spins, claims to be loading, and spits out a link back to the phpFreeChat site).

I've been coding (including HTML and JS) for a long time, but I'm somewhat new to PHP. I feel like there's some sort of caching going on that I'm just not anticipating, but I have no idea how to test that or investigate it any further beyond what I've already done.

Perhaps I'll try poking at the parameters in the phpfreechat/index.php file and see if those display the same weird caching-esque behavior.

Thanks.

[OldWolf]

Ok, well first off... loading the chat in a different page and rehashing it will load up the default values for that page that you haven't set manually (so, for example, if you hadn't set data_public_url, it will attempt to set the correct values for that page). From here on out, I would suggest you don't load the chat from anywhere but the file it will remain in.

Next, I can offer a guarentee that you are rehashing an entirely different chat using that method, which is why you're seeing no results. Phpfreechat can run as many chats as need be, just by using different server_id's. What you did, without knowing it, was ran two seperate chats. The md5(__FILE__) value will be diferent between the two chats (as it's dynamic). Basically, you were rehashing one chat and wondering why the other wasn't changing.

From here, any time you can't enter the specific file that your working on to rehash it (because it's not loading for example), you need to manually rehash using the manual rehash instructions on the following page:
http://www.phpfreechat.net/rehash

[bluecarrot16]

Ha! Victory.

Okay, OldWolf's suggestion about rehashing caused the chat to start loading, but prototype.js would choke on the server_script_url, which was set to a nonsensical value... so I fixed that to be

Code: Select all

$params["server_script_url"] = $_SERVER['REQUEST_URI'];

Until I realized that this would be cached and wouldn't work for other [chat] pages of the wiki. Then I noticed that the $params["serverid"] was set to $wgSitename (the name of the wiki, according to MediaWiki), which didn't really make sense, so I changed that back to md5(__FILE__), and all was happy again.

Takeaway for MediaWiki users whose chat doesn't work:
1. Set $params["data_public_url"] to something sensical
2. Set $params["data_public_path"] to something sensical
3. Set $params["server_script_url"] = $_SERVER['REQUEST_URI'];
4. Since the extension as it's provided by FireBreather sets $params["serverid"] = $wgSitename, might want to set that to md5(__FILE__).
5. Rehash MANUALLY
6. Enjoy!

Thanks so much OldWolf.

As an aside: I know this might be a lofty request, but for those of us who (somewhat) know what we're doing, it would be nice to have a sortof high-level technical overview of how phpFreeChat does its thing (that explained things like the caching of $params, the function of $params["serverid"], which, if I understand it, is really to differentiate between different sets of cached $params, and the effects of rehashing). Understanding this kinda stuff would've made it a lot easier to debug these issues on my own.

[OldWolf]

Well, I'd like to point out that the serverid could be "chicken soup" as long as it was the same from anywhere you would access it. The serverid is for creating seperate chatrooms. Think of each new id as a brand new server for your chat. As long as it's consistant, it doesn't matter at all what it's set to.

A quick note, while __FILE__ should produce the same value, no matter where you access the chat from (since __FILE__ outputs the active file rather than the parent file), you might want to set it to a string, or an md5 of a string. This will guarentee that you aren't opening up multiple servers.

[hypergrove]

Hi - I'm not sure how FireBreather or BlueCarrot16 got chat to work with multiple wikipages, each page being a separate chatroom, given that they both were defining a fixed serverid. But, following Old Wolf's kind advice, the trick for this is:
$params['serverid'] = $wgTitle->getDBkey(); #w/underscores

On to performance now: one might be tempted to create chatrooms only in the User namespace, implying that the user must be present in the chatroom prior to its accepting /send cmds from ANYONE. Further, when that user leaves, the chatroom should revert to that 'blocked' status, providing an option to the admin to fully erase the present contents of the chatroom prior to the admin's departure. Thus, assigning who is admin is critical:
$params['isadmin'] = $wgUser->getName() == $title;
I'd appreciate it if anyone has thoughts about how I can 'block' processing /send commands until and only when an admin is in the chatroom... best to look at who is in the room each time /send is processed? Or to setup a boolean param stored in cache that is TRUE as long as an admin is in the room?
Thanks in advance.

[hypergrove]

On performance:
(a) are there any stats about the expected change in performance when using MySql not the filesystem?
(b) would it be hard to have users join the conversation in asynch-update mode, ie as 'monitors'? The user would do a /connect to join the conversation, until which manual refreshes are needed for message traffic. Also used for 'away' status during a conversation.
(c) PFC now, when a user disconnects, erases all window content - can that be stopped easily? I'd suggest leaving a conversation means the user is 'returning' to 'monitoring' mode.
Thanks in advance.

[Craig]

For posterity, adding

Code: Select all

$params["server_script_url"] = $_SERVER['REQUEST_URI'];

fixed my problem getting this running in a WordPress template.