EdWeb 1.7

January 29, 2016

Last week EdWeb distro 1.7 was released. This week I tried installing it on webtest.inf, first as a fresh install (which gave and error) and secondly updating a clone of web.inf, which worked fine.

The failure, when doing a fresh install, was the same problem Craig had last week, this was my chance to see it for myself. The problem turned out to be a new test to make sure that the PHP variable max_exectution_time was suitably large, but using drush from the command line to install, then that var is set to “0” indicating unlimited.

I submitted the issue and patch via http://dist.drupal.is.ed.ac.uk/node/446 which will be incorporated into the next release. I tested the fix on their updated dev version.

The plan is to update web.inf.ed.ac.uk on Tuesday morning.

Kenny’s been asking again about EASE and restricted pages. I must have a look at that soon.


EdWeb 1.6 update and banner

December 2, 2015

The first attempt to update a fresh copy of web.inf running on webtest.inf, didn’t work. And I got a strange PHP error. It looked like some issue with our content in the DB. A call was logged, but in the mean time they suggested it was our local theme. I doubted it, but I did try an update of webtest.inf with the web.inf data, but without our theme installed and one of the default edweb themes. Much to my chagrin, it did update. For completeness I took another fresh copy of web.inf, this time with our local theme still in use, and that too worked!

Since then I’ve tried several more times to get the update from 1.5 to 1.6 of the distro to fail, but it has not. I’ve let the web support people know via the unidesk ticket.

Hide Banner RFC

Stratos informed me that the next release of EdWeb will contain the ability to hide the banner image on certain pages. It will be configurable to hide on single pages, or complete (sub-)sites. And will be available to people with the CMS Operative role. This sounds ideal, and an improvement over my simple solution. This should mean our RFC for this can be shelved. Hopefully this change will be on central by the end of the year, and in the distro early next year.

 Change the way we apply our local theme

While testing the upgrade from 1.5 to 1.6, I tripped over the problem that you can’t edit and save the homepage content type, without picking an explicit colour theme. Unfortunately this then overrides our site wide local search and hidden banner theme. So the banner and Ed.ac.uk wide search re-appears. I’ve not found a way for our theme to trump the homepage selected theme, so I’ll probably have to look at not using a theme to override things, but just patch the EdWeb distro directly. A simple hack of replacing the shipped page.tpl.php, does indeed replace the the template, but things like:

 if( !theme_get_setting('uoe_localsearch_hidebanner')) {

Don’t read the local theme setting, so presumably they’ll all have to be patched into the shipped theme. More experimenting is required.

Neil


EdWeb update to 1.6

November 20, 2015

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.

Neil


web.inf mirror

November 6, 2015

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.


A little WordPress hacking

October 23, 2015

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.

https://jetpack.me/tag/multisite/

http://jetpack.me/support/multisite-protect/

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.


Footer funnies

October 13, 2015

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.

Neil


EdWeb CAB submissions

October 9, 2015

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:

https://www.wiki.ed.ac.uk/display/edweb/Normal+RFCs

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.

Neil


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