Any views expressed within media held on this service are those of the contributors, should not be taken as approved or endorsed by the University, and do not necessarily reflect the views of the University in respect of any particular issue.
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.
blog.inf front page
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 );
date_default_timezone_set('Europe/London');
$locstr = strftime( "%a %b %e %R %Y %Z", $gmttime );
echo $locstr;
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.
After some more checking that things seemed to be OK, I spotted that some “page not found” errors were being generated for requests to bootstrap.min.js. It turns out this was a change of location that I’d not spotted in the new UoE theme, so I had to update our local theme again to mirror the new location of the javascript file. I also took this opportunity to fix the UoE crest and logo link, which I’d just spotted took people to the web.inf front page, rather than www.ed.ac.uk.
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.
The Plone pages not redirected contained resources links to images, style sheets, javascript etc. As these were being caught by the catch-all and redirected, the remaining Plone pages soon looked broken! It was simply fixed by adding the various resource links to the exception list of what not to redirect. There was also a similar problem for the “your not authorised” page if you tried to access the remaining Plone content that required authorisation to view. It too was fixed the same way.
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:
When testing updates of edweb, I’d just been manually coping the live edweb directory and the most recent mysql dump from web.inf, and then restoring them on my test machine. All fairly mechanical, so I decided to script it to make it more automatic.
The thoughts are that this will be useful for maintaining a DR copy of web.inf too. It works, but at the moment there are a couple of potential gotchas. The first is that I rsync the most recent mysql backup dump (we currently take them every 2 hours), but rsync the live/current edweb directory. So there could be a discrepancy between file changes (eg uploaded images) in the edweb dir, and any record of them in the DB which could be a couple of hours older.
This could be solved by rsyncing the corresponding regular tarball of the edweb dir that we also take every 2 hours, or by somehow running a remote ‘om mysql dump’ to generate a “now” copy of the DB. Either way there is still the possibility of the directory and mysql being slightly out of sync, as these are not atomic processes.
The other gotcha seems to be a bug in the mysql component. After doing the rsync and DB restore, I restart MySQL for good measure. The default is for the mysql component to do a mysql dump at “stop”. This seems to continue to run even after the component reports “stopped”, and if it is restarted while the dump is still running, problems ensue. My work around is to add an arbitrary sleep between the stop and start. (note that om mysql restart is also affected). This should be submitted as a bug against the mysql component.
While investigating the latest Drupal security update on web.inf, I noticed again that the cron jobs were behind schedule. I was under the apprehension that EdWeb used Drupal’s poor mans cron (or some version of it), apparently this is wrong.
So I’ve added a system cron to call the site’s cron.php with the necessary key. I’ve added the following to the live/edweb-school.h #ifdef EDWEB_SITE_CRONKEY
!cron.additions mADD(edwebcron)
cron.add_edwebcron * * * * * wget -O - -q -t 1 http://EDWEB_SITE_NAME/cron.php?cron_key=EDWEB_SITE_CRONKEY
#endif
According to https://www.drupal.org/node/2195391 it should be run every minute, so that’s what I’ve setup. In the machine’s profile I define the CRONKEY and it’s all working fine. Slightly concerned about how much noise it might produce if the wget start producing output. We’ll see.
