CUNY Academic Commons

Boone,

I've created a new doc here on Redmine (can move it to the Github repo's wiki if you'd prefer) outlining the steps I took to get the MESTC files added:

http://redmine.gc.cuny.edu/documents/84

Before I merge or push anything, I'm wondering if we can make a pit stop on cdev so Kimon can explore import/export and menu/widget activities in a safe sandbox. This way he'll be able to tell us exactly what isn't working and we can have a place to adjust the CSS to handle the hiding of the Commons Bar / site footer.

I am also unfamiliar with the plugins he's using, so feedback from him on whether they're working correctly (or not) will vastly speed up the release of his sites.

If we can do this let me know how you want me to proceed: just push up my topic branch to our repo, or merge back into 1.4.x branch and push that up?

Document looks great, Dom.

Good idea about testing on cdev. Please push your topic branch up to the repo, and I'll switch cdev to that branch. (I'll also relay the cdev creds to you, if you don't already have them - you should be able to mess with cdev as you'd like.)

Sorry for the delay, was up very late/early working on all kinds of stuff. mestc-transfer topic branch has been pushed to the repo:

https://github.com/castiron/cac/tree/mestc-transfer

I have the creds for cdev if you're talking about ssh'ing in. Is that how we handle testing on cdev, ssh in and then checkout different branches for testing?

Is that how we handle testing on cdev, ssh in and then checkout different branches for testing?

Yessir. The only complication is that if someone has been messing around on cdev and has left uncommitted changes, you won't be able to switch the branch straight off. If that happens, either stash the changes and reapply after switching branches, or output the changes to a diff file and let the guilty dev know.

Since you've got the creds, could you go ahead and do this yourself? Thanks!

A quick follow up - Dom, after you've pulled the changes to cdev, could you do the following to get Kimon set up?

1) Make sure he has an active user account on cdev (he should, he was one of the first users of the Commons!)
2) Create a new cdev blog for him, and make sure the new theme is enabled for the blog (or networkwide, doesn't matter for cdev)
3) Email Kimon with instructions on how to access cdev (the Apache u:p combo) as well as a short list of things to check? We don't want to ask him to rebuild the whole site on cdev, of course, but just enough to see whether the plugins are working like he'd expect.

Once Kimon has made his checks, I think we're good to release. Muchas gracias!

Agreed. Many thanks, Dom.

Boone,

I have the Apache u:p to view cdev, what I don't have is a login to actually get into the admin to do what you've asked. I think I had one when I started, can you do #1 above for me first? Once I have a u:p that is network enabled I'll jump in and get Kimon all setup so we can get this release out ASAP.

Hey Dom. You've got a Super Admin account on cdev already. The username is humanshell, associated with your gmail address, if you need to do a password reset.

Got it, password has been reset, and I do have network access.

I'll update as soon as I've got the above line items done.

Boone,

A few questions about working with cdev since this is my first time:

1.) cdev is asking for the passphrase of it's id_rsa key when I try to git fetch from the repo to refresh the latest list of remote branches. Can you send that to me, or call me and tell me what it is?

2.) of course since this is my first time working on cdev the current branch has uncommitted changes. :-) I've only used stash a handful of times. What do you mean by: "stash the changes and reapply after switching branches"? Do I stash then switch branches and then pop the stash? That doesn't sound right to me. That would mean I was popping the stash onto the branch I switched to - so if I stash then switch to mestc-transfer and then pop, won't I be popping those changes onto the mestc-transfer branch? Do you mean stash then switch branches and then pop the stash back onto the original branch after switching back to it at a later point? Crap, now I'm confusing myself. Maybe a quick call on this to get me up to speed on git stashing? :-)

2) cdev doesn't have any unstaged changes at the moment. It has untracked files, but you can ignore those. (The ones that matter for our purposes are "Changed but not committed")

Do I stash then switch branches and then pop the stash?

Yes, that's what I'm suggesting. The reason for unstaged changes on cdev is almost always that one of the devs has put something up for testing purposes. If you stash the unstaged changes and then switch to a new branch, you might mess with that developer's testing. By popping the stash back on top, you can test your own branch without messing with the other dev's testing. The only problem would be if your branch and the unstaged changes touched the same code, but that's rarely the case.

I'm aware that this is not an ideal situation. Tests should be done on single-purpose branches.

In general, don't sweat this too much. Nothing is ever left unstaged on cdev that can't be replaced. If you get stuck, just

git checkout .

(1) The SSH passphrase is the same as the MySQL password in cac-env-config.php.

As usual, your answers cause the world to once again make sense. :-)

When I first saw untracked files I thought I may mess up someones testing by switching to another branch without committing. But I forgot that only committed files will change from branch to branch so switching will leave the untracked files where they are. And your stashing/popping explanation makes total sense. I guess if two devs were working on the same issue, there could be conflicts but with everyone working on their own you're prob right - very few chances for code overlap. I know it's only a testing server, I just don't want to mess anything up.

The passphrase worked fine, moving on to the tasks from #5 above.

I appreciate the caution, Dom ;)

OK, I've added the requested themes and plugins to a topic branch, pushed that up to our repo and switched cdev to that branch.

I verified that Kimon has an existing account (under the email address kimon@keramidas.com).

I enabled all the new themes and plugins.

I created two new sites: thesegalcenter.cdev.gc.cuny.edu and preludenyc12.cdev.gc.cuny.edu

I activated the appropriate themes for each site.

Kimon,

Would you please log into the cdev testing server and make sure that all the plugins and themes are behaving the way they should? Once we verify and test on cdev, we can confidently deploy your two new sites with the 1.4.3 release in a few days.

Please don't hesitate to contact me with any problems, questions or concerns.

Continuing a conversation from the email thread:

shadowbox-js downloads it's source files to blogs.dir which is not under source control.

If shadowbox-js is downloading its source files to blogs.dir, then it should already have the permission to do so on cdev (the apache user has write access to blogs.dir). What happens when you click the link to download the files from within the plugin?

Boone,

You're not going to believe this! Thanks to Raymond Hoh I actually tried to update this issue by replying to the email notification with the following message:

"The WP admin page asking for FTP uaername and password comes up."

So here I am sitting around waiting for your reply and I get a delivery status failure email today!

Anyways, that's what happens when I click the link on the shadow-js settings page to download it's additional src files. WP changes to the FTP authorization page asking for the user/pass to download to the blogs.dir directory.

I tried ssh'ing in so I could "sudo wget" but apparently the commons account on cdev doesn't have sudo access.

Let me know how you want me to proceed.

I was able to do it using wget without sudo. Looks like it's set up now.

This is a side effect of the fact that the plugin dev tried to make the plugin smart about where it keeps its library files. It's actually a good thing broadly speaking, but he's using an unreliable method to test for directory permissions on systems like ours, where Apache can only write to certain subdirectories. I know the guy who wrote it - maybe I'll ping him with a suggestion.

Would you mind making a note of this in the release notes, so that I remember to do the same thing at deploy time?

ACTION_REQUIRED doc has been updated with a reminder.

Dom, thanks for reminding me to update the ACTION_REQUIRED doc myself! :)

No prob. :-)

Got an email from Kimon this morning saying that it's still not working. I realize now that this is because I put the plugin files into blogs.dir/1/, not blogs.dir/[mestc-blog-id]/. This is going to continue to be a problem anytime someone activates the plugin on the Commons. Even if we allowed plugins free rein over where they install library files - which is a non-starter - it would still be sorta absurd for us to have dozens of copies of the shadowbox script strewn throughout blogs.dir. For that reason, I'm wary of using the plugin in its current state.

Dom, can I ask you to take a look at the source code of this plugin to see how hard it would be to do the following two things?
(1) Change the path-to-shadowbox so that it always points to some central location, maybe wp-content/lib/ or something like that (whatever seems right to you is fine - just not in the plugin folder where it will be overwritten on update)
(2) Make sure that the "files not found" dashboard warning is not thrown (if you do (1) completely, this should happen automagically.

The most lightweight way to make this happen is to add an apply_filters() call, so that we can simply filter the location. The plugin currently uses wp_upload_dir() to construct the upload path (which is the blog-specific upload directory, which is what's causing the problem); you'd add a line to do something like this:

$upload_dir = wp_upload_dir(); 
// whatever else he does to construct the path, then:
$path_to_shadowbox = apply_filters( 'shadowbox_location', $path_to_shadowbox );

I think he generates the shadowbox path in several different places in the plugin (admin.php, frontend.php) so you may have to hunt around a bit.

Because we need to get this release out the door, we can just make this change and get on with things. I'll then pass a patch along to sivel (the plugin author) with a suggestion for a more complete fix (the apply_filters() is pretty minimal; a more complete solution is to automatically search a central location on multisite installations). Hopefully he will accept the fix for the next release.

One last point about this - I'm thinking it should be pretty straightforward. If it looks like it's going to take more than an hour to make this change, let me know first and we can see what else might be done (like manually injecting the shadowbox script into the theme, rather than using a plugin for it).

Kimon also points out that there are problems with Event Calendar. From his message:

The Events Calendar: This plugin is working well except for a weird issue with the slug that the events list appears under. As I use the name 'events' for a different page I change the slug to 'events-list' in the MESTC theme. This impacts both sites for a lot of obvious reasons. Although it works on my MAMP install, for some weird reason on cdev the slug I am inputting is not being recognized as the link for the events calendar auto generated pages. Even weirder, it seems that every time I change it the link that works is the one that I have just changed it from. So for instance if slug says events-list that won't work. If I change to event-list, event-list won't work but events-list does start working in some places. Was wondering if we could maybe uninstall that plugin and reinstall it, or at least install it in a way that I could activate and deactivate it to see if that does the trick. It is a problem on both sites and really screws up with the navigation to events pages, calendars, etc.

Can you have a look at this? I have no idea how the events calendar stuff works.

I'll be looking through the plugin later tonight to try and adress everything above. I'm pretty sure that Kimon replied that the events calendar was working, I might be mistaken though. I will look into it as well.

Since we are trying to get this out the door, why don't we just let the plugin put it's files where it wants and then get a patch to the author so the next version behaves the way we want it to? Can't we only show the plugin to Kimon so that other users aren't enabling it while we help to create a more Multisite friendly version of the plugin?

Can't we only show the plugin to Kimon so that other users aren't enabling it while we help to create a more Multisite friendly version of the plugin?

Not easily, at least not for this release. (We'd need to use a separate plugin for this.) And Murphy's Law says that dozens of people will activate the plugin if it's available, and each one will send a support request :)

Here is the new MESTC theme for installation

Hi Kimon -- don't think the attachment came through. Can you repost?

Kimon,

You may just want to email it to me.

Posting here will make your theme files available publicly.

Hey everybody, just wanted to give a quick update before heading out the door to class.

I'm sorry, I didn't get to look at the plugin the way I wanted to last night. I do have a three hour break today between classes though. I'm going to try and take a look then, if for some reason I can't, I will definitely be able to tonight. Either way I have all Saturday and Sunday to get something figured out so that these sites can get up as soon as possible.

Kimon,

The new themes have been pushed up to the cdev repo, let me know if the changes fix the issues you're experiencing.

Boone,

I am looking into our shadowbox issues now, I'll have an update for you in a few hours.

Dom - Thanks for the update. I'll have a look at this in the next few days. It could just be that the plugin is making an unnecessary check of the apache user's file permissions. (You're correct that it's not related to WP caps/roles.)

Boone,

My changes to the plugin force it to create and look for its src files in /blogs.dir/shared_lib/ when running multisite. Could we move the shadowbox-js dir from /blogs.dir/413/files/ into a new /blogs.dir/shared_lib/ directory? I tried to ssh in and do this so I can check to make sure the plugin is at least half working, but none of the passwords I know for cdev works for sudo.

So if you could send me the sudo creds under separate cover, or move them for me, Kimon will be able to test and tell us if shadowbox is working correctly once it has access to its src files.

Just checked on two sites. Prelude looks like to be completely in good order. Hoorah!

MESTC I can't tell because apparently I uploaded an incomplete theme. No idea what happened but I think my sync software got confused and deleted some files I had renamed. So most of the site is broken for the moment. I have reconstructed the lost files and added a new folder on my share. Dom would you mind putting up this theme. Sorry for the inconvenience.

As for Shadowbox and target releases, that feature is very low on the list of necessities at the moment and as I wrote to Matt (and Boone) we are reaching a timetable concern as we get closer to the launch of our season. We could probably proceed without that feature for the moment as it is more cosmetic than necessary and there might be an analog in the existing Commons plugin kit (although we prefer that one ideally). Is there any way that if the two themes are good to go by today tomorrow or Tuesday that we could still be part of 1.4.3 and not have to wait for 1.4.4?

MESTC has been updated with your newest files.

Take a look and let me know if everything looks good.

Hi all. If everything but Shadowbox is working correctly at the moment, I'm happy to put this back into the 1.4.3 release, and worry about shadowbox for the next milestone. Kimon, give a heads up when you've had a chance to test.

Just tested and we are good to go on both fronts. You guys have been amazing, thanks for turning the theme around so quickly Dominic.

I am prepared to move forward without Shadowbox for the time being. We can go ahead and use another plugin or just not rely on having an image box function for the time being.

How does that sound?

BTW, I think that the Events calendar problem was in fact a settings issue, and when I changed to Default Events Template from Default Page Template that fixed things. Thanks for that tip Dominic.

No prob, glad it was something so simple and not a plugin conflict, or something worse. :-)

Boone,

As far as shadowbox goes, I think if we get the src files into /blogs.dir/shared_lib/ it should work. I know that's no where near a fix, but the changes I made to the plugin in our repo ought to pick up those files and work. We can then work with the plugin author going forward to see if he likes the changes I've made and will incorporate them into a new version.

Nice work, all -- thanks. Glad we're able to get this in 1.4.3

Ah, that makes more sense. I some how got the impression from earlier updates that it "needed" to be in /blogs.dir/.

Making the appropriate changes now...

Boone, Kimon,

I've adjusted the shadowbox plugin files to look for its src dir one level up in /wp-content/ instead of /wp-content/blogs.dir/. Therefore /shadowbox-js/src/ in now under version control.

I've tested on cdev and everything seems to be working. Although (like the events plugin) I've never used shadowbox, so Kimon, could you please test and make sure all expected functionality is there?

Let me know if there are any issues I may have overlooked.

Nice work, Dom! Thanks to all for getting this done.

Works on both site. Awesome work Dom!!

Glad we got everything into 1.4.3 like we planned, thanks to all of you for the help and feedback.