Jump to content
Sign in to follow this  
aethernavale

MediaWiki Integration

Recommended Posts

aethernavale

Hoping someone here can help me out with it since I know it is working on the Pagelines site. I am using Centos 6.2, Virtualmin GPL 3.9, Wordpress 3.3.1, and MediaWiki 1.18.0. Following the guidelines in "How to Use Integrations" in documents, one of the steps is to place a require_once path to wp-load in the LocalSettings document. If you don't do this, you can't use the PageLines integration, get the warning, etc. However, the *instant* I add this line to my LocalSettings.php file, MediaWiki's functions shut down. A list of the following items I have noticed so far: 1. Attempting to post anything anywhere in the wiki winds up with the error another user has mentioned in a related thread: "Your edit has been rejected because your client mangled the punctuation characters in the edit token. The edit has been rejected to prevent corruption of the page text. This sometimes happens when you are using a buggy web-based anonymous proxy service." Obviously, not being able to add anything to the wiki rather defeats the purpose of having it. 2. Attempting to save any settings in My Preferences fails. Type in changes, click on Save button, changes appear; reload the screen (and / or go to another page then back to My Preferences) and whatever changes are made are gone. With wp-load called in LocalSettings, when you click save the changes DO appear after clicking save, but you don't get the little green box at top that says your changes were saved. Without wp-load called, you will get that box and the changes will be saved. As soon as the require_once line is removed from LocalSettings, everything works fine. This is being tested on a virgin install. Everything is blank. No plugins are enabled or installed. It is literally, install OS, install VirtualMin and prereqs, install WP, install MW. I have tested MediaWiki install with every option I can think of; disabling caching, using binary and UTF-8 modes for database, loading MW with and without extensions, using MW short url setup and default setup, using a different database from Wordpress, using the same database as Wordpress.... I'm at my wits end here. If wp-load is called, MW does not work. Beyond the ability to say that it appears and loads. One cannot change anything in it. In fact, just for S&G I changed the line to wp-config and that will also cause all these aforementioned problems across all the same setup changes. Misspelling it, changing it to a different file, etc, will actually result in errors as one would expect. I have additionally tested with both MW and WP debugging options enabled; all of them. SQL, PHP, etc. I get NO errors. Nothing in logs except webpages being accessed. Firebug doesn't show me anything goofy happening. Please someone tell me the hours I've dumped into this banging my head against a wall aren't in vain. I can see that you guys got it working, and that we are using the same versions for WP and MW at least. So I know it can work, I just know that mine isn't working no matter what I do.

Share this post


Link to post
Share on other sites
Simon
Try this... Open PageLinesWiki.php comment out line 61 like this: [code] // $out->addHeadItem('pl-js', $plhead['js']);[/code]

Share this post


Link to post
Share on other sites
aethernavale
No good. No change to behaviours noted before occurs with the modification above. Edit: Tried a few more things along with that suggestion, still not working. Here is my curiosity question now, based on the suggestion to comment out loading js... do you think this is a script issue, or something deeper? As noted earlier, if I remove the wp-load line from LocalSettings and go back to the 'vector' theme everything behaves normally. What in a vanilla install of 3.3.1 Wordpress would cause just the inclusion of wp-load into LocalSettings to create this behavior?

Share this post


Link to post
Share on other sites
Simon
Well thats what we did when we got the exact same error, it was wordpress' js screwing up MW js. Can you show us a link?

Share this post


Link to post
Share on other sites
aethernavale
No, currently doing this on a test environment so when I have to rebuild it, it doesn't matter. I will try to throw it up as a random something or another though on my actual server. I will post back a link when done.

Share this post


Link to post
Share on other sites
aethernavale
Okay: Test environment is https://test01.aethernavale.net User test, pass l453r5 - will work both for WP login and MW login. Have to accept SSL because it's self signed, being a hastily made no intent on using test site, but wanted to keep as many of the factors the same as possible. The two differences with setup I'm aware of between this server and my test server; MW on my test environment is setup with APC for chaching and INTL package; my normal server is not. MediaWiki link in particular https://test01.aethernavale.net/database

Share this post


Link to post
Share on other sites
Simon
I cant even change theme. Is there way to test this without SSL and APC?

Share this post


Link to post
Share on other sites
aethernavale
That's precisely the problem. With wp-load in the file, nothing works with MW. Remove the line from the file, and everything works again. You can force the pagelines theme by modifying localsettings.php and changing it there, but it still won't accept changes made or allow text entries on the actual website. As stated, on this particular install, APC isn't there. No caching of any sort is occurring at the link I gave you. APC is on my actual test environment, this is just a 'test' setup on my production environment. I have removed the forcing of SSL from the HTAccess, but it's still on for Admin side of WP. Can change that too if you want, not sure it'll do anything.

Share this post


Link to post
Share on other sites
aethernavale
Okay, I made some progress on this. After cooling off for a few hours I came back and hit my test environment with every debug option MW listed, and after sifting through the mass of information I came across something: Class SkinPageLinesWiki not found; skipped loading User::matchEditToken: broken session data User: got user 1 from cache This is a snippit from that 'something'. Broken session data led me to Google Search where I [url=http://www.mwusers.com/forums/archive/index.php/t-1623.html]happened across this link[/url] which has nothing to do with my problem but mentions this error with matchEditToken. Thus, changing the following code in /includes/user.php of the wiki directory from this: [code]public function matchEditToken( $val, $salt = '', $request = null ) { $sessionToken = $this->editToken( $salt, $request ); if ( $val != $sessionToken ) { wfDebug( "User::matchEditToken: broken session datan" ); } return $val == $sessionToken; }[/code] And making it say this instead: [code]public function matchEditToken( $val, $salt = '', $request = null ) { $sessionToken = $this->editToken( $salt, $request ); if ( $val != $sessionToken ) { wfDebug( "User::matchEditToken: broken session datan" ); } return $val == true; }[/code] Fixes the issue. This isn't recommended which is why I only did it on my local test machine, but after making this change the box that tells you your preferences are saved appears, and, on top of that, it *actually* did store the information. It works with and without the earlier suggested coding change of commenting out line 61 of the pagelines theme file. This change also corrected the issue of posting and or changing text in the wiki itself - edits work now. So, all you wonderful people smarter and wiser than me in coding (because I admittedly suck at it, no doubt about that); what does this discovery mean and how can I fix it in a way that doesn't jeopardize my system and site?

Share this post


Link to post
Share on other sites
Simon
I have no idea, could be something with the way you have sessions configured maybe?

Share this post


Link to post
Share on other sites
aethernavale
What is it that needs configuring though? Everything is vanilla, fresh from the download files on a box that is essentially just as fresh. WP and Vanilla work without issue just installing them. I don't know why MW is doing this, nor where I would configure whatever MW is or isn't getting in terms of session data.

Share this post


Link to post
Share on other sites
aethernavale
Okay, so more debugging isolated the issue to the following effects; Restarted everything, back to vanilla Loaded MediaWiki without any changes other than the following two: 1.) [code]wfDebug( "User::matchEditToken: broken session data '$val' != '$sessionToken' n" );[/code] to includes/user.php 2.) LocalSettings.php turn on Debug Logged in to MW ONLY. Did not log into anything else. Debug is clean; there are no session errors on Main Page. Go to My Preferences; receive the following session error: [code] User::matchEditToken: broken session data '' != '7afc47c84e20be2c534f7c78e948c613+' [/code] Despite this error, data saves just fine. Green box appears telling me data was saved. Data is saved. Debug code remains on page though. Go to Main Page - Discussion, type in "Why can't I have my cake" to make sure processing is fine. Preview works. Okay, attempt to Save. Save works. Text is formatted cleanly, no issues (text is formatted good, no session errors). Changed LocalSettings.php to now force wgDefaultSkin to be pagelineswiki and added the wp-load call at the bottom of the file. Go to Main Page. Debugger shows no errors on page; only major difference now is that we see the cookie data has changed from being a rather simple line of just MW's data to a much more complex one including WordPress cookie data. Go to My Preferences. Again, the [code]User::matchEditToken: broken session data '' != '7afc47c84e20be2c534f7c78e948c613+' [/code] error appears. Attempt to change some datapoint, lets say I'm a guy. Hit Save. Data is not saved. No green box appears saying data is saved. Debug says: [code]User::matchEditToken: broken session data '7afc47c84e20be2c534f7c78e948c613+' != '7afc47c84e20be2c534f7c78e948c613+' [/code] So somehow my session is losing a character. Just one, from the end. I've got absolutely no knowledge of this or why. Attempt to change / add text. Receive aforementioned error regarding 'mangled punctuation characters'. Text does not save. Well, I've fixed this before: [code]return $val == $sessionToken;[/code] now becomes [code]return $val == true;[/code] again. Go to Main Page. No errors noted by debug. Go to My Preferences. Receive [code]User::matchEditToken: broken session data '' != '7afc47c84e20be2c534f7c78e948c613+' [/code]. This occurred previously, without any changes made. Attempt to change something. Since I said 'male' earlier and that saved, lets change it to 'female' now. Green box appears. Data is saved. Same code remains as when initially accessed My Preferences, but data saved. Go to Main Page. Go to Discussion. Attempt to edit previous text. Well, now I see an issue that I didn't notice before. Preview works, Save works. However, now I receive this: [code]"Why can't I have my cake" [/code] instead of [code]"Why can't I have my cake"[/code]. No formatting works at all. Bold, italics, nothing. FUBAR. Well, taking the info from [url=http://www.mediawiki.org/wiki/Project:Support_desk/Archives/Installation/003#Cant_edit_or_create_pages_after_correct_installation]this link[/url] and some looking around, I can make this code change to /includes/user.php [code] public function matchEditToken( $val, $salt = '', $request = null ) { $sessionToken = $this->editToken( $salt, $request ); if ( substr($sessionToken, -1) == "" ){ $sessionToken = substr_replace($sessionToken, '', -1, -1); wfDebug( "User::matchEditToken: sessionToken corrected to '$sessionToken' n" ); } if ( $val != $sessionToken ) { wfDebug( "User::matchEditToken: broken session data '$val' != '$sessionToken' n" ); } return $val == $sessionToken; } [/code] And now let's see what happens. Go to Main Page. No errors noted by debug. Go to My Preferences. Receive the following [code]User::matchEditToken: sessionToken corrected to '7afc47c84e20be2c534f7c78e948c613+' User::matchEditToken: broken session data '' != '7afc47c84e20be2c534f7c78e948c613+' [/code] We can see the edit at work here, because this is the same error that happened on the 'good, clean' install but now the missing character is available and we get the new print. Attempt to change data on My Preferences page again. YAY! Green box. Data is saved. Things are looking good. Let's go back to Main Page > Discussions and try and edit the cake text again. Nope, no good. I can save and preview like before with [code]return $val == true;[/code], but again MW formatting is lost. I receive the same garbledygook with formatting as with the return true clause. How about we go back and make that edit you initially proposed. What will that do, I wonder? Line 61 of PageLinesWiki.php... removed. No, I'm not wasting time with // here, lets just make it gone and be certain. Go to Main Page. No debug notices out of the ordinary... Go to My Preferences. [code]User::matchEditToken: sessionToken corrected to '7afc47c84e20be2c534f7c78e948c613+' User::matchEditToken: broken session data '' != '7afc47c84e20be2c534f7c78e948c613+' [/code] Familiar code again appears. Make a change. Change saves! Green box appears. Code remains the same. One down... Go to Main Page > Discussion. Attempt to change cake text one last time... Nope~! No good. Text formatting is still completely lost. MW remains defunct. I wonder though... what happens when I change the LocalSettings.php file back to having default skin be vector and removing the wp-load bit? Take note; the changes made earlier to includes/user.php are still in effect. Go to Main Page. No debug information out of the ordinary... Go to My Preferences. Get the [code]User::matchEditToken: sessionToken corrected to '7afc47c84e20be2c534f7c78e948c613+' User::matchEditToken: broken session data '' != '7afc47c84e20be2c534f7c78e948c613+' [/code] stuff again. Attempt to save... it works! I can save my preferences. But we're not out of these woods yet, seeing as what we know about other things: Go to Main Page > Discussion. Attempt to change cake text.... It works. Text is saved with formatting. So... after all this, I'm back to I have no clue. Again, from the word go as soon as you put in wp-load to LocalSettings.php everything goes wrong. Juryrigging it kind of works, but not really. I can make functionality go from nil to defunct with PageLinesWiki; not really what I'm after though, obviously. After all of that... any ideas? What else is there for me to possibly do here?

Share this post


Link to post
Share on other sites
Simon
Looks like a magic_quotes problem, is it enabled?

Share this post


Link to post
Share on other sites
aethernavale
No. Magic quotes are disabled by default on initial server setup. magic_quotes_gpc = Off magic_quotes_runtime = Off magic_quotes_sybase = Off From php.ini for the server.

Share this post


Link to post
Share on other sites
Simon
Maybe mediawiki needs it, we had a similar issue, I turned it off because our bugtracker will not work with it on, and wordpress does not need it. Then i got a report from our docs manager that MW was now unusable so i had to turn it back on an make a small modification to the bugtracker.

Share this post


Link to post
Share on other sites
aethernavale
Tried, enabled magic quotes on the server, restarted httpd, no change in behavior. Without modification to user.php and with wp-load in localsettings.php, and then with modification to user.php. In the former, no changes are made/saved, attempting to post text results in 'mangled' error, and debug reports session error from above. With the latter, changes are made/saved, attempting to post text is allowed but all formatting will be disregarded and any special characters escaped, and debug reports also what I showed above. Since it wasn't mentioned before; I'm using PHP 5.3.10, MySQL 5.5.20, and Apache 2.2.15.

Share this post


Link to post
Share on other sites
Simon
We have this at the top of MW config[code]ini_set('magic_quotes_gpc', 1); ini_set('magic_quotes_runtime',1); [/code] Also we use memcached for sessions[code]## Shared memory settings $wgMainCacheType = CACHE_MEMCACHED; $wgParserCacheType = CACHE_MEMCACHED; # optional $wgMessageCacheType = CACHE_MEMCACHED; # optional $wgMemCachedServers = array( "127.0.0.1:11211" );[/code] Our setup would not work at all without magic quotes. Mind you we are running cpanel which has different defaults as you have set the server up yourself.

Share this post


Link to post
Share on other sites
aethernavale
Adding those lines to localsettings with magic quotes enabled still didn't cause any changes to the events as described previously. I don't have memcached setup since it required extra settings to do so. Do you think that could potentially make a difference? I know that sessions are being saved, written, etc; I can see the files being made and such on the server side. The files aren't corrupted as far as I can tell, I can open them up and read them and they have tangible data in them. Setup on this is really initial loading: Make VM, install Centos 6.2 from minimal, install wget, get EPEL and REMI repositories installed, do update, install perl and a few other prereqs, [url=http://www.virtualmin.com/download.html]run the Virtualmin GPL install script[/url], setup domains for testing in VirtualMin, install WP, MU... and yeah, can't get past this massive roadblock here at initial setup of the site. Is there anything in particular that you can think of that would cause this behavior that would be different between the setups?

Share this post


Link to post
Share on other sites
aethernavale
Okay, update time. The issue turns out to be magic quotes. What I managed to isolate it to: The issue only appeared when wp-load was called in LocalSettings, and we worked too hard on every other angle for it to be from MW's side of the house. That left WP the culprit. So I set off on the troubleshooting task of halfsplitting every file loaded by Wordpress starting at wp-load and continuing on. And I found it. The file: wp-settings.php. Location: Lines 215-216. [code] // Add magic quotes and set up $_REQUEST ( $_GET + $_POST ) wp_magic_quotes(); [/code] WordPress DOES use magic quotes. Apparently their own little setup of them. If you look in the first part of that file you might think otherwise because it reports: [code] // Disable magic quotes at runtime. Magic quotes are added using wpdb later in wp-settings.php. @ini_set( 'magic_quotes_runtime', 0 ); @ini_set( 'magic_quotes_sybase', 0 ); [/code] From lines 31-33 of that same file. Guess what? Commenting out line 216 of wp-settings.php fixes *everything*. At least I hope. I have no idea what removing this function from WordPress will cause later on... any thoughts to how much I'm shooting myself in the foot with this? I don't really understand why WP uses them though... they're not good practice...

Share this post


Link to post
Share on other sites
Simon
We only enabled magic_quotes_gpc for it to work here.

Share this post


Link to post
Share on other sites
aethernavale
Well, turning them on in my php.ini didn't fix the issue (and I rebooted httpd, cleared cache, my cookies, etc... if it was going to work it should have, had all the opportunities to do so). I don't know why not, but it didn't. Removing this line from the Wordpress core files fixed it. Of course, when I started this endeavor I had no idea what exactly I was looking for, I just went through and started chopping out sections of code in a half-splitting fashion until I found the code that was causing me headaches. I guess I was too hung up on it being a MW issue that I didn't deign to look in other locales. Since my previous post 'fix' I did some Google searching and found some recent posts on WP talking about this. These various people also say to comment out that line, so I'm assuming at least for now that my doing so isn't going to break anything. [url=http://wordpress.org/support/topic/magic-quote-documentation-out-of-date]An example of one such post[/url]. Personally I'd rather not use them, for all their trouble and especially since they're going away with the next PHP.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

×