Digital.Grinnell’s Islandora lifespan will most likely come to an end this year, or at least in the early part 2024. So, I’m adopting a new, lean and mean process for updating it from this point forward. Basically the process will involve backing up the code that’s already in place, then using drush up to upgrade the Drupal modules and core if necessary.
That process on January 19, 2023, went something like this…
In case of catastrophic failure I first elected to open my VPN then a window into VMware® vSphere. Once inside I took a “snapshot” of the DGDocker1 server to preserve as an emergency backup.
Backup DG’s html Directory
Next, to safeguard the Drupal code at a module/file level I made a backup copy of the Apache container’s /var/www/html directory and subdirs like so…
Next, the all-important drush up command, complete with unabridged output, from inside the Apache container…
root@df92a99d657a:/var/www/html# cd /var/www/html/sites/default/
root@df92a99d657a:/var/www/html/sites/default# drush up
Update information last refreshed: Thu, 2023-01-19 11:15
Name Installed Version Proposed version Message
Drupal 7.87 7.94 SECURITY UPDATE available
Views Bulk Operations (views_bulk_operations) 7.x-3.6 7.x-3.7 Update available
Colorbox (colorbox) 7.x-2.15 7.x-2.17 SECURITY UPDATE available
Date (date) 7.x-2.12 7.x-2.14 Update available
Field Group (field_group) 7.x-1.6 7.x-1.8 Update available
Link (link) 7.x-1.9 7.x-1.11 SECURITY UPDATE available
SMTP Authentication Support (smtp) 7.x-1.7 7.x-1.9 Update available
Views (views) 7.x-3.25 7.x-3.28 Update available
NOTE: A security update for the Drupal core is available.
Drupal core will be updated after all of the non-core projects are updated.
Security and code updates will be made to the following projects: Views Bulk Operations (VBO) [views_bulk_operations-7.x-3.7], Colorbox [colorbox-7.x-2.17], Date [date-7.x-2.14], Field Group [field_group-7.x-1.8], Link [link-7.x-1.11], SMTP Authentication Support [smtp-7.x-1.9], Views (for Drupal 7) [views-7.x-3.28]
Note: A backup of your project will be stored to backups directory if it is not managed by a supported version control system.
Note: If you have made any modifications to any file that belongs to one of these projects, you will have to migrate those modifications after updating.
Do you really want to continue with the update process? (y/n): y
Project views_bulk_operations was updated successfully. Installed version is now 7.x-3.7.
Backups were saved into the directory /root/drush-backups/digital_grinnell/20230119174513/modules/views_bulk_operations. [ok]
Project colorbox was updated successfully. Installed version is now 7.x-2.17.
Backups were saved into the directory /root/drush-backups/digital_grinnell/20230119174513/modules/colorbox. [ok]
Project date was updated successfully. Installed version is now 7.x-2.14.
Backups were saved into the directory /root/drush-backups/digital_grinnell/20230119174513/modules/date. [ok]
Project field_group was updated successfully. Installed version is now 7.x-1.8.
Backups were saved into the directory /root/drush-backups/digital_grinnell/20230119174513/modules/field_group. [ok]
Project link was updated successfully. Installed version is now 7.x-1.11.
Backups were saved into the directory /root/drush-backups/digital_grinnell/20230119174513/modules/link. [ok]
Project smtp was updated successfully. Installed version is now 7.x-1.9.
Backups were saved into the directory /root/drush-backups/digital_grinnell/20230119174513/modules/smtp. [ok]
Project views was updated successfully. Installed version is now 7.x-3.28.
Backups were saved into the directory /root/drush-backups/digital_grinnell/20230119174513/modules/views. [ok]
Code updates will be made to drupal core.
WARNING: Updating core will discard any modifications made to Drupal core files, most noteworthy among these are .htaccess and robots.txt. If you have made any modifications to these files, please back them up before updating so that you can re-create your modifications in the updated version of the file.
Note: Updating core can potentially break your site. It is NOT recommended to update production sites without prior testing.
Do you really want to continue? (y/n): y
Project drupal was updated successfully. Installed version is now 7.94.
Backups were saved into the directory /root/drush-backups/digital_grinnell/20230119174513/drupal. [ok]
System 7085 Remove FLoC-blocking variable.
Link 7100 Rebuild the menu cache to make the settings page use the correct permission.
Smtp 7104 Add "smtp_verify_peer", "smtp_verify_peer_name", "smtp_allow_self_signed" variables based on current running PHP version for most compatibility.
Do you wish to run all pending updates? (y/n): y
Performed update: system_update_7085 [ok]
Performed update: link_update_7100 [ok]
Performed update: smtp_update_7104 [ok]
'all' cache was cleared. [success]
Finished performing updates. [ok]
Comparing New Files to Old
The process of updating Drupal core always introduces changes in a couple of files, namely /var/www/html/.htaccess and /var/www/html/robots.txt. It’s prudent for check for differences and take steps to preserve critical portions of these files. In this instance that looked like this…
root@df92a99d657a:/var/www/html/sites/default# cd ../../
root@df92a99d657a:/var/www/html# diff .htaccess /mnt/storage/html-backup/.htaccess
< <FilesMatch "\.(engine|inc|info|install|make|module|profile|test|po|sh|.*sql|theme|tpl(\.php)?|xtmpl)(~|\.sw[op]|\.bak|\.orig|\.save)?$|^(\.(?!well-known).*|Entries.*|Repository|Root|Tag|Template|composer\.(json|lock)|web\.config)$|^#.*#$|\.php(~|\.sw[op]|\.bak|\.orig|\.save)$">
> <FilesMatch "\.(engine|inc|info|install|make|module|profile|test|po|sh|.*sql|theme|tpl(\.php)?|xtmpl)(~|\.sw[op]|\.bak|\.orig|\.save)?$|^(\.(?!well-known).*|Entries.*|Repository|Root|Tag|Template|composer\.(json|lock)|web\.config)$|^#.*#$|\.php(~|\.sw[op]|\.bak|\.orig\.save)$">
> ## The following rule lifted from https://www.drupal.org/node/38960
> ## Implemented in April 2021 in order to redirect old object addresses of the form
> ## drupal/fedora/repository/grinnell:182, to a proper equivalent form like
> ## islandora/object/grinnell:182
> # custom redirects
> RewriteRule ^drupal/fedora/repository/(.+)$ https://digital.grinnell.edu/islandora/object/$1 [R=301,L]
> # end custom redirects
> SetEnvIf X-Forwarded-Proto https HTTPS=on
Finding no real difference in the 6c6 block above, I elected to do this with .htaccess…
Checking on https://digital.grinnell.edu showed me that the site was “working”, but the theme was not properly in play. I’ve seen this before and research showed that it was due to Drupal caching of .htaccess settings. Time to flush the cache, so I did that using the link provided on the Digital.Grinnell home page when one is logged in with proper admin permissions.
The flush of the cache worked to clean up the theme, so I did a little search and facet testing to demonstrate that these operations were working, and with that I’ll declare this update to be DONE!
This probably isn’t the last time for an Islandora update, but for now… that’s a wrap.