CUNY Academic Commons

bump

As a note, it's likely that this will get punted from the already overcrowded 1.3 milestone. I don't like for these sorts of major platform upgrades to be tied up as part of new feature releases if we can help it. It will have to get its own point-point release in the 1.3.x cycle.

Sounds fine to me. I just don't want us to lose track of a nice offer of assistance with something that has given us a bit of trouble in the past.

Just so I understand, would you like me to stop work on all other issues and just focus on this?

Just so I understand, would you like me to stop work on all other issues and just focus on this?

No. Since you're as far as you are on #1386, go ahead and keep working on it (in parallel with this one, if you can). Once you've finished, focus on this.

Got it.

Boone,

MediaWiki 1.17 was discontinued on June 22, 2012. Should I be trying to upgrade to 1.18.4 or 1.19.1?

http://www.mediawiki.org/wiki/Download

OK, here's what I'm trying to do:

In an earlier update you mention a 1.3.x-MW branch. I think I will create a 1.3.x-MW-1.18 and 1.3.x-MW-1.19 branch so I can try and upgrade to each version on its own "clean branch."

However, this is where I'm running into an issue. It's been a while since I've worked off the 1.3.x branch, most of my recent issues have been branched off master. I get the following two errors when I switch to 1.3.x and load my dev env:

Notice: Use of undefined constant BP_SETTINGS_SLUG - assumed 'BP_SETTINGS_SLUG' in /home/humanshell/sites/wordpress/commons/cac/wp-content/plugins/bp-custom.php on line 643

Fatal error: Call to undefined function bp_core_new_nav_item() in /home/humanshell/sites/wordpress/commons/cac/wp-content/plugins/bp-custom.php on line 649

The fatal error occurs in a function called cac_core_add_settings_nav() that's getting attached to both the 'wp' and 'admin_menu' actions.

I've pulled the latest code for the 1.3.x branch from the repo. Any idea why this constant and function are giving me problems?

What's probably happening is that BuddyPress is not loading when you are running the 1.3.x branch. That's because master branch runs BP 1.6 and 1.3.x runs BP 1.5.x. BP does not roll back in a totally clean way; you would have to run the installation routine again. But in bp-custom.php, we must run some BP functions in the global scope (ie in a plugin that's not hooked to a BP action), so that it's not very smart about loading only when BP is present.

My suggestion: Find the line in bp-custom.php that is throwing the fatal error. Comment out the add_action() or add_filter() that is calling the function. Repeat until you get the site to load. Then run the BP install wizard.

Which means I'll need to run bp install again whenever I switch back to master?

It'll probably ask you to do so, but it won't crash the site if you don't.

Anyway - you should just create your topic branches from the master branch. The MW release will be in the 1.4.x series. I probably should have thought of this before, sorry.

No prob, I don't think any of my other issues currently need me to be working off of 1.3.x. So if I can work on a MW branch off master that would be great. There is no 1.4.x branch currently so I'll just branch my two (1.18, 1.19) topics off of master.

Boone, how would you feel about installing MediaWiki as a git submodule? Might make future upgrades a little easier?

If you want to install as a submodule, that's fine. An svn checkout is another option.

Boone,

I have a feeling that this update might get a little long, so please bare with me...

First - (and I'm a little afraid to admit this on Redmine) I tried to add MediaWiki as a submodule. I have never had so many problems with git! The branching wouldn't work, I kept finding myself on a detached HEAD, whenever I would try to checkout a different cac branch (like going from my topic back to master) a whole slew of files would show up as uncommited while the topic branch showed a clean index state, etc. It was a nightmare; I've used submodules before so I know it's not seamless, but this was just absurd. So I decided instead to just use a fresh 1.19.1 tarball on a new topic branch and move forward from there. Unfortunately I didn't have most of the git errors until I had completed a significant portion of the upgrade process (which is always the way it works). So I basically restarted from scratch after all the submodule problems. Once I had the new topic branch going the upgrade went (slightly) smoother.

Second - once I got my topic branch under control I began by moving the LocalSettings.php and AdminSettings.php files from the old wiki directory (I saved it for reference in a separate folder) into the new one. The first step you take when upgrading MW is to run wiki/maintenance/update.php so it can update the DB to the newest version's required state. Turns out this script will not run while some of our extensions are enabled. So I completely reorganized LocalSettings.php to separate all the "settings" from all the extensions. I then placed a constant at the top of the file that, when uncommented, prevents extensions from loading (all extensions are wrapped in an if() that checks whether the constant has been defined). When you pull the topic branch you will need to uncomment this line so your update.php script can run. Just recomment it after the script completes.

Third - I then moved on to upgrading/replacing each extension individually. Basically I commented out each require line in LocalSettings.php and turned them on one by one as I downloaded new versions of each.

I will try and outline each extension in terms of its working status:

Seems to be working:
AuthWP
EmbedVideo
Lockdown
uniwiki/Layouts
uniwiki/Authors
uniwiki/CreatePage

Not working:
FCKEditor (no "edit in rich text editor" link on the edit page)
TagsAsCategory
PdfBook (no pdf link shows up in the "views" sidebar)
uniwiki/CatBoxAtTop

I'm note sure what the extension does, so it's hard to report if it's working or not:
CommonsCustomHooks
NewsChannel
RSS
uniwiki/CssHooks
uniwiki/Javascript
uniwiki/MooTools12core (MooTools?? Seriously???)
uniwiki/AutoCreateCategoryPages

I tried to get the latest extensions from SVN when I could. Otherwise I just downloaded a tarball. The commits for each extension list whether or not they are from SVN, tarball or have been copied from old MW directory.

Fourth - I had to comment out some lines in the CommonsWiki skin. They were causing the layout to break. I'm hoping if you're the one who wrote that skin you can point me in the direction of an easy fix for those commented parts.

I'm not sure if you'd like to put this up on cdev, but I would really like to get Scott's feedback. My only experience with MW up to this point is reading their docs long enough to determine that I don't want to be a MW admin. :-)

I think what we need is a review from Scott telling us what he absolutely needs and what we can dump as far as extensions go. If we don't use it lets dump it.

You can see all my commits on the new topic branch (1.4.x-MW) here:
https://github.com/castiron/cac/commits/1.4.x-MW

Yikes -- thanks for suffering through this, Dom. MediaWiki is a nightmare.

just wanted to shed some light on the uniwiki extensions, which I added way back in the early days of the Commons. This page includes links that provides explanations of what some of these extensions do.

Also, let's not forget the note from in the main part of this message -- we have an option to work with wikimedia if we want to on this.

Thanks for the link, I'll take a look.

Talking to MeidiaWiki may become necessary. Would like to hear Scott's feedback first though.

I think what we need is a review from Scott telling us what he absolutely needs and what we can dump as far as extensions go. If we don't use it lets dump it.

Agreed. Scott, can you provide any information off the top of your head on the extensions that Dom has listed under "Not working" and "Not sure what the extension does"? I'll be happy to install Dom's topic branch on cdev, but I have a feeling it's going to break some stuff, and we need cdev to work in the near future for 1.4 testing, so I'd like to get as much settled as possible before that point.

A few questions, mostly for Boone:

1. Is our current Mediawiki install broken in any way?

2. What do we gain by upgrading?

3. Is it worth tabling the MW upgrade and instead waiting a bit and attempting to migrate pages over to the WP-based wiki that will be part of CBOX once it is ready?

I'm just not sure that it's worth the trouble we're putting into this -- Dom has spent 10 hours on this already.

My feeling is that we should probably wait and migrate.

1. Is our current Mediawiki install broken in any way?

No more than it always has been. There are little places where things don't work as expected, but things generally work fine.

2. What do we gain by upgrading?

Maybe Dom has looked over the changelogs for the last few releases, but I would guess that they are stability + security fixes. The same sorts of fixes that come from WP releases. It's generally good practice to keep up to date when possible.

3. Is it worth tabling the MW upgrade and instead waiting a bit and attempting to migrate pages over to the WP-based wiki that will be part of CBOX once it is ready?

I personally think this is a better use of our resources. I was just trying to push the MW upgrade through because it's been sitting here so long, and you were once keen on getting it done ASAP. I'm happy to table it.

Dom, Scott -- please let us know your thoughts. Dom, maybe you could look over the changelogs and give us a sense of whether we're missing out on anything crucial. And also please let me us know whether you're so far into this that you really don't want to back off. And Scott, please just let us know where you stand. Thanks.

I have been going over the CHANGELOG, HISTORY and RELEASE-NOTES and, as you can imagine, there have been quite a few changes from 1.15.4 to 1.19.1.

However, Boone is correct, they are mostly bug/security fixes. My inexperience with MW doesn't make me the ideal candidate for analyzing the changes over the past 4 minor point releases, but I didn't see anything that would constitute a "requirement" for upgrading. There are no sections in the files above that outline any urgent or mandatory changes that would endanger the Commons if we decided to stay on 1.15.4 a little longer.

As far as my feelings about the upgrade, I think if we're gonna pour a lot of hours into the wiki shouldn't those hours be spent moving away from MW if that's the ultimate goal? Instead of making our extensions work with the newest MW I could be working on a script to try and automate (as much as possible) the transfer to a WP based wiki. Given the opportunity, I will always choose to spend time moving away from older technology, whenever possible of course.

Boone, have you and I already talked about wordpress-wiki from wpmudev? I feel like we have for some reason.

http://premium.wpmudev.org/project/wordpress-wiki/

Is this being considered for CBOX?

From reading the above, MediaWiki does seem like a real pain to upgrade, and I agree that our time may be better spent. The current version is working fine for now- but if we're at a dead end with MW and looking to sunset it, we need a future plan that will have the same functionality, and ideally allow data conversion. That may be wishful thinking... I can certainly take a look at the extensions - there are some that we had issues with and are not widely used - but I wouldn't want to upgrade to a new version and lose functionality that wiki users are used to. Let me know if you want me to go through each extension and prioritize.

Given the opportunity, I will always choose to spend time moving away from older technology, whenever possible of course.

we need a future plan that will have the same functionality, and ideally allow data conversion.

Here's the rub :) Realistically, getting MW up to snuff - including whatever research and development might be necessary to phase out or update our extensions - is probably going to take in the dozens of hours of dev time. In contrast, while we won't have to do any additional development to get the WP-based wiki solution itself up and running (most of this work will be done as a part of CBox dev), it will take lots and lots of time to handle feature parity and data migration. My guess is that this job will take 5-10x what it'd take to stick with MW, at least in the medium term. Even if we did decide to migrate to a WP-based wiki, there is no way it could happen until at least the spring of 2012, and perhaps beyond, because of other obiligations and priorities.

My gut feeling about all of this wiki business is that we should do nothing at all at the moment. After the first CBox release, when the wiki stuff is live and our dev resources are a bit freer, we can revisit this discussion.

Boone, have you and I already talked about wordpress-wiki from wpmudev? I feel like we have for some reason.
http://premium.wpmudev.org/project/wordpress-wiki/
Is this being considered for CBOX?

No. (a) I've generally not been very happy with wpmudev products. (b) The plan is to build out BuddyPress Docs to be a wiki replacement.

there is no way it could happen until at least the spring of 2012

We're gonna have to travel to the past to upgrade MW!!! I'm not OK with that! LOL

(b) The plan is to build out BuddyPress Docs to be a wiki replacement.

Oh, cool - I didn't know BuddyPress docs was gonna be the core of the new wiki.

No prob, it's experience for when the actual migration time does come.