## Update to EdWeb 1.5 part2

September 24, 2015

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.

Neil

## Plone redirects

September 18, 2015

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.

RewriteCond \$1 !^/student-services/(acl_users|portal_javascripts|portal_css|porta_kss|kupudrawers|plonekupuimages|kupu[a-z]+\.xml|[^/]*.(gif|jpg|ico|png))
RewriteRule ^(/student-services/.*) http://web.inf.ed.ac.uk/infweb/student-services [R=permanent,L]


Yes it could be a bit more efficient, but I think this is clearer!

Neil

## Update to EdWeb 1.5 part1

September 13, 2015

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”.

Neil

## Embedded video test

September 11, 2015

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:

## Cloning web.inf

September 11, 2015

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.