“It’s sair to bear, when you get a pair!” – A traditional saying, exclaimed by players of the “High Low” game, upon the revelation of the same card as the preceding one.
Check soon for an official entry in Urban Dictionary.
On Tuesday afternoon, and update to the EdWeb distro was released – 1.6. http://dist.drupal.is.ed.ac.uk/project/uoe_distribution, and the following day the site started warning us that there was an update available. So far, so good.
The following day I updated webtest.inf with a fresh copy of the live web.inf site, and did a diff of the code. It seemed mostly the latest updates to drupal core that we were missing, plus some other EdWeb changes, but it didn’t look like new functionality, and the release notes didn’t mention anything.
When I tried the recommended upgrade procedure using drush it seemed to go smoothly, more smoothly that previous updates, but the site is now broken, and all pages reporting the error:
Fatal error: Class name must be a valid object or a string in /disk/data/edweb/includes/common.inc on line 7998
More worrying, it also reports the same when doing drush commands, even drush status. I don’t really know what to do, so I’ve reported the problem to website.support@ed (UniDeskI151120-0697) and given then copies of the site and DB before and after the update.
I suspect it is a problem with some content we have, rather than our local theme, as happened once before in the early days. Some simple debugging shows
$type_info = entity_get_info($entity_type);
Is returning an undefined value for something called “rules_config”, which seems to be a module used in the distro. My hope is that someone who knows will spot a problem with our DB, and give us some SQL to fix it.
In the meantime I’m going to revert webtest.inf back to the live web.inf, remove our local theme, and try the update again to see if that makes any difference.
While looking at the various drupal versions we have, I spotted that we had an old version on canny.inf (our www.inf DR mirror machine). A while a go I’d started setting it up to add a mirror of web.inf (drip), but obviously hadn’t quite finished it off.
So I’ve now got something going, that every four hours (when the normal www.inf DR copies are taken) it also rsync’s the data from web.inf and restores web.inf on canny.
At the moment, it was simpler to have the web mirror running on a non-standard port (I can’t remember why at the moment) so the DR copy of web.inf is actually http://dripped.inf.ed.ac.uk:8088/.
While doing this, I hit some problems with stopping and restarting MySQL, it was taking longer to start up/shutdown than expected and then it was restarted. Some things complained about mysql not being available. Co-incidentally Duncan from physics hit a similar problem, so some work may need to be done to make stopping and starting more robust. I’ll probably add a “dont do backup at stop” option too.
Not really I’m supposed to be looking at, but I did a little playing with WordPress today. One was to revisit my attempt to install JetPack on wobleg.inf which previously would only partially work if I enabled its DEBUG_MODE. I presumed then the “sign in/connect” problem was due to our Cosign authentication system instead of the default WP login.
I downloaded the latest version, and initially the same problem, it reported a failure to authenticate or connect, or something. Then I wondered if it was a firewall problem, as wobleg is blocked from the outside world, so I opened the HTTP and HTTPS holes, and I was then able to connect/sign in to WordPress.com (which JetPack requires).
JetPack certainly has lots of useful features (similar to those provided by WordPress.com), but rather scarily it also allow you to then manage your wobleg.inf (blog.inf) site via WordPress.com, eg add, edit, delete posts, and more if you allow it.
The recommendation is to network enable JetPack, though individual sites do not need to connect jetpack to their WP.com account.
All this sounds a bit scary, and I’m not sure about installing it on blog.inf without some more testing.
While fiddling with WordPress, I couldn’t resist having a quick look at the request to improve the current front page of blog.inf. One of the comments was that the list of “Updated Blogs” is lengthy and shows no indication of when the particular blog was last updated. There is a project (not mine!) to give it a major revamp, https://computing.projects.inf.ed.ac.uk/330/ , but it turned out to be very simple limit the list of blogs. It turns the local theme calls
get_last_updated() which produces a list of the 40 most recently changed blogs. Giving it some extra args it now only lists the 20 most recent. I’ve also extracted those last modified dates and it now shows those too.
$gmtstr = get_blog_status( $details[ 'blog_id' ], 'last_updated');
$gmttime = strtotime( $gmtstr );
$locstr = strftime( "%a %b %e %R %Y %Z", $gmttime );
Without the timezone stuff, it just reported UTC time. Not a huge difference, but hopefully the old and stagnant blogs will be less visible.
Kenny reported problems when trying to make use of the new subsite footer options of the homepage content type. The problem appears to be our “local search” theme, not being compatible with the new multi-colours option of the latest UoE theme.
If you choose one of the multi-colours (or even the default red) from the homepage subsite settings, then you can add the footer stuff, and have it stick. The problem (I assume) is that this becomes a new theme, attached to that homepage, overriding whatever sitewide theme we may have (our localsearch version of UoE), and so we lose our localsearch and ability to hide the banner image.
Co-incidentally, IS were asking for my patches to EdWeb to support our RFC request. I explained that we didn’t actually patch EdWeb, but used our own theme, and offered to produce patches to the UoE theme that did the same. They were happy to just get my complete theme code, but perhaps we will have to go down the”patch EdWeb” route, rather than try to sub-theme. It will make upgrades more problematic, but should mean we have less issues when new features are added.
Of course, even better would be if our two RFCs (local search and hide banner) get accepted into the main EdWeb distro, then we won’t have to worry about patches or sub-themes.
The Uni EdWeb project now has a Change Advisory Board (CAB), and I’ve submitted the three things our local sub-theme of the UoE theme does as Requests For Change (RFCs) to the board chair – Stratos.
Of the 3 things: local search, removal of banner image and fixing the UoE crest and logo link. The first two have been submitted as RFCs, but the UoE crest link has already been recorded as a bug to be fixed. The RFCs can be seen at:
We’ve also been asked if we can provide a “budget” either in manpower or cash. I’ve said it’s unlikely, other than my patches, but I’ve asked Craig to clarify that.
Stratos has also asked if I would do a presentation at an upcoming Web Publishers monthly meeting. I’ve said I would, but will need to check some facts/bugs with the Web Project team before doing any slides.
I finally applied the latest EdWeb update (1.5) to web.inf. Having first given it a few dry runs on a clone site. It went mostly without incident, and so far no problems have been reported/spotted !
After trying the EdWeb update on a clone of web.inf, I noted that a few manual settings were not preserved following the update (something we’ve been warned about if we’re not using the Features module). I’ve noted those manual changes in my project directory (web-config-changes), but boil down to enabling the rich text editor toggle, and various Organic Group permissions for the new OG role “infweb editor” on the homepages OG node.
I also had to update our version of the UoE theme (with local search and no banner image) to match the latest page.tpl.php file.
To do the upgrade, the plan was to take a copy of the DB and edweb directory (so I could roll back if necessary), run the various recommended drush commands to do the actual update, update our local theme, and then re-apply the manual config changes. These were the steps I had to do when trying it on the clone.
However, during the actual upgrade, the “drush updatedb” terminated with an “uncrecoverable error”. It gave some warnings, as my test had done, but I’d not seen the unrecoverable error before. I decided to press on anyway.
The next drush command “drush up drupal”, warned that there were still DB updates pending, and proceeded to do them (in my previous test, this was uncessary), it ran through the updatedb again, and this time it completed without an error.
At this point the web site looked fine, I went to redo the manual configuration changes, but I didn’t need to. This time they had survived. Which was obviously good, but makes me wonder what is different about my cloned version of web.inf.
So all seems to have gone OK. It’s a bit of a concern that my clone of the live web.inf.ed.ac.uk doesn’t seem to be an exact copy, given the behaviour differences during the updates. I’ll have to check that I’m not missing something, but it should be as simple as taking (and restoring) a copy of the edweb directory and the MySQL database, which is what I believe I’m doing.
Next to do will be to try the EASE/Cosign authentication again with this latest EdWeb release. IS have added my test webtest.inf to EASE, so I can try that to see if it “just works”, to rule out my previous difficulties when using our local Cosign.
Kenny asked that we now start redirect requests from the old Plone student-services pages to the new EdWeb pages, rather than just relying on the “This is old” banner that put on all the Plone pages.
So he sent a list of specific “this goes to that” redirects and also a request for a “catch-all” so that all other old student-services pages just be redirect to the new student-services front page. Remembering that there are still small pockets of Plone content that are still needed (until we have restricted viewing permissions in EdWeb), and that these should be excluded from the redirects (and the “This is old” banner).
I set this up, and tidied up some of the other adhoc ISS redirects in the server config, and it nearly “just worked”! I missed a couple of things.
Yes it could be a bit more efficient, but I think this is clearer!
Finally had some time to look at updating web.inf to the latest EdWeb release, 1.5. Rather than updating the live site web.inf.ed.ac.uk, I first tried it out on a copy of web.inf running on adpurl. See my previous post on creating a script to now make creating a clone of web.inf.
Following the usual instruction on updating via drush on the http://dist.drupal.is.ed.ac.uk/project/uoe_distribution web site, it sort of worked, but there were some obvious graphic anomalies. I guessed this was due to our local modified theme that gives us local search, and removes the banner image. To achieve those I had to ship a modified version of the page.tpl.php file from the normal UoE theme, and doing a diff I could see that some things had changed. So I’ve updated our theme page template with the differences from the latest 1.5 template.
The updated template fixed the layout, but some more work may be needed if our theme is to support the new colour palettes that 1.5 now supports. Simply giving one of them a quick test, replaced our theme altogether, so you got the “blue” theme for example, but you also got the banner image back and the default “search ed.ac.uk” search function. Fortunately Kenny says he’s happy with the default red scheme for now.
EdWeb updates always warn you about the possibility that some settings revert back to the EdWeb default during an update. With previous updates, we seem to have got away with this, but this time it looks like we haven’t. We’d changed some default settings so that web editors could opt NOT to use the WYSIWYG ckeditor, however this is one setting that’s been reverted back to default following the update, there could be others. The recommended solution is to use the “Features” module to record changes and then have them reapplied following updates. I’ve not yet spent any time looking at this, but it looks like I will now have to do so.
So as it stands, web.inf is still running 1.4, I’ll look at what other settings have been reset, and workout how to make them persistent via the Features module. That will be “part 2″.
Just seeing this this work. I just cut and paste the <video> markup from http://www.nutshell-videos.ed.ac.uk/barbara-webb-insect-robots/ into the “text” editor (rather than “Visual”) of WordPress.
I had to adjust the width to get it to fit in my odd, fixed width theme.
Alternatively from the visual editor I can do “Add Media” and select “Insert from URL” and then paste in the URL to the video, in this case http://podcast.is.ed.ac.uk:8080/Podcasts/cseresearch/webm/inf-barbara-webb.webm, and then I get the following: