Drupal - Error Messages On site reinstall

One of the damnest things to frustrate a 'Drupalist' is running into error messages or the dreaded 'white screen of death' otherwise known as 'WSOD' to enthusiasts. The journey to mastering Drupal is never complete until 'Problem solving' these installation issues become a learnt skill. Most adent developers with proficient coding or programming skills avoid these issues by deploying backend solutions through scripting or querying the database 'error messages' effectively. Drupal is an intuitive CMS. It however requires fairly adequate knowledge of its methods 'The Drupal Way' of doing things. Each drupal version until version 8, had been very different. The development of Drupal 8 (D8) paved the way for a consistent transition between subsequent versions. With the drive towards a more 'fluid' functionality, it is imperative that certain changes would constrain the developer to consider moving onto version 9.

Audience

This article is aimed at beginners and perhaps intermediate drupalists who may have experienced challenges reinstalling there website from an earlier Drupal version 8.

The setting

Deploying a drupal site is generally possible in shared hosting sites. However having access to SSH as a root user would make one's experience significantly better.

This article would assume the reader is able to gain access to the database via cpanel (terminal, phpmyadmin) or SSH (Git Bash,, PUTTY, VSCode etc).

Relevance is in a re-install of D8/9 site from older d8 versions. Transfering old database 'node' content to new database by 'importing' saved copy from previous database may trigger error alerts when attempting to access or save editted content! There are usually no issues with other module contents such as custom 'blocks', poll, taxonomy, or forms. This the scheme for these contents are often unaltered.

Previously, my solution has been to enter all content directly into the new webpage 'as new content', but dated retro - which is evidently not practical for a large site. Another solution would be to install a new Drupal site, then 'wholesale' drop the new database (via phpymyadmin or SSH mysql access), replacing this with the preferred database. The next step would be to switch to previous configuration in the 'files' folder, adjusting the settings.php file to accept the older configuration. This method may not always be issue-free and requires familiarity with these steps.

Motivation - Complete Drupal re-installation by transferring relevant node data via the database, resolving all conflicting issues systematically

Previously, I had been unsuccessful in attempting to add old 'content' via the database 'nodes' by directly importing these nodes into the new database - like for like. I did try to replicate the content types as close as possible.

Any attempt to save an editted copy of the node content trigger an alert "The website encountered an unexpected error. Please try again later."

Suspect missing url links, permission errors, mismatched field names or disparity in modules in the configuration of the content type of the new vs old install. The error log gives a number of messages - depending on which content type is involved.

Risks include mismatched

• node names including storage names
• content types
• content modules (e.g schedule added to new content, and absent in previous source data)
• content translation data
• layout_builder info (if you are using this module), etc

Solution

'Drush'- Drupal Shell is your friend. Others might use Drupal console. However I found Drush very useful in many respects including checking for possible errors with:

• 'drush ws',
• clearing cache with 'drush cc',
• updating database with 'drush updb',
• enabling or disabling (uninstalling) modules and
• of course deploying composer require, remove, update or install.

   

  Get acquainted with the 'Recent log messages' under the 'Reports' admin tab. You may discover after correcting the culprit mismatched field, and creating the new field in the content type, you still get an error page and all 'content' fails to be listed. In views, content list, you might get an error message indicating missing database tables, advising you to select * from ... where and (placeholders ...#1 to zzs, representing the number of content items missing). All I did was to import the database table from previous database and voila, all resolved.

  "SQLSTATE[42S22]: Column not found: 1054 Unknown column 'publish_on' in 'field list': INSERT INTO {node_field_data} (nid, vid, type, langcode, status, uid, title, created, changed, promote, sticky, default_langcode, revision_translation_affected, publish_on, unpublish_on, content_translation_source, content_translation_outdated) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, ...

  Working backwards to resolve mismatched Drupal configuration files!

  Access to config files via:

  • phpmyadmin and
  • SSH login to database
  • On the production site - Configuration editor (Devel module)
  • Development (localhost) computer : Working with mysql workbench directly! This allows directly editing the (Blob data) on a copy of the old database, making the necessary corrections

  Through these steps, I was able to reinstall all nodes from previous site into the new installation including remote media (video) files avoiding the labourous process of adding every content via the new content page