DrupalMaintenance

This page has information on my Drupal maintenance activities, i.e. documenting my upgrades from one version of Drupal to the next, and troubleshooting hints for real issues that I had with Drupal in the past.

Module upgrade

Upgrading a module is much simpler than upgrading an entire site. This node on drupal.org has the most up-to-date information that I could find at the time of writing. The procedure is basically this:

Download the tar ball of the module's new version
Put the site into maintenance mode so that external users do not execute module code while the module is in the middle of being upgraded
Do not uninstall the module
Remove the old module folder in sites/all/modules (possibly making a backup first)
Unpack the tar ball and place the result in sites/all/modules
Run update.php
If there are no errors, put the site back online

Site upgrade strategy

A rough and general upgrade manual can be found in Drupal's tar ball in the file UPGRADE.txt. I have my own preferred upgrade procedure that closely follows the basic steps outlined by UPGRADE.txt, but has the following differences:

I don't merge the new Drupal code base into the old one. Instead I unpack the new Drupal code base into its own directory (/var/www/drupal-new) where I re-create all changes made to the old code base (/var/www/drupal).
I don't upgrade the original database. Instead I create a duplicate database and upgrade that one.

There are two advantages to this approach:

The old setup remains completely untouched at all times. This gives me the freedom to abort the upgrade at any time, and to effortlessly go back to the old setup.
The new code base is as clean as it can possibly get, i.e. no worrying that I keep dragging old cruft with me from one Drupal upgrade to the next.

Site upgrade procedure

Preparation

Create a new archive directory that will hold all tar balls I am going to download:

/var/archive/drupal/drupal-x.y

Prepare an upgrade matrix for modules and themes, then download the tar ball for the new Drupal version, and for all new versions of modules and themes into the archive directory. Further down on this page there are example matrices from old upgrades.

Extract tar balls

Create the directory for the new Drupal version by extracting the Drupal tar ball:

cd /var/www
tar xfvzo /var/archive/drupal-7.14/drupal-7.14.tar.gz

Next, extract tar balls of modules and themes into sites/all/modules and sites/all/themes.

Repeat customizations

Repeat customizations of modules, themes and the .htaccess files. An indicator for a customization is that an .org file exists.

Note: This section exists mostly for completeness sake because I usually don't do any customizations. With older versions of Drupal I usually had a few additional rewrite rules in .htaccess, but today this is no longer necessary.

Prepare sites for the upgrade

Disable all system cron jobs (there should be a script in /etc/cron.hourly)
Use the web interface to put all sites into off-line mode to prevent any further modifications by users

Create/update symlinks

Subsequent steps in the upgrade procedure rely on the fact that

The old code base is available under /var/www/drupal-old
The new code base is available under /var/www/drupal-new

The following commands create the appropriate symlinks:

cd /var/www
rm drupal-old drupal-new
ln -s drupal-6.26 drupal-old
ln -s drupal-7.14 drupal-new

Note: The "production" symlink /var/www/drupal still points to the old code base. This is necessary so that the outside world still sees the original site (which is now in maintenance mode).

Duplicate databases and generate sites

I have written a shell script that helps me with duplicating my sites. The script interactively asks questions and even performs database connection tests before it starts its work. The script is supposed to be in

/usr/local/htb/sbin/htb-drupal-copysites.sh

If it isn't, get it from this direct link into htb.git. Read the comments at the top of the script file to get an idea what it does.

Notes:

When doing an upgrade to a new major version of Drupal (e.g. 6.x to 7.x), double-check that the settings.php file created by htb-drupal-copysites.sh contains a valid database connection. If the new Drupal version's default settings.php has a significantly different format, the script may have silently failed in setting up a valid database connection.
It should be possible to simply re-run the script if something went wrong in the first attempt. The script should detect the leftovers from the first attempt and ask interactively whether it is allowed to proceed to clean up those leftovers.

Access to old-site and new-site subdomains

For the remainder of the upgrade process, we are going to access the duplicated sites under two pre-defined subdomain. Every one of my sites has an old-site and a new-site subdomain, e.g.

old-site.herzbube.ch
new-site.herzbube.ch
old-site.grunzwanzling.ch
new-site.grunzwanzling.ch
etc.

The subdomains are set up as CNAMEs in the domain's DNS configuration, and the Apache web server configuration has separate vhosts defined for the subdomains which point to

/var/www/drupal-old
/var/www/drupal-new

Because we have created symlinks fore these two locations in a previous step, we can now access the duplicated database of each site via both the old and the new code base.

Summary:

The old-site subdomain uses the old Drupal code base in /var/www/drupal-old
The old-site subdomain points to the new database
The new-site subdomain uses the new Drupal code base in /var/www/drupal-new
The new-site subdomain points to the new database
The new database begins its life as a duplicate of the original database, but will gradually evolve away during the upgrade process (e.g. because of database scheme upgrades)
The original database remains unchanged at all times during the upgrade process

Disable/uninstall modules (using old code base)

Visit each site's old-site subdomain (as explained above) and log in as administrator. Login is possible via the direct login URL (e.g. https://old-site.herzbube.ch/user/login), even though the site is in maintenance mode.

While logged in as administrator, perform the following modifications:

If the site uses a custom or contributed theme, switch to a core theme (e.g. Garland)
Disable all contributed (= non-core) themes that will no longer be used after the upgrade. Note: Unlike modules, themes cannot be installed, therefore they also cannot be uninstalled. Disabling them is sufficient.
Disable all contributed (= non-core) modules - regardless of whether you want to keep them or throw them out. Note: Modules that contribute a field type cannot be disabled.
Uninstall all contributed modules that will no longer be used after the upgrade
- On the page where all modules are listed, there is a tab "Uninstall" at the top. Switch to this tab.
- A module will appear on this tab only if it has an uninstall routine. Run the uninstall routine.
- Always perform a manual check for leftovers! A module without an uninstall routine may leave tables or fields in the database. A module with a badly implemented uninstall routine may do the same. First check the database for obviously named tables, which can be easily dropped. But the only way to know for sure is to examine the module installation file to see what was added in the first place. An installation file is a file that ends with .install.
- Also see the official module uninstall docs
If the site uses caching, clear the cache and disable caching (Administration > Configuration > Performance)
Logout

Perform the upgrade (using new code base)

Visit each site's new-site subdomain (as explained above) and log in as administrator. Login is possible via the direct login URL (e.g. https://new-site.herzbube.ch/user/login) even though the site is in maintenance mode.

While logged in as administrator, perform the following modifications:

Run the update script (e.g. https://new-site.herzbube.ch/update.php). Notes:
- This affects only the database tables of Drupal core and of those modules that do not defer the upgrade because they are disabled.
- For those modules that do defer (e.g. CCK in older versions of Drupal) you may see some "Failed" messages in the update log, but if you read the messages closely you will see that the "failure" is due to the module not being enabled
- Carefully read the results page of update.php because it often contains useful hints about things that need to be done differently with new versions of modules
Go to the modules page and enable contributed modules
Re-run the update script. The update this time affects the database tables of all contributed modules that have deferred the upgrade while they were disabled
Go to the status report page (Administer -> Reports -> Status report) and fix any remaining errors; this may include manually runing cron.php
Check that the site timezone is set up correctly (Administer -> Regional and language -> Date and time). The timezone may have an influence on modules (e.g. "Date Timezone"), and in the past one of my sites was suddenly configured with "Africa/Algiers" instead of "Europe/Zurich"
Return the site to its original theme
If the site uses caching, re-enable caching
Return the site to online mode
Log out, then perform site-specific tests (see the following chapters) while still using the new-site subdomain

Activate the upgraded sites

After all sites have been upgraded:

Change symlink /var/www/drupal so that it points to the new Drupal code base. For instance

rm /var/www/drupal
ln -s /var/www/drupal-7.14 /var/www/drupal

If the site uses caching, clear the cache one final time (Administer -> Site configuration -> Performance). I am not sure if this is really necessary, but in the past I once experienced some really weird problems that went away after I cleared the cache. This may be due to the testing activities performed under the new-site subdomain.
Update Drupal-specific entries in /var/www/herzbube.ch/robots.txt with entries from /var/www/drupal/robots.txt. Commit the changes in Git!

Cleanup

Remove symlinks /var/www/drupal-old and /var/www/drupal-new
- TODO: I currently keep these symlinks because apachectl configtest prints a warning if these folders do not exit but are still configured as document roots for vhosts
Re-activate Drupal cron jobs!
Remove configuration files taken over from the old Drupal installation by htb-drupal-copysites.sh

/var/www/drupal/sites/*/settings.php.old
/var/www/drupal/sites/*/settings.php.org

Remove any other temporary files (manually created backup files, etc.)
Replace the site default by a symlink that points to the site herzbube.ch

Site-specific tests after an upgrade

This chapter contains one check list per site that can be used to test, after an upgrade, whether the essentials things still work.

Note: Unless otherwise specified, all tests should be performed as anonymous user. This requires that the site has been set to online mode.

herzbube.ch

https://new-site.herzbube.ch/ (front page) displays news items
Site appears in English
Site header displays an icon and the site name
Site footer displays a note that provides a link to my PGP key
News items on front page display taxonomy terms
Sidebar on the left displays 3 blocks:
- A block titled "Links" containing a number of links pointing outside the Drupal site; clicking each link works correctly
- A block titled "Most recent book reviews" containing a table with up to 5 book reviews. The table has 3 columns: Book title / Author, Posted date, Rating. The book title is clickable and displays the corresponding full book review node.
- A block titled "Get CAcert root certificates"
https://new-site.herzbube.ch/node/40 ("CAcert Assurer Challenge - Passed!", 09.09.2008)
- Must redirect to https://new-site.herzbube.ch/blog/2008/09/cacert-assurer-challenge-passed
- Must provide a .pdf attachment
- Must display a clickable URL (achieved using the <a> HTML element)
- Must display comment posting section that includes a CAPTCHA challenge
- Submitting a comment without solving the CAPTCHA will not work.
https://new-site.herzbube.ch/node/44 ("Structured Procrastination", 08.12.2008)
- Must display a clickable URL (automatically marked up as such)
There must be a page with this url: https://new-site.herzbube.ch/about
There must be a page with this url: https://new-site.herzbube.ch/software
- Various projects in the list display an icon floating on the left (achieved using embedded CSS style attributes)
There must be a page with this URL: https://new-site.herzbube.ch/acexpander
- The page displays a download button (achieved using embedded CSS style attributes)
Log in as normal user (not as the administrator!) using https://new-site.herzbube.ch/user/login
- Login must work (which means that a connection to the LDAP server exists)
- After logging in, the CAcert block in the left sidebar must disappear, and a new block "Recent comments" must appear in the sidebar on the right
https://new-site.herzbube.ch/xxx
- Must result in a HTTP 404 status and a page that displays some sort of error message, such as "The requested page "/xxx" could not be found."
Manual teaser break test
- Go to the front page, then cycle through the pages until you see the story "The Art of Computer Programming" from 15 August 2016. This is an example of a story where the manually specified teaser is longer than the teaser that Drupal would automatically create on its own. In fact, in this example the teaser consists of the full body of the node. The teaser must end with the sentence "It's so fabulous that I consider it to be a real piece of computer programming art!".
- Continue to cycle through the pages until you see the story "The second journey: Attack ships on fire off the shoulder of Orion" from 26 August 2015. This is an example of a story where the manually specified teaser is shorter than the teaser that Drupal would automatically create on its own. The teaser must end with the sentence "Read more after the break.".
- Continue to cycle through the pages until you see the story "A statement on democracy" from 02 December 2012. This is another example of a story where the manually specified teaser is longer than the teaser that Drupal would automatically create on its own, but in this example there is actually more text after the teaser break. The teaser must end with the sentence "For once in this post I am not talking about technical stuff..."

grunzwanzling.ch

https://new-site.grunzwanzling.ch/ (front page) displays picture and german/english "poem"
No site header, site footer, or any means of navigation
Log in as administrator (there is no normal user) using https://new-site.grunzwanzling.ch/user/login

kino.herzbube.ch

Accessing the site results in a certificate warning or error, because certificate is the wildcard certificate for *.herzbube.ch, which does not match the hostname new-site.kino.herzbube.ch
https://new-site.kino.herzbube.ch/ (front page) displays a single front story
Site appears in German
Site header displays a site name but no icon
Site displays no navigation
Log in as administrator (there is no normal user) using https://new-site.kino.herzbube.ch/user/login

Simplified site upgrade

After the painful upgrade to Drupal 8 I have started to perform upgrades more frequently, and more informally. The main difference to my more secure site upgrade strategy is that I am not cloning the database, instead I am upgrading directly into the current database. Although this is more risky, I am sick of performing painful upgrades only every other year. I want upgrades to be painless, and the only way to achieve this that I can see at the moment is by updating frequently and with relatively simple steps. The mitigation against broken updates is my backup plan that is currently executing flawlessly.

First, log in as administrator on all sites.

Next, prepare everything on the command line. Here's a session for the update from 8.6.3 to 8.6.4:

# Obtain new Drupal version
cd /var/www/archive/drupal
mkdir drupal-8.6.4
cd drupal-8.6.4
wget https://ftp.drupal.org/files/projects/drupal-8.6.4.tar.gz

# Extract new Drupal version
cd /var/www
tar xfvzo /var/archive/drupal/drupal-8.6.4/drupal-8.6.4.tar.gz

# Copy modules, sites and themes from the old Drupal version to the new Drupal version
cd /var/www/drupal-8.6.3/modules
cp -Rp captcha ctools externalauth extlink ldap pathauto recaptcha redirect token /var/www/drupal-8.6.4/modules
cd /var/www/drupal-8.6.3/sites/
cp -Rp grunzwanzling.ch herzbube.ch kino.herzbube.ch sites.php /var/www/drupal-8.6.4/sites
cd /var/www/drupal-8.6.3/themes/
cp -Rp adminimal_theme nexus /var/www/drupal-8.6.4/themes

# Port local patches
cd /var/www/drupal-8.6.3/core/modules/filter/src/Plugin/Filter
diff FilterHtml.php.org /var/www/drupal-8.6.4/core/modules/filter/src/Plugin/Filter/FilterHtml.php
>>> If there are no differences
    mv /var/www/drupal-8.6.4/core/modules/filter/src/Plugin/Filter/FilterHtml.php /var/www/drupal-8.6.4/core/modules/filter/src/Plugin/Filter/FilterHtml.php.org
    cp -Rp FilterHtml.php /var/www/drupal-8.6.4/core/modules/filter/src/Plugin/Filter/FilterHtml.php

# Update symlinks
cd /var/www
rm drupal; ln -s drupal-8.6.4 drupal
rm drupal-new; ln -s drupal-8.6.4 drupal-new

Check if the content of the root folder of the new Drupal version is different from the content of the root folder of the old Drupal version. If yes, create/delete appropriate symlinks in site folders (e.g. /var/www/www.herzbube.ch).

Finally, run update.php in the browser:

Upgrade logs

Drupal 7.50 -> 8.5.6

Upgrade matrix

Each row in the following table corresponds to a package as it appears in /var/www/drupal/sites/all/modules:

Software package	Old	New	URL	Remarks
Modules
advanced_help	7.x-1.3	-	drupal.org	The project page states "This module is currently being ported to Drupal 8, but is not usable yet." Since this module is not necessary to run my site I am discontinuing it.
blockanonymouslinks	7.x-1.1	-	drupal.org	No usable D8 update available. I am relying on CAPTCHAs anyway, so I think I don't really need this module anymore.
captcha	7.x-1.3	8.x-1.0-beta1	drupal.org	The project page states "This module has a pre-release version for Drupal 8." This refers to the Beta 1 from February 2017. A newer dev version from August 2018 is also available, but I want to play it safe for the moment, so I am going for the Beta.
ctools	7.x-1.9	8.x-3.0	drupal.org	In D7, this module was only required as a dependency for the Views module. Views is now part of D8 core, but I still need the module because the D8 version of the "pathauto" module now has a dependency on "ctools".
date	7.x-2.9	-	drupal.org	The project page states "This module has been renamed or deprecated by another module in Drupal 8." This refers to the fact that D8 core has now a Date field type - see this issue on drupal.org. Discontinuing this module.
email	7.x-1.3	-	drupal.org	The project page states "The basic email field type is in core now [...], making this contrib module obsolete." Discontinuing this module.
externalauth	-	8.x-1.1	drupal.org	The "LDAP Authentication" and "LDAP Users" modules depend on this module
extlink	7.x-1.18	8.x-1.1	drupal.org
fivestar	7.x-2.2	?	drupal.org
flattr	7.x-1.0-alpha3+7-dev	-	drupal.org	I have abandoned my Flattr account, so I can also discontinue this module.
globalredirect	7.x-1.5	-	drupal.org	The project page states "For Drupal 8 please use the redirect module. This project is deprecated for D8." Discontinuing this module.
ldap	7.x-1.0-beta12+6-dev	8.x-3.0-beta4	drupal.org	Under the "Drupal 8" heading the project page states "The module can be used in production but we recommend intensive tests before you depend on it [...] You need to read the release notes due to still open issues."
link	7.x-1.4	-	drupal.org	The project page states "[...] the link module is now part of the Drupal 8 core installation." Discontinuing this module.
pathauto	7.x-1.3	8.x-1.3	drupal.org
recaptcha	7.x-2.1	8.x-2.3	drupal.org
redirect	-	8.x-1.2	drupal.org	Replacement for the deprecated "globalredirect" module.
token	7.x-1.6	8.x-1.5	drupal.org
views	7.x-3.14	-	drupal.org	The project page states "Views is in Drupal 8 Core!" Discontinuing this module.
votingapi	7.x-2.6	7.x-2.12	drupal.org	The project page states "This module has a pre-release version for Drupal 8." This refers to the Alpha 3 from May 2018. A newer dev version from August 2018 is also available, but I want to play it safe for the moment, so I am going for the Alpha.
Themes
zen	7.x-6.4	-	drupal.org	The project page states "This theme has a pre-release version for Drupal 8." This refers to the Alpha 14 from June 2016. With more than 2 years since the last alpha, a stable release of this theme obviously is not going to happen soon. Discontinuing this theme in the hope that I will find a replacement. A suggestion has been made that the D8 core theme "Classy" is similar to Zen. As it turns out, however, "Classy" is merely a base theme that is not selectable in the D8 administration UI (because it's marked as "hidden" as this useful article explains). The idea is that theme builders construct their own themes based on "Classy", not to use "Classy" directly.

Upgrade procedure

I had to perform 2 upgrades, as described in Drupal's UPGRADE.txt:

Drupal 7.50 >>> Drupal 7.59 (latest 7.x at the time of writing)
Drupal 7.59 >>> Drupal 8.5.6 (latest 8.x at the time of writing)

Drupal 7.50 >>> Drupal 7.59

After studying the release notes of all versions since 7.50, it seemed that no database changes had been made, and code changes did not sound to be so profound as to affect current modules' functionality. I therefore decided to perform a simplified upgrade only:
- No module upgrades
- No disabling modules in old-site / enabling modules in new-site
As it turned out when running update.php there were two database changes after all, but they appeared minor, so I went ahead and performed the simplified upgrade as planned. It worked smoothly. Exceptions:
- grunzwanzling.ch: The update script complained "The following module is missing from the file system: default". Indeed, the system database table contained an entry for a module "default" (query = "select * from system where name = 'default' and type = 'module'"). This post suggests to delete the row in question, but I am not bothering because I expect that the upgrade to Drupal 8 will clear the problem anyway.
- herzbube.ch: After the update the update script shows 3x the same PHP warning "Methods with the same name as their class will not be constructors in a future version of PHP". The offenders are ctools_context, ctools_context_required and ctools_context_optional, all in ctools.module. I am not concerned because at the moment the code is still functional (it's a deprecation warning) and the upgrade to Drupal 8 will clear the problem because there I will get new module versions.

Drupal 7.59 >>> Drupal 8.5.6

Unlike Drupal 6 and 7, the upgrade in Drupal 8 from a previous major version does not perform changes on the original database. Instead, a clean Drupal 8 site first needs to be installed, then the site configuration and site content from the old installation is migrated (= imported) to the new Drupal 8 site. This procedure is outlined in this drupal.org article.
This drupal.org article has a list of known issues when upgrading from Drupal 6 or 7 to Drupal 8. Issues relevant for me are:
- Migration system will create a D8 comment type comment_node_article, but the D8 install will already have create the default D8 comment type comment. Since I don't want to use two comment types on the same content type (i.e. "article"), I want to remove the unused default comment type. Due to a bug in D8, this must be done before the migration process.
- The text format "PHP code" will be migrated, but after the migration will use the filter filter_null. This is because D8 has no filter that corresponds to the D7 filter "PHP evaluator", the reason being that this is "bad practice" and there D8 does not support it. This is no problem for me because none of my content makes use of the "PHP code" format.
- Views are not (yet) migrated, they need to be manually recreated. There is a View Migration module, but I intend to perform the migration manually since I should have documented my views.
Basic installation of a D8 site
- Extract D8 tar ball
- Set up sites in the file system. There are differences from D7 which I am not describing here because that would serve little purpose. To see the differences, compare versions of the main Drupal wiki page from the page history.
- Extract the tar balls of all D8 modules that are ready to use, according to the module upgrade matrix in the previous section. These are: captcha, ctools, extlink, pathauto, recaptcha and token. I'll deal with LDAP and fivestar/votingapi later.
- Need to increase the PHP memory limit to 64 MB in the Apache configuration
- I am using the opportunity to switch from MariaDB to PostgreSQL. INSTALL.pgsql.txt has information how to create the database user and the database. As with MySQL, the DB schema is later automatically loaded by install.php.
- Perform the setup by running install.php from the "new-site" subdomain. Example: https://new-site.herzbube.ch/install.php.
  - Use the installation profile "Minimal", as described in this drupal.org article in section "Do not configure the Drupal 8 site". Reason: The "Standard" profile, which is the default, already adds configuration stuff that might conflict with the data from the migration.
After setup, we still need to enable some modules before we can start the migration process. Navigate to "Administration > Extend" to enable modules.
- Enable the Drupal Core modules used for the migration process:
  - Migrate
  - Migrate Drupal
  - Migrate Drupal UI (necessary because we want to perform the migration in the browser)
- Also enable the following Drupal Core modules. These are required because these modules contain migration plugins that will migrate data from the D7 site (in some cases from D7 contrib modules that have been replaced by D8 core modules)
  - Color (migrates data from the D7 color module)
  - Comment (migrates comments)
  - Datetime (migrates data from the D7 date module)
  - Link (migrates data from the D7 link module)
  - Options (migrates options field type data)
  - Path (required by pathauto, migrates paths data)
  - Search (migrates data from the D7 search module)
  - Taxonmoy (migrates taxonomy data)
- Enable some more Drupal Core modules which I will be using later on but which should not have an impact on migration
  - Field UI
  - Help
  - Statistics
  - Views
  - Views UI
- It is unclear which module is supposed to migrate the data from the D7 email module.
- Views will not be migrated, they need to be manually re-created.
- Enable all contrib modules. This is to make sure that if any data migration is required, the contrib modules get the possibility to do their job.
  - Chaos tools
  - Pathauto
  - Token
  - CAPTCHA
  - Image CAPTCHA
  - reCAPTCHA
  - External Links
We are now ready for the actual migration. The requirement that the new Drupal 8 site has access to the old Drupal 7 site's database and filesystem content is met because we perform everything on the same host.
For details about the migration process of a specific site, check out the corresponding site-specific section below.
After the migration is complete, LDAP access can be re-added. For this the LDAP modules must be installed and then configured, in almost the same way as they were configured in D7 (minor differences not mentioned here). Despite the beta-level status of the modules, this works flawlessly! After configuring the modules, nothing more needs to be done because the content creation user (patrick) has already been created by the migration process.
After all sites have been migrated, perform these file system changes
- Go to the site base folder (e.g. /var/www/www.herzbube.ch)
- Remove old D7 symlinks:
  for symlink in authorize.php cron.php .htaccess includes index.php install.php misc modules profiles scripts sites themes update.php web.config xmlrpc.php; do echo "Removing symlink $symlink ..."; rm $symlink; done
- Add new D8 symlinks:
  for symlink in autoload.php core .htaccess index.php modules profiles sites themes update.php vendor web.config; do echo "Adding symlink $symlink ..."; ln -s /var/www/drupal/$symlink .; done
- When all sites have been treated, thus, change the main symlink:
  cd /var/www; rm drupal; ln -s drupal-8.6.1 drupal
- Update the robots.txt for all sites by removing the old D7 entries and replacing them with the new D8 entries (simply copy them over from /var/www/drupal-8.6.1/robots.txt). Note: Some sites may not have their own robots.txt but instead symlink to Drupal's robots.txt. For those sites, obviously nothing has to be done.

Problems and solutions for herzbube.ch

Steps for performing the migration:

Visit this URL to initiate the migration: https://new-site.herzbube.ch/upgrade
Enter the following details
- Drupal version of the source site = Drupal 7
- Source database
  - Database type = MySQL
  - Database host = localhost
  - Database name = drupal759_herzbube
  - Database user = drupal
  - Database password = secret
- Source files
  - Public files directory = /var/www/drupal-old/sites/herzbube.ch/files
  - Private files directory = /var/www/drupal-old/sites/herzbube.ch/files
The upgrade wizard informs me that data for the following modules will not be migrated, because "[...]There are no modules installed on your new site to replace these modules". This is OK in all cases, I have added my comments behind the module name.

advanced_help OK. Has no data. I am discontinuing the module because its D8 version is not yet available.
blockanonymouslinks OK. Has no data. I am discontinuing the module because it has no D8 version.
book OK. I don't have any books on my old site.
captcha OK. Has no data. The enabled D8 CAPTCHA module is not recognized as the successor of the D7 module.
extlink OK. Has no data. The enabled D8 "External Links" module is not recognized as the successor of the D7 module.
fivestar OK. Will manually add data later as soon as I have found a solution for the missing D8 module.
flattr OK. I am discontinuing the module because I have abandoned Flattr.
globalredirect OK. Has no data. I am discontinuing the module because in D8 it is supposed to be in D8 core.
ldap_authentication OK. Will manually add configuration later.
ldap_servers OK. Will manually add configuration later.
locale OK. Has no data.
pathauto OK. Has no data. The enabled D8 Pathauto module is not recognized as the successor of the D7 module.
recaptcha OK. Has no data. The enabled D8 reCAPTCHA module is not recognized as the successor of the D7 module.
token OK. Has no data (hopefully). The enabled D8 Token module is not recognized as the successor of the D7 module.
views OK. Will manually add view configuration later.
votingapi OK. Will manually add data later as soon as I have found a solution for the missing D8 module.

Running the upgrade has this result:

Completed 69 upgrade tasks successfully
1 upgrade failed

Visiting the log shows a large number of error entries.

Missing filter plugin: filter_null.
- This is related to the failed migration of filter "php_code". See next issue.
Source ID 2: Filter php_code could not be mapped to an existing filter plugin; defaulting to filter_null.
- This is listed as a known issue in this drupal.org article.
- The D7 format "PHP code" makes use of the D7 filter "PHP evaluator". This D7 filter is not supported in D8 because "it's very bad practice".
- This is no problem because I didn't use this filter/format anywhere in my D7 site.
- Incidentally, when you edit the migrated "PHP code" format, D8 displays this message: "The filter_null filter is missing, and will be removed once this format is saved." Also, the "PHP code" format has no filters enabled.
- The solution for the issue obviously would be to to delete the migrated "PHP code" format. ~~Unbelievably~~ Unfortunately Drupal does not allow to delete a format, even if it is not used anywhere. All one can do is disable the format, which will cause it to disappear from the UI while still remaining in the database. Here's a discussion revolving around this.
Source ID minimum_word_size: No static mapping found for 'array( NULL, )' and no default value provided for destination 'default_page'.
- Searching the net hints that this has something to do with the "search" module: The keyword "minimum_word_size" appears in that module's context
- This command confirms the suspicion: grep -r "minimum_word_size" /var/www/drupal-8.6.1
- I don't think this is a problem because the "search" module certainly has not any important data to migrate.
Source ID allow_insecure_uploads: No static mapping found for 'NULL' and no default value provided for destination 'allow_insecure_uploads'.
- Looking over the D7 source code, allow_insecure_uploads is a so-called "variable" (in D7 terms). In D7, variables are stored in the database table variable. All variables share the same namespace.
- In D8 there are no more variables. Instead, D8 introduces a new config subsystem. The config subsystem stores its values in the database table config. A config value is identified by its name. From looking at the data, it appears that a config value is a serialized form of a larger PHP data structure, such as an array. Because of this, a config value can contain several other names/values. For instance, the config value for system.file contains a value for allow_insecure_uploads, but also other values such as default_scheme or default_config_hash.
- My educated guess is that the error message is generated because the migration code tries to obtain a value for allow_insecure_uploads from the D7 site database, but there is none because the variable is not defined in the DB table, i.e. there is no row. This explains the mention of NULL.
- In the destination D8 database, the config subsystem contains a value for allow_insecure_uploads, within the config value named system.file. This is how the raw data looks like: "s:22:"allow_insecure_uploads";b:0". I interpret this as "a string value of length 22", followed by the actual value (which is indeed 22 characters long), then "a binary value", followed by the actual value (0 in this case, or false).
- My conclusion is that the error message can be ignored because the migration produces a result where allow_insecure_uploads has the good value "false".
Source ID mail_system: No static mapping found for 'NULL' and no default value provided for destination 'interface/default'.
- Armed with the knowledge obtained from analysing the previous error message, it becomes much easier to interpret this error message
- Again, a D7 variable named "mail_system" is not defined. Checking the D8 config subsystem, the config value system.mail contains a suitable default value "php_mail"
- Conclusion: Error message can be ignored.
Operation on Blocks failed. The "block_content" entity type does not exist.
- No idea what this is about. But blocks are a pretty large structural thing in Drupal, so I will certainly find out whether something is missing when I later compare the migrated site with the old site. If necessary I will manually create the missing blocks in the migrated site.
- Conclusion: Error message can be ignored for the moment.
Attempt to create a field storage field_rating with no type. Source ID field_rating,node: Attempt to create a field storage field_rating with no type.
- This appears to be about the field_rating field used in the "Book review" content type on the D7 site. The field has the type "Fivestar Rating". Since this module currently does not exist in the D8 site, it is only natural that the migration process should have a problem. I will later address the problem when I investigate how to recreate book reviews on the D8 site.
- Conclusion: Error message can be ignored for the moment.
Attempt to create a field field_rating that does not exist on entity type node. Source ID node,bookreview,field_rating: Attempt to create a field field_rating that does not exist on entity type node.
- Same as the previous error message.
- Conclusion: Error message can be ignored for the moment.
Attempt to create a field storage field_flattr with no type. Source ID field_flattr,node: Attempt to create a field storage field_flattr with no type.
- This appears to be about the field_flattr field used in all sorts of content types on the D7 site. The field has the type "Flattr". Since this module no longer exists in the D8 site, it is only natural that the migration process should have a problem. I will not address the problem because I have abandoned Flattr.
- Conclusion: Error message can be ignored.
Attempt to create a field field_flattr that does not exist on entity type node. Source ID node,bookreview,field_flattr: Attempt to create a field field_flattr that does not exist on entity type node. Source ID node,page,field_flattr: Attempt to create a field field_flattr that does not exist on entity type node. Source ID node,story,field_flattr: Attempt to create a field field_flattr that does not exist on entity type node.
- Same as the previous error message.
- Conclusion: Error message can be ignored.
8 messages about missing files. Example: Source ID 14: File '/var/www/drupal-old/sites/herzbube.ch/files//sites/herzbube.ch/files/readable-label.jpg' does not exist.
- This is about files that are attached to story nodes or referenced elsewhere on the D7 site
- Obviously the migration process is unable to find these files because it looks for them using the wrong path. The reason for this is unknown.
- I will address the problem later by manually adding the files to the D8 site
- Conclusion: Error message can be ignored for the moment.
Attempt to create a field storage of unknown type image. Source ID : Attempt to create a field storage of unknown type image.
- This appears to be about the picture that can be attached to a user node.
- I'm not interested in this because I never used a picture for my users.
- Conclusion: Error message can be ignored.
Attempt to create a field user_picture that does not exist on entity type user. Source ID : Attempt to create a field user_picture that does not exist on entity type user.
- Same as the previous error message.
- Conclusion: Error message can be ignored.
The "default" plugin does not exist. Source ID node,bookreview,token,field_links: The "default" plugin does not exist.
- The message is repeated for many other Source IDs
- I can only guess (rather un-educated) that this is related to the "link" module which provides fields of type "Link". But I have no idea what the actual problem is here.
- The only way how to address this is to later verify that links have been migrated correctly.
- Conclusion: Error message can be ignored for the moment.
The "select" plugin does not exist. Source ID story,taxonomy_vocabulary_4: The "select" plugin does not exist.
- The message is repeated for many other Source IDs
- I can only guess (rather un-educated) that this is related to the "Software Projects" taxonomy vocabulary. But I have no idea what the actual problem is here.
- The only way how to address this is to later verify that terms from the vocabulary have been migrated correctly.
- Conclusion: Error message can be ignored for the moment.

Theme

Drupal 8 Core comes with no good-looking theme. Especially annoying is that the core themes don't even get dropdown menus right :-(
Garland, a former Drupal 7 Core theme, has not been ported to D8 (or rather: porting has been stuck in alpha state since more than two years)
The Adminimal theme is a serviceable administration theme.
The Nexus theme looks pretty nice, but its default configuration definitely needs a bit of tweaking.
- Use the logo supplied by the theme = No
- Path to custom logo = sites/herzbube.ch/files/site-logo.png
- Use the favicon supplied by the theme = No
- Path to custom icon = <none>
- Front Page Slideshow - Show slideshow = No
- I ignored these errors when I installed the theme:

User warning: The configuration name "block.block.nexus_tabs" does not match the ID "nexus_local_tasks" in Drupal\Core\Config\ConfigInstaller->createConfiguration() (line 334 of core/lib/Drupal/Core/Config/ConfigInstaller.php).
User warning: The configuration name "block.block.nexus_primary_admin_actions" does not match the ID "nexus_local_actions" in Drupal\Core\Config\ConfigInstaller->createConfiguration() (line 334 of core/lib/Drupal/Core/Config/ConfigInstaller.php).
User warning: The configuration name "block.block.nexus_powered_by_drupal" does not match the ID "nexus_powered" in Drupal\Core\Config\ConfigInstaller->createConfiguration() (line 334 of core/lib/Drupal/Core/Config/ConfigInstaller.php).
User warning: The configuration name "block.block.nexus_main_page_content" does not match the ID "nexus_content" in Drupal\Core\Config\ConfigInstaller->createConfiguration() (line 334 of core/lib/Drupal/Core/Config/ConfigInstaller.php).
User warning: The configuration name "block.block.nexus_footer_menu" does not match the ID "nexus_footer" in Drupal\Core\Config\ConfigInstaller->createConfiguration() (line 334 of core/lib/Drupal/Core/Config/ConfigInstaller.php).

More D8 themes can be found here: https://www.drupal.org/docs/8/themes

Verified that migration of the following data did work

URLs (link module). I checked this by looking at book review nodes. I assume that if other nodes also contain links they will have been migrated, too.

Manual fixes

ISFDB links in book reviews don't work correctly. Although the URL is correct in the data, the clickable link omits the query string (the part after the "?")
Custom links in the main menu were not migrated. Manual migration.
The custom menu "Links (HTTPS only)" has been created, but no links were added to it. Manual migration. In addition I also had to enable the "Menu UI" module.
Footer block was not migrated. Manual migration. In addition I also had to enable the "Custom Block" module and create the "Basic block" type which didn't exist yet.
Book review content type was not fully migrated
- Missing fields: title (type Node module element), field_rating (type Fivestar Rating), path (type Path module form elements)
Pathauto patterns were not migrated. Manual migration. Tokens with "_raw" suffix no longer seem to exist.
View "Book reviews" was not migrated. Manual migration.
Custom date/time formats were not migrated. Manual migration.
Default CAPTCHA module was not migrated. Manual configuration.
reCAPTCHA settings were not migrated. Manual migration.
User registration was not restricted to admins only. Manual configuration.
None of the files in the "files" area were migrated. Manual migration. In addition, manually re-attach image files to a few stories (story 1, story 2).
Enabling the CAPTCHA modules did not add CAPTCHA points for protecting comment entry. Manually added the following CAPTCHA points. Alas you have to know the "form_id" values, there is no UI for selecting the correct forms. Probably the simplest way to find out a form's ID is to look at a page's source code and find a hidden input element named "form_id". The input element's value attribute has the desired form ID.
- comment_comment_node_bookreview_form
- comment_comment_node_book_form
- comment_comment_node_page_form
- comment_comment_node_story_form

Problems and solutions for grunzwanzling.ch

When I attempted the migration for the first time, it miserably failed to migrate the single node of the original site. The final and fatal message in the upgrade log was this:

Source ID 1: SQLSTATE[23502]: Not null violation: 7 ERROR: null value in column "title" violates not-null constraint DETAIL: Failing row contains (1, 1, page, und, 1, null, 1, 1178402262, 1258167891, 1, 0, 1, 1).: INSERT INTO node_field_data (nid, vid, type, langcode, status, title, uid, created, changed, promote, sticky, default_langcode, revision_translation_affected) VALUES [...]

So the node could not be migrated because the migration process attempted to insert a NULL value where none was allowed - duh! Well, I thought, I'll just create the node manually, but this plan did not work because after the migration I was not able to create any pages on the new site - apparently the migration process by failing to migrate the single node had somehow managed to corrupt the entire site. Wow, Drupal, great job! OK, I have to admit that the original problem of a missing title was created by myself, because I had manipulated the database to remove the title. But still - failing to migrate a node should not, in my opinion, lead to the entire site becoming unusable.

Anyway, I made a second migration attempt. This time I temporarily added a dummy title to the node on the original site. I also enabled the "Comment" module which I had disabled in the first attempt because there are no comments on the site - just to be on the safe side. This time the migration worked better. The following is the log of this second attempt.

Steps for performing the migration:

Visit this URL to initiate the migration: https://new-site.grunzwanzling.ch/upgrade
Enter the following details
- Drupal version of the source site = Drupal 7
- Source database
  - Database type = MySQL
  - Database host = localhost
  - Database name = drupal759_grunzwanzling
  - Database user = drupal
  - Database password = secret
- Source files
  - Public files directory = /var/www/drupal-old/sites/grunzwanzling.ch/files
  - Private files directory = /var/www/drupal-old/sites/grunzwanzling.ch/files
The upgrade wizard informs me that data for the following modules will not be migrated, because "[...]There are no modules installed on your new site to replace these modules". This is OK in all cases, I have added my comments behind the module name.

list                  OK. The original site does not use any widgets from this module.
options               OK. The original site does not use any widgets from this module.
taxonomy              OK. The original site does not have any vocabularies.

Running the upgrade has this result:

Completed 51 upgrade tasks successfully
1 upgrade failed

Visiting the log shows a large number of error entries.

Source ID 2: Filter php_code could not be mapped to an existing filter plugin; defaulting to filter_null.
- See notes for site herzbube.ch for more details
- Conclusion: Error message can be ignored.
Source ID allow_insecure_uploads: No static mapping found for 'NULL' and no default value provided for destination 'allow_insecure_uploads'.
- See notes for site herzbube.ch for more details
- Conclusion: Error message can be ignored.
Source ID mail_system: No static mapping found for 'NULL' and no default value provided for destination 'interface/default'.
- See notes for site herzbube.ch for more details
- Conclusion: Error message can be ignored.
Operation on Blocks failed. The "block_content" entity type does not exist.
- See notes for site herzbube.ch for more details
- Conclusion: Error message can be ignored for the moment.
Source ID 1: File '/var/www/drupal-old/sites/grunzwanzling.ch/files//sites/grunzwanzling.ch/files/grunzwanzling.jpg' does not exist
- See notes for site herzbube.ch for more details
- Conclusion: Error message can be ignored for the moment.
Attempt to create a field user_picture that does not exist on entity type user. Source ID : Attempt to create a field user_picture that does not exist on entity type user.
- See notes for site herzbube.ch for more details
- Conclusion: Error message can be ignored.

Theme

The previous theme, Zen, is no longer available. As a replacement I choose the ultra-simple core theme "Stark"

Manual fixes

Login form was visible to unauthenticated users. Fixed by disabling the block.
Add the "User menu" block, but configure it to show only for authenticated users.
User registration was not restricted to admins only. Manual configuration.

Problems and solutions for kino.herzbube.ch

Steps for performing the migration:

Visit this URL to initiate the migration: https://new-site.kino.herzbube.ch/upgrade
Enter the following details
- Drupal version of the source site = Drupal 7
- Source database
  - Database type = MySQL
  - Database host = localhost
  - Database name = drupal759_kino
  - Database user = drupal
  - Database password = secret
- Source files
  - Public files directory = /var/www/drupal-old/sites/kino.herzbube.ch/files
  - Private files directory = /var/www/drupal-old/sites/kino.herzbube.ch/files
The upgrade wizard informs me that data for the following modules will not be migrated, because "[...]There are no modules installed on your new site to replace these modules". This is OK in all cases, I have added my comments behind the module name.

ldap_authentication   OK. Will manually add configuration later.
ldap_servers          OK. Will manually add configuration later.

Running the upgrade has this result:

Completed 39 upgrade tasks successfully
1 upgrade failed

Visiting the log shows a large number of error entries.

Source ID allow_insecure_uploads: No static mapping found for 'NULL' and no default value provided for destination 'allow_insecure_uploads'.
- See notes for site herzbube.ch for more details
- Conclusion: Error message can be ignored.
Source ID mail_system: No static mapping found for 'NULL' and no default value provided for destination 'interface/default'.
- See notes for site herzbube.ch for more details
- Conclusion: Error message can be ignored.
Operation on Blocks failed. The "block_content" entity type does not exist.
- See notes for site herzbube.ch for more details
- Conclusion: Error message can be ignored for the moment.
Attempt to create a field storage of unknown type image. Source ID : Attempt to create a field storage of unknown type image.
- See notes for site herzbube.ch for more details
- Conclusion: Error message can be ignored.
Attempt to create a field user_picture that does not exist on entity type user. Source ID : Attempt to create a field user_picture that does not exist on entity type user.
- See notes for site herzbube.ch for more details
- Conclusion: Error message can be ignored.

Theme

For the same reasons as outlined in the notes for site herzbube.ch, I'm using the Nexus theme
For configuration details also see the notes for site herzbube.ch

Manual fixes

Filtered HTML text format does not allow certain HTML elements to pass, even though they are explicitly listed. Example: The a element. Fixed by setting the single node's text format to "Full HTML".
Login menu was visible to unauthenticated users. Fixed by configuring the menu in the block layout to show only for authenticated users.
User registration was not restricted to admins only. Manual configuration.

Drupal 7.14 -> 7.50

Upgrade matrix

Each row in the following table corresponds to a package as it appears in /var/www/drupal/sites/all/modules:

Software package	Old	New	URL	Remarks
Modules
advanced_help	7.x-1.0	7.x-1.3	drupal.org
blockanonymouslinks	7.x-1.1	7.x-1.1	drupal.org	No update available
captcha	7.x-1.0-beta2	7.x-1.3	drupal.org
ctools	7.x-1.0	7.x-1.9	drupal.org
date	7.x-2.5	7.x-2.9	drupal.org
email	7.x-1.0	7.x-1.3	drupal.org
extlink	7.x-1.12	7.x-1.18	drupal.org
fivestar	7.x-2.0-alpha2	7.x-2.2	drupal.org
flattr	7.x-1.0-alpha3+7-dev	7.x-1.0-alpha3+7-dev	drupal.org	The code base has changed even though the version remains the same. The previous code base was a 7.x-1.x-dev snapshot from August 4 2012, the new code base is a 7.x-1.x-dev snapshot from October 1 2013.
globalredirect	7.x-1.4	7.x-1.5	drupal.org
ldap	7.x-1.0-beta12+6-dev	7.x-1.0-beta12+6-dev	drupal.org	No update although newer versions are available. See below for details.
link	7.x-1.0	7.x-1.4	drupal.org
pathauto	7.x-1.1	7.x-1.3	drupal.org
recaptcha	7.x-1.7	7.x-2.1	drupal.org	I first upgraded to 7.x-1.13, then to 7.x-2.1
token	7.x-1.1	7.x-1.6	drupal.org
views	7.x-3.3	7.x-3.14	drupal.org
votingapi	7.x-2.6	7.x-2.12	drupal.org
Themes
zen	7.x-5.1	7.x-6.4	drupal.org

Upgrade procedure

General summary

Because I performed this upgrade on pelargir's re-incarnation as a Dedicated Server it took a moment until I had a properly working Apache vhost configuration
I was debating whether to use drush to perform the upgrade, but for the moment decided against it because it would have meant to abandon my preferred upgrade procedure (drush performs an in-place upgrade of the code base)
The main struggle I had was with the corrupted registry database tables. See this section further down for more information.
Drupal 7.50 introduces a new check that warns when it finds leftovers from old modules that were not uninstalled correctly. Details see below.
Drupal 7.50 offers multi-byte UTF-8 support, e.g. for displaying emojis. This page has information about how to configure MySQL. At this time I decided that I don't need this.
LDAP module could not be upgraded because of PHP warning (see below for details)

Site summary

herzbube.ch
- Upgrade worked without problems
- Site test had some problems (see below for details)

grunzwanzling.ch
- Upgrade worked without problems
- Site test passed

kino.herzbube.ch
- Upgrade worked without problems
- Site test passed

Problems and solutions

Problems for all sites

Going to the update script displays a lot of red warnings about missing modules
- Drupal 7.50 introduces a new check for leftovers of modules that were not uninstalled properly. An example warning message that update.php displays is this:
  User warning: The following module is missing from the file system: flexinode. In order to fix this, put the module back in its original location. For more information, see the documentation page. in _drupal_trigger_error_with_delayed_logging() (line 1128 of /var/www/drupal-7.50/includes/bootstrap.inc).
- Here is an explanation of what this is all about, and how it can be fixed
- In my case, of course I can't re-add ancient modules such as flexinode just to uninstall them, so I have to use the manual approach: Directly fiddle with the database tables
- The query to use is delete from `system` where name in ("foo", "bar", ...) and type="module"
- Caches must be cleared afterwards. I already have caches cleared and disabled during the upgrade process, so that's not something I have to do
- The list of modules that I was warned about, and the concrete SQL queries used to fix the problem can be found below under "Site-specific problems"
.htaccess file in each site's files folder is not up to date
- The status report detects the problem and points to this security advisory
- Instead of manually fiddling with the .htaccess file, I delete the original file and let Drupal re-create the file with appropriate content
- Do this by going to "Administration > Configuration > Media > File system", on that page click the "Save configuration" button
- The file is created with www-data:www-data ownership
LDAP module could not be upgraded because of PHP warning
- At the time of writing this, the LDAP module has a beta release both for 7.x-1.0 (the branch I am currently on) and for 7.x-2.0.
- The project page says in regard to the 7.x-1.0 branch that
  It is recommended to stick with whatever version of it you have working currently until 7.x-2.0RCs come out.
- In the release notes for 7.x-1.x-dev I find the following :
  7.x-1.x-dev will have bug fixes when patches are submitted and tested. Otherwise it is being abandoned in favor of the 7.x-2.x branch. Only use the 7.x-1.x branch if you are working with an existing site that its functional on.
- I also find this in the release notes for 7.x-2.0-beta6:
  There is no upgrade path from 7.x-1.x to 7.x-2.x. Please uninstall and reinstall and reconfigure ldap modules. When a 7.x-2.0 release candidate is available, an upgrade path will be worked on.
- With all this information, I decided to stick to 7.x-1.x-dev
- I noticed that the official 7.x-1.0-beta12 release is slightly older than what I am currently using - apparantly I have already installed a 7.x-1.x-dev version on September 14 2012.
- To continue with this "tradition", I decided to install the current 7.x-1.x-dev snapshot which is from March 14 2016
- When I tried that snapshot, I immediately got this warning on the update.php page:
  Notice: Constant LDAP_DEREF_NEVER already defined in include_once() (line 92 of /var/www/drupal-7.50/sites/all/modules/ldap/ldap_servers/ldap_servers.module).
- I immediately backed off because I don't want any hassles. I decided to skip this upgrade, especially in light that the new module version needs to perform a database scheme upgrade, which means I can't just try out the new code base.
- Note: Comment 9 and 10 in this bug report mention the reason for the PHP warning
- For future updates: Check this post to see whether the module has made any progress towards a stable release

Site-specific problems & tasks

herzbube.ch
- I received a warning about 17 modules that were not properly uninstalled (explanation of the general problem is above). The following SQL command clears entries for those modules from the system database:

delete from `system` where name in ("archive", "flexinode", "page", "story", "upload", "urlfilter", "watchdog", "workspace", "content", "content_migrate", "optionwidgets", "matrix", "date_timezone", "basicevent", "loginmenu", "taxonomy_image_link_alter", "taxonomy_image_node_display") and type="module"

- Warning about several orphaned actions. The warnings were generated because the code for the actions could not be found because the code resides in modules that were disabled at that time. By re-enabling the modules the actions became "un-orphaned". Cf. this Stack Overflow post.

grunzwanzling.ch
- I received a warning about 3 modules that were not properly uninstalled (explanation of the general problem is above). The following SQL command clears entries for those modules from the system database:

delete from `system` where name in ("upload", "watchdog", "content_migrate") and type="module"

- Warning about an orphaned action user_block_ip_action. As it turned out the action existed twice in the actions table. I removed the duplicate by visiting this link: /admin/config/system/actions/orphan.

kino.herzbube.ch
- No problems

Drupal 6.14 -> 7.14

Upgrade matrix

Each row in the following table corresponds to a package as it appears in /var/www/drupal/sites/all/modules:

Software package	Old	New	URL	Remarks
Modules
advanced_help	6.x-1.2	7.x-1.0	drupal.org
calendar	6.x-2.2	-	drupal.org	No upgrade because I only used this module for the ludenti.ch website, and that website is gone
captcha	6.x-2.0	7.x-1.0-beta2	drupal.org
cck	6.x-2.5	-	drupal.org	No upgrade because this module has been incorporated into Drupal core. Uninstall of submodules "Fieldgroup", "Node Reference", and "User Reference" which I don't actually use even though they are currently activated
ctools	6.x-1.2	7.x-1.0	drupal.org
date	6.x-2.4	7.x-2.5	drupal.org
email	6.x-1.2	7.x-1.0	drupal.org
extlink	6.x-1.8	7.x-1.12	drupal.org
fivestar	6.x-1.19	7.x-2.0-alpha2	drupal.org
globalredirect	6.x-1.2	7.x-1.4	drupal.org
link	6.x-2.5	7.x-1.0	drupal.org
pathauto	6.x-1.2	7.x-1.1	drupal.org
recaptcha	6.x-1.3	7.x-1.7	drupal.org	The recaptcha PHP library does not need an upgrade, version 1.10 is still the latest version
taxonomy-image	6.x-1.6	-	drupal.org	No upgrade because there is no Drupal 7 version of this module. The core maintainers claim that this module is not needed in Drupal 7.
token	6.x-1.12	7.x-1.1	drupal.org
views	6.x-2.6	7.x-3.3	drupal.org
votingapi	6.x-2.3	7.x-2.6	drupal.org
Themes
sky	6.x-3.9	-	drupal.org	No upgrade because the Drupal 7 version of the theme has been completely changed so that it no longer looks good to me.
zen	6.x-1.0	7.x-5.1	drupal.org

Upgrade procedure

General summary

I had to perform 2 upgrades, as described in Drupal's UPGRADE.txt:
- Drupal 6.14 -> Drupal 6.26 (latest at the time of writing)
- Drupal 6.26 -> Drupal 7.14
The first upgrade worked smoothly
The second upgrade had a few hitches, obviously because this was an upgrade to a new major version of Drupal. See the problems section below for details.

Site summary

herzbube.ch
- Successful uninstall of modules "Taxonomy image", "Fieldgroup", "Node Reference", and "User Reference"
- Upgrade worked without problems
- CCK data migration (as outlined in http://drupal.org/node/1144136) worked well
- Site test had some problems (see below for details)

grunzwanzling.ch
Upgrade worked without problems
- Site test passed

Problems and solutions

General things/problems that needed to be done/solved due to the major version upgrade:

Because settings.php in D7 changed the way how the database connection is set up, htb-drupal-copysites.sh failed to generate a correct settings.php in the D7 site directories. I fixed this by giving update.php temporary write access to the file and letting it generate the necessary settings for me. Afterwards I modified htb-drupal-copysites.sh to work correctly in the future. Note: Drupal no longer uses mysqli as the database driver.
D7 (specifically update.php, and later the "Views UI" module) requires more memory than D6. After experimenting I increased PHP's memory limit to 40 MB in the appropriate places in the Apache configuration.
Deleted sites/default/default.settings.php as recommended in the D7 UPGRADE.txt
Added new symlinks to each site's vhost document root (e.g. /var/www/herzbube.ch) for the following files that are new in D7: authorize.php, web.config

Site-specific problems & tasks

herzbube.ch
- Uninstalling the module "Fieldgroup" required that the CCK main module "Content" be active. At first I had "Content" already disabled, but then uninstalling "Fieldgroup" would not work (I always got an empty page with no error message). Activating "Content" fixed this problem.
- The D6.26 version of update.php displayed a warning involving the database table semaphore, which I ignored because I observed that the table had been successfully created during the upgrade process. This was the warning text:
  - user warning: Table 'drupal626_herzbube.semaphore' doesn't exist query: SELECT expire, value FROM semaphore WHERE name = 'module_rebuild_cache' in /var/www/drupal-6.26/includes/lock.inc on line 149.
- D7 update.php displayed a message that the footer message previously defined on the theme had been automatically migrated to a custom block that appears in the footer. This is OK for me.
- Received the following warning messages when migrating CCK data in D7. Ignored the messages because 1) it's OK to limit the heading field length; and 2) I don't know anything about the "text_hidden" formatter, but as it turned out the default formatter was OK.
  - Invalid field/widget combination: The field 'field_plot_heading' in the bundle 'bookreview' is an unlimited length field using a textfield widget, not allowed in D7. The field length will be set to 255.
  - Missing formatter: The 'text_hidden' formatter used in 1 view modes for the field_plot_heading field is not available, these displays will be reset to the default formatter.
- Enabling the "Sky" theme in D7 did not work. On activating the theme the entire site went entirely blank and became utterly unusable. I had to fix this by disabling the theme manually in the database. Clearing the cache, as suggested somewhere on drupal.org did not fix this problem. I stopped investigation after I realized that the D7 version of the theme looks completely different from the D6 version, and that I don't like the design of the D7 version. For the moment I settled on using the Bartik core theme, but eventually I will have to find a new theme.
- As a side-effect of not using the "Sky" theme anymore, I now need to configure blocks for the Bartik theme
  - Disable empty block "Book navigation"
  - Enable blocks "Get CAcert root certificates" and "Book Reviews" (powered by Views)
- D7 update.php displayed a message notifying me about changes to Pathauto patterns having been changed. Reviewing these patterns after the upgrade was complete revealed that the old patterns had all become invalid. At the bottom of this Pathauto issue I found a helpful summary with suggestions for the new patterns. See DrupalModules#Pathauto for the currently defined patterns.
  - Due to the change in available tokens, the aliases for taxonomy terms no longer involve a "path" to the term. For instance, the alias for the "UML" term in the "Topics" vocabulary in D6 was this: "category/topics/computers/software-engineering/software-engineering-concepts/uml". In D7, however, the alias for the same term now looks like this: "topics/uml". I am somewhat missing the old structure, but nothing can be done about this, there is no way to get back to the old behaviour. I am therefore focusing on the good part: The new alias is much shorter :-)
  - After accidentally recreating too many URL aliases I had to manually fix the following Page nodes which don't follow the Pathauto pattern rules: about, software, and all the software project main pages (acexpander, aqua-crystal-ball, dgsmonx, littlego, mkroesti, python-aprmd5)
- Fixes to the "book_review" view
  - In the block configured for the view, the field "Content: Rating" was removed. I had to manually re-add this field after the upgrade.
  - In the block configured for the view, the title column which used to contain both author and title fields now only contained the title field. I had to manually create a new custom field that merges both title and author in one field. The way how this is done has apparently changed from D6 Views to D7 Views.
  - The view also has a page configured which is supposed to display Book Review teasers. Apparently, during the upgrade the Book Review content type has lost its settings for the Teaser view mode. These settings need to be recreated, i.e. go to "Administration > Structure > Content types > Book review > Manage display" and disable all fields except Author, Rating and Recommendation.
  - In the block configured for the view, edit the settings of the pager and make sure that the Pager ID is set to 1. Leaving this at 0 causes the pager at the bottom of the main page to disappear due to some sort of ID conflict. I got the hint for solving this from here.
- Updated robots.txt to match the D7 version of the file
  - However, I repeated the decision from the previous D5 to D6 upgrade to not add "Crawl-delay: 10" to robots.txt (reason: Crawl-delay appears to be slightly non-standard, and so far I have not experienced any issues with crawlers)
- Taxonomy image site test failed: I am currently looking for a replacement for the Taxonomy Image module.
- CAPTCHA site test failed: I need to repeat my research on how to get CAPTCHAs to work again.

grunzwanzling.ch
- Same warning as for herzbube.ch regarding database table semaphore
- update.php notified me of the following: "The content type page had uploads disabled but contained uploaded file data. Uploads have been re-enabled to migrate the existing data. You may delete the "File attachments" field in the page type if this data is not necessary."

Drupal 6.8 -> 6.14

Upgrade matrix

Each row in the following table corresponds to a package as it appears in /var/www/drupal/sites/all/modules:

Software package	Old	New	URL	Remarks
Modules
blockreference	6.x-1.10	-	drupal.org	No upgrade because I have never used this module
cache_browser	6.x-1.3	-	drupal.org	No upgrade because I have used this module only temporarily for troubleshooting
calendar	6.x-2.0-rc6	6.x-2.2	drupal.org
captcha	6.x-2.0-beta1	6.x-2.0	drupal.org
captcha_pack	6.x-1.0-beta2	-	drupal.org	No upgrade because I use reCAPTCHA
cck	6.x-2.1	6.x-2.5	drupal.org
date	6.x-2.0-rc6	6.x-2.4	drupal.org
email	6.x-1.1	6.x-1.2	drupal.org
format_number	6.x-1.3	-	drupal.org	No upgrade because I have installed this only temporarily as a dependency of cache_browser
jstools	6.x-1.0	-	drupal.org	No upgrade because this module is obsolete
link	6.x-2.5	6.x-2.6	drupal.org	It appears that the module has been adopted again by a maintainer, so I am going to continue to use it
panels	6.x-2.0-alpha3	-	drupal.org	No upgrade for the moment, although it appears that the module has reached a stable state for Drupal 6.
recaptcha	6.x-1.1	6.x-1.3	drupal.org	The recaptcha PHP library does not need an upgrade, version 1.10 is still the latest version
taxonomy-image	6.x-1.5	6.x-1.6	drupal.org
viewreference	6.x-2.11	-	drupal.org	No upgrade because I have never used this module
views	6.x-2.2	6.x-2.6	drupal.org
Themes
sky	6.x-1.0-beta3		drupal.org
zen	6.x-1.0-beta3	6.x-1.0	drupal.org

Upgrade procedure

The upgrade procedure follows the general procedure outlined further up. These are the details:

No customizations to modules or themes are necessary
Did not add "Crawl-delay: 10" to robots.txt because it appears to be slightly non-standard, and so far I have not experienced any issues with crawlers
herzbube.ch
- Uninstall of modules "Panels" and "Panels page" (see below for problems that occurred, and their fixes)
- Uninstall of module "Views"
- Upgrade worked without problems
- Site test passed
moser-naef.ch
- Uninstall of module "Views"
- Upgrade worked without problems
- Site test had some problems (see below for details)
ludenti.ch
- Upgrade worked without problems
- Add module "jQuery UI" as a new dependency of "Date popup" (see below for details)
- Site test passed
grunzwanzling.ch
- Upgrade worked without problems
- Site test had some problems (see below for details)

Problems and solutions

The following things needed fixing:

herzbube.ch
- Uninstalling the old version of Panels did not work flawlessly
  - The "Panels" module issues warnings when an uninstall is attempted, about three tables that it tries to drop but that do not exist (panels_display, panels_pane, panels_object_cache)
  - I simply ignore these warnings because it doesn't matter to me if a table cannot be dropped because it does not exist; what is important is that all tables are gone after the uninstall process has finished
  - The "Panel pages" module refuses to do anything and prints the following error: "Fatal error: Call to undefined function panels_get_path() in /var/www/drupal-6.8/sites/all/modules/panels/panels_page/panels_page.module on line 476"
  - The error can be made to "go away" by inserting the following line into panels_page.module, just before the function definition that contains the unknown function call: require_once '/var/www/drupal/sites/all/modules/panels/panels.module';
  - Note: This is a really crude hack to get the uninstall function working, but it does the trick!!!
  - Uninstalling "Panel pages" appears to drop the database tables "panels_page" and "panels_page_router_store", while uninstalling "Panels" does not appear to do anything (except removing the module from the list of modules that are available for uninstall)
  - After both modules "Panels" and "Panel pages" have been uninstalled, there still are two Panels-related tables in the database: "panels_area" and "panels_info"
  - These tables do not appear anywhere in the code of panels-6.x-2.0-alpha3, except for a hint about "panels_info" in the file KNOWN_ISSUES.txt. The hint indicates that "panels_info" was a table of Panels 1. This can be confirmed by looking at the source code of panels-5.x-1.0.tar.gz, at the install/uninstall hooks defined in the file panels.install
  - With this information, I feel confident to simply drop the offending tables manually
  - In addition to all this, I have been digging around a bit in Panels' source code and I found the install/uninstall hooks in the panels.install and panels_page/panels_page.install files. It appears that both modules simply define additional DB tables that are created on install, and dropped on uninstall. With this information, I feel confident that I have completely removed all traces of the module from my databases

ludenti.ch
- The "Date popup" module suggests installing the "jQuery UI" module
  - The "Date popup" module would like to use the date picker provided by the "jQuery UI" module
  - For the moment, "Date popup" provides its own copy of the date picker, but this might change in the future (and the copy might not be as current as the one provided by "jQuery UI"
  - Solution is to install "jQuery UI"
  - "Date popup" automatically detects the presence of the other module

moser-naef.ch
- The site name displayed the "&" character as "&"
  - This problem seems to be addressed in issue http://drupal.org/node/461938, and a backport to Drupal 6 seems to be possible
  - For the moment I modify my site title to use the word "and", but I also add an issue to Bugzilla to be able to track the issue

grunzwanzling.ch
- The front page displays an attachment link to the .jpg file
  - Fixed by editing the page and saying, under the file attachment options: list = false

Drupal 5.1 -> 6.8

Upgrade matrix (each row in the following table corresponds to a package as it appears in /var/www/drupal/sites/all/modules):

Software package	Old	New	URL	Remarks
Modules
calendar	5.x-1.4	6.x-2.0-rc6	drupal.org
cck	5.x-1.5	6.x-2.1	drupal.org
cck_email	5.x-1.x-dev (downloaded January 5 2007)	6.x-1.1	drupal.org
cck_field_perms	5.x-1.4	-	drupal.org	This module is now distributed with the Drupal6 version of CCK as `content_permissions` module
cck_link	5.x-1.4	6.x-2.5	drupal.org	Warning: The module looks for a new maintainer, so may become unsupported at some point in the future
cck_matrix	5.x-1.0	-	drupal.org	Dropping this module because it has never been ported to Drupal 6
date	5.x-1.5	6.x-2.0-rc6	drupal.org
event	HEAD (downloaded ?)	-	drupal.org	Dropping this module because I no longer use it; there is no official release for Drupal 6, anyway
jstools	5.x-0.3	-	drupal.org	Dropping this module because it no longer provides the "jscalendar" widget (which was why the module was included in the first place)
loginmenu	5.x-1.x-dev (downloaded November 20 2006)	-	drupal.org	Dropping this module becaues Drupal 6 core now provides the module's functionality (see module's project page)
panels	1.1	-	drupal.org	Dropping this module for the moment because the Drupal 6 version is still considered alpha (6.x-2.0-alpha3), and there seem to be a lot of plans for redesign. Later, when the software has matured, I will probably come back to this module. Currently, only the AceXpander page on herzbube.ch was designed with panels, so it's easy to do without the module.
views	5.x-1.5	6.x-2.2	drupal.org
Themes
aquasoft	5.x-1.0	-	drupal.org	Dropping this theme because it has never been ported to Drupal 6
zen	5.x-1.0	6.x-1.0-beta3	drupal.org

Notes:

There are now two major versions of the Views module: Views 1 and Views 2. I am going to install Views 2 (not sure if Views 1 is available for Drupal 6), which causes the following upgr
- The Calendar module has been rewritten to the Views 2 API (article on drupal.org), the module is now referred to as "Calendar 2.0"
The CCK module has its own specific instructions for the 5.x to 6.x upgrade
Check out what I need jstools for - the module's "Jscalendar" part is not available for Drupal 6, the project page says the following
- "Jscalendar: The JS library it integrates is obsolete and unmaintained; there are jQuery alternatives available."
- "As the Jscalendar library is no longer maintained, this module is deprecated past Drupal 5. There are jQuery-based alternatives."
Check out how the Aquasoft theme can be replaced

Upgrade procedure:

in the Apache configuration, set php_value memory_limit 24M (the previous value of 16M is not sufficient for the new Views module in Drupal 6.2; this was determined "experimentally")
as suggested by UPGRADE.txt in the new 5.1 tar ball, the following steps for an upgrade are required:
prepare the 6.8 directory as usual & disable cron jobs (see above)
install new versions of modules and themes into sites/all/modules and sites/all/themes
just before switching the symlink, do the following for each of the existing sites:
- log in as administrator
- place the old site into off-line mode
- if using a custom or contributed theme, switch to a core theme, such as Garland or Bluemarine
- disable all contributed (= non-core) modules
- DO NOT LOG OUT
from here, continue only if all sites have been prepared for the upgrade!
switch the symlink
for all sites, do the following:
- re-load the page (in this case, when upgrading from 5.1 to 6.8, a lot of error messages will be displayed)
- for some reason, Drupal "forgets" that the user is still logged in; for this reason, the site's settings.php needs to be changed so that it contains the entry $update_free_access = TRUE;
- run update.php (updates the core database tables to the new Drupal installation)
- revert the site's settings.php so that it contains the entry $update_free_access = FALSE;
- because the user is not logged in, it is not possible to go back to the administration pages; because the site is still in offline mode, the login link is not directly available - to login the browser must be manually pointed at http://<site>/drupal/?q=user
- after logging in, go to the modules page and re-install contributed modules
- re-run update.php (update contributed database tables to the new Drupal installation)
- go to the status report page (http://<site>/drupal/admin/reports/status) and fix any remaining errors; I encountered the following:
  - manually run cron.php
  - set the site timezone name (required by the "Date Timezone" module)
- Note: check the site timezone (http://<site>/drupal/admin/settings/date-time) even if it is not mentioned on the status report page; one of my sites was configured with "Africa/Algiers" instead of "Europe/Zurich"
- return the site to its original theme
- return the site to online mode

The following things needed immediate fixing:

herzbube.ch
- the upgrade produces the following error message

user warning: Duplicate entry '34-0' for key 1 query: ALTER TABLE locales_target ADD PRIMARY KEY (language, lid, plural) in /var/www/drupal-6.8/includes/database.mysql-common.inc on line 374.

- - this drupal.org page apparently reports the same error
  - manually add the primary key within phpmyadmin (note that there are no table rows with lid=0, which would have to be deleted if we were to follow the above bug report on drupal.org)

ALTER TABLE locales_target ADD PRIMARY KEY (language, lid, plural)

- HTML comments "" need to removed from the "About" page because Drupal 6 displays these comments
- some links (wiki, photo gallery and the dragon go server) need to be re-added to the "Links" menu because they were "magically" stripped away during the upgrade
  - the reason being the annoying path validation "feature" of Drupal 6: Drupal 6 thinks that a path which is not a full URL (e.g. "redirect_url=/mediawiki/") is invalid if it does not refer to an existing node, nor to a file system directory
  - because of this feature, the re-created links need to be absolute, e.g. http://www.herzbube.ch/mediawiki/
  - I have commented on the path validation feature in this issue on drupal.org
- replace the "login" link previously provided by the loginmenu module:
  - go to '/admin/build/menu-customize/navigation'
  - click "Add Item"
  - use the following:
    - path = user/login
    - menu link title = Log in
    - parent item = "Navigation" (i.e. the menu itself)
    - weight = 10
- replace the "aquasoft" theme by the "sky" theme
- add "delete own book|page|story content" permission to the appropriate roles
moser-naef.ch
- add primary key to database table locales_target (see above under herzbube.ch for details)
- some links (photo gallery, DVD list, wiki Francesca) need to be re-added to the "Links" menu (see notes for the herzbube.ch site for details about this)
- replace the "login" link previously provided by the loginmenu module (see notes for the herzbube.ch site for details about this)
- add "delete own book|page|story content" permission to the appropriate roles
ludenti.ch
- add primary key to database table locales_target (see above under herzbube.ch for details)
- HTML comment ("") needs to removed from the "About" page because Drupal 6 displays these comments
- replace the "login" link previously provided by the loginmenu module (see notes for the herzbube.ch site for details about this)
- CCK custom field "field_datum"
  - the date granularity must be set to include all three values year, month, day; unless this is done, nodes that contain this field type do not display the field at all; note that this setting was correct in Drupal 5, but somehow got lost when upgrading
  - change the field's widget type to "Text field with Date pop-up calendar" (first enable the "Date Popup" module); this needs to be done because the module "Javascript tools" no longer provides the "jscalendar" widget
- views (calendar, fridayevents, gameevents, workspace) need to be re-created from scratch, as conversion from Views 1 to Views 2 format does not produce usable results
- add "delete own book|page|story|fridayevent|gameevent content" permission to the appropriate roles
grunzwanzling.ch
- none

Troubleshooting

Unable to log out in Drupal 4.5.5

This version of Drupal contained a bug that made it impossible to log out.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=336719

Fix: in /usr/share/drupal/includes/session.inc, in the function sess_destroy() change the DB query from

WHERE sid = '%d'

to

WHERE sid = '%s'

Database table `cache_filter` keeps growing

When I was preparing for the upgrade from Drupal 5 to Drupal 6, I noticed that the database dump for one of my sites was unreasonably large (>140 MB, as compared to 2 MB for other site databases). Snooping around the site database with phpmysql revealed that the table cache_filter was the culprit: It contained 56709 rows, totalling to about 127 MB of data.

The following questions arose:

What is the purpose of cache_filter?
Can the table be cleared manually?
If not, how else can the table be cleared in a safe way?

Searching drupal.org did not reveal any useful answers, however this page provides the following information:

cache_filter is one of four caching table
a comment at the bottom of the page seems to indicate that it is possible to clear the table periodically with cron with "delete from cache_filter"

All in all, however, I have found no conclusive answers to my questions, so for the moment I leave the table as it is.

Update: The upgrade from Drupal 5 to Drupal 6 seems to delete entries from the table. Corresponding code can be found in update.php.

SQL syntax error in CAPTCHA module

An SQL syntax error in the CAPTCHA module prevents user input from being evaluated successfully. See this issue on drupal.org. The fix suggested in the issue report is already committed in CVS-HEAD, but has not yet been released, therefore the change to the file captcha.pages.inc needs to be applied manually.

Corrupted registry database tables

When I upgraded from Drupal 7.14 to 7.50, I was unable to commence the upgrade process because whenever I attempted to access the site under the new-site URL I found mysterious and (to me) nonsensical messages like the following in my Apache error log:

[Thu Jul 07 03:36:05.308459 2016] [:error] [pid 47994] [client 212.101.18.224:64152] PHP Fatal error:  Class 'SelectQueryExtender' not found in /var/www/drupal-7.50/includes/pager.inc on line 15
[Thu Jul 07 03:39:31.204929 2016] [:error] [pid 48039] [client 212.101.18.224:64190] PHP Fatal error:  Class 'DrupalDefaultEntityController' not found in /var/www/drupal-7.50/modules/comment/comment.module on line 1681
[Thu Jul 07 04:05:20.138656 2016] [:error] [pid 48017] [client 212.101.18.224:64473] PHP Fatal error:  Class 'DatabaseTasks_mysql' not found in /var/www/drupal-7.50/modules/system/system.install on line 188

After much grinding of teeth (why are Drupal upgrades never ever smooth) and many hours of fruitless attempts to solve the problem, I finally found this bug report which describes a problem similar to mine.

Comment 6 of the bug report indicates where the problem lies, namely that database tables "registry" and "registry_file" are corrupted.

Comment 8 has a link to this page, which is about an ultra-useful, life-saving, world-rescuing PHP script that magically rebuilds those database tables. Here are the instructions how to run the script via drush (these instructions come directly from the "Rebuild Registry" page, but are slightly adapted to my use):

Because I was in the process of upgrading, I already had a database backup - if you don't have a backup, make one now
The following command downloads the PHP script and places it in the ~/.drush folder

drush @none dl registry_rebuild

Clear Drush cache

drush cc drush

On a multisite installation, switch to the folder of the site. In my case:

cd /var/www/drupal-new/sites/herzbube.ch

Rebuild the registry tables. This performs a soft rebuild.

drush rr

In my case this didn't help, so I had to perform an "aggressive rebuild from scratch"

drush rr --fire-bazooka

My conclusion: Those registry database tables contain references to filesystem paths. These references are rendered invalid by my upgrade procedure because I place the new code base in an entirely new filesystem folder. So before I can access the cloned databases with the new code base, I have to rebuild those references in the registry database tables, so that they now point to the new code base.

DrupalMaintenance

Module upgrade

Site upgrade strategy

Site upgrade procedure

Preparation

Extract tar balls

Repeat customizations

Prepare sites for the upgrade

Create/update symlinks

Duplicate databases and generate sites

Access to old-site and new-site subdomains

Disable/uninstall modules (using old code base)

Perform the upgrade (using new code base)

Activate the upgraded sites

Cleanup

Site-specific tests after an upgrade

herzbube.ch

grunzwanzling.ch

kino.herzbube.ch

Simplified site upgrade

Upgrade logs

Drupal 7.50 -> 8.5.6

Upgrade matrix

Upgrade procedure

Problems and solutions for herzbube.ch

Problems and solutions for grunzwanzling.ch

Problems and solutions for kino.herzbube.ch

Drupal 7.14 -> 7.50

Upgrade matrix

Upgrade procedure

Problems and solutions

Drupal 6.14 -> 7.14

Upgrade matrix

Upgrade procedure

Problems and solutions

Drupal 6.8 -> 6.14

Upgrade matrix

Upgrade procedure

Problems and solutions

Drupal 5.1 -> 6.8

Troubleshooting

Unable to log out in Drupal 4.5.5

Database table cache_filter keeps growing

SQL syntax error in CAPTCHA module

Corrupted registry database tables

Navigation menu

Search

Database table `cache_filter` keeps growing