Drupal Core has been updated from 10.3.10 to 10.4.0. I checked the update notification and updated it immediately, but this time, as usual, it did not update smoothly without any problems, and I had to struggle with error processing and recovery.
Let's look at the reasons why the update did not go smoothly this time.
- Incomplete update processing due to inadequate PHP memory limit settings
- HTTP ERROR 500 due to inability to load Bootstrap5
- Translation errors due to mismatched entity and field definitions
There were three main problems, and we dealt with each of them by identifying the cause. The root cause is thought to be errors caused by incomplete update processing due to insufficient PHP memory, but there may also have been an impact from dependencies related to the core program from 10.3x to 10.4.
‘As a side note, the Drupal-CMS release is imminent and we will be supporting it from 11.1.X. As we are also looking to update 10.4.X to 11.1.X, I think that the delay in supporting themes and modules is also one of the causes.’
We are taking the following measures to deal with incomplete updates and configuration file issues caused by insufficient PHP memory limits.
Problems encountered with the Drupal Core 10.4.0 update
- PHP memory limit was set to 256MB.
- Timeout with composer update
- Changed PHP memory limit to 1024MB
- Updated again
- Installation did not occur
- Identifying the cause of the installation failure
- 10.4.0 installation completed on Composer
- 10.3.10 displayed on Drush and admin screen
- Identifying the cause
- composer.lock was not updated successfully
- Update composer.lock
- The problem with drupal/core not being updated to the latest version
- Rebuild drupal/core
- Update complete
The Drupal Core update was completed successfully, but an HTTP ERROR 500 was displayed and it became impossible to display public pages or log in to the administration screen. The cause was that Bootstrap was not being loaded correctly, but there was a possibility that the dependency relationships in the vendor directory were damaged or that it was referencing old files, so we are dealing with this by repairing the vendor files.
Error after update completion
- HTTP ERROR 500 is displayed and the page does not display.
- Fatal Error occurs due to autoload.php not being found
- This can be resolved by completely regenerating the vendor directory
The display of the public pages has been successfully repaired, but an error occurs saying that the definitions of the entities and fields related to the translation are inconsistent. It is thought that the repair of the vender directory caused the inconsistency of the entities and fields, so we are dealing with this by updating the entities.
Displayed errors
- Entity field definitions
Entity and field definitions do not match
The following changes were detected in entity type and field definitions. - Custom menu links
Translation source field needs to be uninstalled.
Translation expired field needs to be uninstalled.
Translation contributor field needs to be uninstalled.
Translation status field needs to be uninstalled.
Translation created date field needs to be uninstalled. - Content
Translation Source field needs to be uninstalled.
Translation Expired field needs to be uninstalled. - Taxonomy Term
Translation Source field needs to be uninstalled.
Translation Expired field needs to be uninstalled.
Translation Contributor field needs to be uninstalled.
Translation Date field needs to be uninstalled.
Repair
- This is thought to have occurred due to the regeneration of the vendor directory, so it can be fixed by updating the entity.
This update has been successfully updated by addressing the above three errors.
We will summarise the verification and response to the errors that occurred this time. We will be using functions of composer and drush that we have not used before when verifying and responding.
Update to Drupal Core 10.3.10 > 10.4.0 using composer update.
Up Date stopped in the middle and timed out, so we will deal with the PHP memory shortage.
// Update Drupal
$ sudo composer update ‘drupal/core-*’ --with-all-dependencies
// Installation did not finish due to a timeout. Terminate and identify the cause
// PHP memory was set to 256MB
----- Change PHP memory to 1024MB -----
// Check the location of the PHP ini file
$ php --ini
Configuration File (php.ini) Path: /opt/bitnami/php/etc
Loaded Configuration File: /opt/bitnami/php/etc/php.ini
// Change the PHP memory limit in vim
$ sudo vim /opt/bitnami/php/etc/php.ini
// php.ini description
// Change memory_limit = 256MB to 1024MB
memory_limit = 1024MB
// Restart the server to apply the settings
sudo /opt/bitnami/ctlscript.sh restart phpResult
Drupal administration screen > Reports > Site status to check the PHP memory change
As I have changed the PHP memory to 1024MB, I will check the current situation.
Check for dependencies using Composer.
// Check for Drupal core and module updateable packages
$ sudo composer outdated drupal/*
// List installed package dependencies
$ sudo composer show -t
// Simulate the state after updating without applying changes
$ sudo composer update --dry-run
-----
Nothing to modify in lock file
-----
Nothing to install, update or remove
-----Result
No problems detected.
Let's try checking the dependencies with drupal-check.
- drupal-check scans Drupal code and dependencies to detect problems.
drupal-check . - drupal-check . is quite heavy and there is a high possibility of the server stopping, so please check the usage environment and if possible, test it in a local or staging environment before running it.
- If you run drupal-check ., the server may freeze due to the load and it may be necessary to force a server reset. Please refrain from using it unless you have the authority to reset the server.
Install drupal-check.
// Install drupal-check
$ composer global require mglaman/drupal-check
// Check installation
$ drupal-check --version
// Installation complete successfully
-----
Nothing to modify in lock file
-----
Nothing to install, update or remove
-----
// Check installation destination
$ composer global config home
〜〜〜〜〜
/home/bitnami/.config/composer
-----
// Execute drupal-check
$ /home/bitnami/.config/composer/vendor/bin/drupal-check .
----- Reference -----
$ drupal-check .
If you want to execute it, add the path.
// Add to $PATH
$ export PATH=‘$PATH:/home/bitnami/.config/composer/vendor/bin’
// Apply the settings
$ source ~/.bashrcResult
The drupal-check settings are now complete.
I will run drupal-check. I ran $ drupal-check . but the process froze halfway through, so I will restart the server on Lightsail to deal with it.
Running drupal-check .
$ drupal-check .
~~~~
$ /home/bitnami/.config/composer/vendor/bin/drupal-check . --memory-limit=1024M
PHP Deprecated: The drupal_root parameter is deprecated. Remove it from your configuration. Drupal Root is discovered automatically. in /home/bitnami/.config/composer/vendor/mglaman/phpstan-drupal/src/Drupal/DrupalAutoloader.php on line 92
Deprecated: The drupal_root parameter is deprecated. Remove it from your configuration. Drupal Root is discovered automatically. in /home/bitnami/.config/composer/vendor/mglaman/phpstan-drupal/src/Drupal/DrupalAutoloader.php on line 92
260/26805 [░░░░░░░░░░░░░ ░░░░░░░░░░░░░░░] 0%
// Freeze here
Because of this state, check the Lightsail control panel.
// CPU load is over 60%.
// The public site has stopped working.
// Restart the site in the Lightsail control panel to fix the problemResult
We will not use drupal-check because it puts a heavy load on the server.
The drupal-check . process is too heavy for the production environment, so we will abandon its use.
Check the current situation where the update failed.
I'll try updating again.
// Clear the cache
$ drush cr
// Clear Composer's cache
$ sudo composer clear-cache
// Try updating again.
$ sudo composer update ‘drupal/core-*’ --with-all-dependencies
-----
Gathering patches for root package.
Loading composer repositories with package information
Updating dependencies
Nothing to modify in lock file
Writing lock file
Installing dependencies from lock file (including require-dev)
Nothing to install, update or remove
Generating autoload files
46 packages you are using are looking for funding.
Use the composer fund command to find out more!
No security vulnerability advisories found.
-----
// Nothing to modify in lock file / Nothing to install, update or remove.Result
It is displayed as the latest version, so it cannot be updated. In the administration screen, it is displayed as Drupal 10.3.10.
Let's check the settings.
Check composer.json and update again
// composer.json
‘require’: {
‘composer/installers’: ‘^2.0’,
‘drupal/bootstrap5’: ‘^4.0’,
‘drupal/captcha’: ‘^2.0’,
‘drupal/core-composer-scaffold’: ‘^10.3’,
‘drupal/core-project-message’: ‘^10.3’,
‘drupal/core-recommended’: ‘^10.3’,
‘drupal/core-vendor-hardening’: ‘^10.3’,
----- The rest is omitted -----
// Just in case, change ‘^10.3’ to ‘^10.4’
‘require’: {
‘composer/installers’: ‘^2.0’,
‘drupal/bootstrap5’: ‘^4.0’,
‘drupal/captcha’: ‘^2.0’,
‘drupal/core-composer-scaffold’: ‘^10.4’,
‘drupal/core-project-message’: ‘^10.4’,
‘drupal/core-recommended’: ‘^10.4’,
‘drupal/core-vendor-hardening’: ‘^10.4’,
----- The rest is omitted -----
// Let's try updating by specifying the version.
$ sudo composer require drupal/core-recommended:10.4.0 drupal/core-composer-scaffold:10.4.0 drupal/core-project-message:10.4.0 drupal/core-vendor-hardening:10.4.0 --update-with-all-dependencies
-----
Nothing to modify in lock file
Nothing to install, update or remove
-----
// Nothing to modify in lock file / Nothing to install, update or remove. It did not update.Result
It says it is the latest version and I cannot update it.
There is a possibility that there is a version restriction in composer.lock, so delete composer.lock and run composer update again.
Delete composer.lock and run composer update again.
// Delete composer.lock
$ sudo rm composer.lock
// Update again
$ sudo composer update
-----
Loading composer repositories with package information
Updating dependencies
Lock file operations: 99 installs, 0 updates, 0 removals
----- Omitted -----
- Locking drupal/core (10.4.0)
- Locking drupal/core-composer-scaffold (10.4.0)
- Locking drupal/core-project-message (10.4.0)
- Locking drupal/core-recommended (10.4.0)
- Locking drupal/core-vendor-hardening (10.4.0)
----- Omitted -----
-----
// composer update completed successfullyResult
composer update was successfully executed and the drupal/core-related package was updated to 10.4.0. When you check the admin screen in this state, it still displays Drupal 10.3.10.
Let's check the version using Composer and Drush.
Check the version
// Clear the cache and update the DB.
$ sudo drush cr
$ sudo drush updatedb
// Check to see if the version has been updated.
$ composer show drupal/core
-----
composer show drupal/core
name : drupal/core
descrip. : Drupal is an open source content management platform powering millions of websites and applications.
keywords :
versions : * 10.4.0
released : 2024-12-17, this week
type : drupal-core
----- Omitted -----
-----
// The version of drupal/core has been updated to 10.4.0.
// Check with drush st
$ drush st
-----
Drupal version : 10.3.10
Site URI : http://default
DB driver : mysql
DB hostname : 127.0.0.1
-----
// The version of drupal/core is still 10.3.10.Result
The Drupal version is 10.3.10. This information does not match the version 10.4.0 confirmed on composer.
Check that the core directory you are actually referring to has the correct version. Use the following command to check the contents of the CHANGELOG.txt file in the core directory.
Check the Core directory
$ head -n 10 /opt/bitnami/drupal/core/CHANGELOG.txt
-----
New minor (feature) releases of Drupal are released every six months and
patch (bugfix) releases are released every month. More information on the
Drupal release cycle: https://www.drupal.org/core/release-cycle-overview
* For a full list of fixes in the latest release, visit:
https://www.drupal.org/latest-release
* API change records for Drupal core:
https://www.drupal.org/list-changes/drupal
-----
// Drupal version information is not displayed.Result
As no specific version information is displayed, it is possible that the /opt/bitnami/drupal/core directory has not been updated correctly. The composer output shows that it has been updated to 10.4.0, so there is a discrepancy in the code base.
Let's check the Drupal Core directory.
Checking the version of the Core directory
// Checking the core directory
$ ls -l /opt/bitnami/drupal/core
total 764
drwxr-xr-x 5 root root 4096 Nov 22 12:51 assets
-rw-r--r-- 1 root root 7243 Nov 22 12:51 authorize.php
-rw-r--r-- 1 root root 399 Nov 22 12:51 CHANGELOG.txt
-rw-r--r-- 1 root root 7077 Nov 22 12:51 composer.json
// It is assumed to be 10.3.10 from Nov 22.
// Check the original file
$ ls -l /opt/bitnami/drupal/vendor/drupal/core
total 780
drwxr-xr-x 5 root root 4096 Dec 17 22:18 assets
-rw-r--r-- 1 root root 7243 Dec 17 22:18 authorize.php
-rw-r--r-- 1 root root 399 Dec 17 22:18 CHANGELOG.txt
-rw-r--r-- 1 root root 7077 Dec 17 22:18 composer.json
// It is assumed to be 10.4.0 from Dec 17.Result
You can see that /opt/bitnami/drupal/core is 10.3.10 from Nov22, and /opt/bitnami/drupal/vendor/drupal/core is 10.4.0 from Dec17.
Because /opt/bitnami/drupal/core is holding old files, Drupal is referring to old code, and it is thought that the correct version is not being reflected in the administration screen or Drush.
Delete /opt/bitnami/drupal/core and create a symbolic link so that it refers to the correct code (vendor/drupal/core).
Rebuild /opt/bitnami/drupal/core
// Delete opt/bitnami/drupal/core
$ sudo rm -rf /opt/bitnami/drupal/core
// Create a symbolic link to refer to vendor/drupal/core.
sudo ln -s /opt/bitnami/drupal/vendor/drupal/core /opt/bitnami/drupal/core
// Clear the cache
$ drush cr
// Update the DB
$ drush updatedb
-----
Module Update ID Type Description
-------- ----------- --------------- -------------------------------------
system 10400 hook_update_n 10400 - Equivalent update to 11102.
-------- ----------- --------------- -------------------------------------
┌ Do you wish to run the specified pending updates? ───────┐
│ Yes │
└──────────────────────────────────────────────────────────┘
> [notice] Update started: system_update_10400
> [notice] Update completed: system_update_10400
[success] Finished performing updates.
-----
// The DB has been updated to 10.4.0.
// Restart the web server to apply the changes.
$ sudo /opt/bitnami/ctlscript.sh restart
Restarting services..
Result
Once the restart is complete and the terminal is connected, use drush to check the version.
Check the version of Drupal.
Checking the version of Drupal
// Check the Drupal version.
$ drush st
-----
[warning] Undefined array key ‘bootstrap5’ ThemeHandler.php:74
Drupal version : 10.4.0
Site URI : http://default
DB driver : mysql
DB hostname : 127.0.0.1
----- Omitted -----
-----
// The update was completed, but the following error occurred.
[warning] Undefined array key ‘bootstrap5’ ThemeHandler.php:74Result
It has been updated to Drupal 10.4.0.
[warning] Undefined array key "bootstrap5" ThemeHandler.php:74
There is an error with Bootstrap 5.
The update from Drupal 10.3.10 > 10.4.0 has been completed, but there is a Bootstrap5 error on the terminal, and when I check the page, I get an HTTP ERROR 500 and the public pages and admin screen are no longer displayed. I will resolve the HTTP ERROR 500.
[warning] Undefined array key "bootstrap5" ThemeHandler.php:74
Check the Apache error log.
Checking Apache's error log
// Apache error log
$ tail -n 50 /opt/bitnami/apache2/logs/error_log
-----
[Fri Dec 20 06:18:57.726988 2024] [authz_core:error] [pid 1054:tid 1139] [ client 123.123.123.123:37826] AH01630: client denied by server configuration: /opt/bitnami/drupal/vendor/phpunit
----- The rest is omitted -----
Got error ‘PHP message: PHP Warning: require_once(/opt/bitnami/drupal/vendor/drupal/autoload.php): Failed to open stream: No such file or directory in /opt/bitnami/drupal/vendor/drupal/core/install.php on line 38; PHP message: PHP Fatal error: Uncaught Error: Failed opening required ’/opt/bitnami/drupal /vendor/drupal/autoload.php‘ (include_path=’.:/opt/bitnami/php/lib/php') in /opt/bitnami/drupal/vendor/drupal/core/install.php:38 Stack trace: #0 {main} thrown in /opt/bitnami/drupal/vendor/drupal/core/install.php on line 38
-----
// PHP Fatal error: Uncaught Error: Failed opening required ‘/opt/bitnami/drupal/vendor/drupal/autoload.php’ (include_path=‘.:/opt/bitnami/php/lib/php’) in /opt/bitnami/drupal/vendor/drupal/core/install.php:38 Stack trace: #0 {main} thrown in Result
There is a fatal error because /opt/bitnami/drupal/vendor/drupal/autoload.php cannot be found.
autoload.php is missing
- There is a possibility that the dependencies have not been installed correctly with composer.
- There is a possibility that the vendor directory is incomplete or damaged.
The vendor directory will be completely regenerated.
Regenerate the Vender directory
// Delete the vender directory
$ sudo rm -rf vendor
// Reinstall dependencies
$ sudo composer install
-----
Installing dependencies from lock file (including require-dev)
Verifying lock file contents can be installed on current platform.
Package operations: 99 installs, 0 updates, 0 removals
- Downloading composer/installers (v2.3.0)
- Downloading drupal/core-composer-scaffold (10.4.0)
----- Omitted -----
-----
// Clear cache
$ drush cr
// HTTP 500 ERROR has been resolved.Result
The HTTP 500 ERROR disappeared and the public site and admin screen were displayed successfully.
The Bootstrap 5 error was repaired by regenerating the Vender directory, and the HTTP 500 ERROR no longer appears, and the public site and admin screen are now displayed without problems.
The following error appears when $ drush cr is run, and the admin screen report also shows an error that the entity and field definitions are inconsistent.
$ Errors displayed by drush cr
$ drush cr
-----
[warning] include_once(/opt/bitnami/drupal/vendor/drupal/core/modules/announcements_feed/announcements_feed.module): Failed to open stream: No such file or directory Extension.php:153
[warning] include_once(): Failed opening ‘/opt/bitnami/drupal/vendor/drupal/core/modules/announcements_feed/announcements_feed.module’ for inclusion (include_path='/opt/bitnami/drupal/vendor/pear/pe ar_exception:/opt/bitnami/drupal/vendor/pear/console_getopt:/opt/bitnami/drupal/vendor/pear/pear-core-minimal/src:/opt/bitnami/drupal/vendor/pear/archive_tar:.:/opt/bitnami/php/lib/php') Extension.php:153
----- The rest is omitted -----
-----Error displayed on the control screen
- Entity field definitions
Entity and field definitions do not match
The following changes were detected in entity type and field definitions. - Custom menu links
Translation source field needs to be uninstalled.
Translation expired field needs to be uninstalled.
Translation contributor field needs to be uninstalled.
Translation status field needs to be uninstalled.
Translation creation date field needs to be uninstalled.
The following is omitted
The above error is displayed when a mismatch between entity and field definitions is detected, and usually occurs when fields related to translation are not required or have been incorrectly set.
- This may be due to changes in the translation module (content_translation or interface_translation) settings or uninstallation.
- Entity and field definitions were changed during the update, but they have not been applied to the database.
- This message is displayed when unnecessary translation fields remain in the system.
To fix the discrepancy, run the following command.
$ drush entup
This command executes ‘entity update’ and deletes or applies unnecessary fields and entities.
Fixing the definition discrepancy
// Update entities
$ drush entup
Command ‘entup’ is not defined.
The command is not available. // Currently not available
-----
// Update entities
$ drush entity:updates // Currently not available
The command is not available.
// Available commands are displayed.
Command ‘entity:updates’ is not defined.
Did you mean one of these?
entity-create
entity-delete
entity-save
entity:create
entity:delete
entity:save
locale:update
y:update:key
y:update:value
yaml:update:key
yaml:update:value
-----
// Using locale:update
$ drush local:update
> [notice] ja translation for bootstrap5 was checked.
> [notice] The ja translation for captcha has been confirmed.
> [notice] The ja translation for drupal has been confirmed.
> [notice] The ja translation for easy_breadcrumb has been confirmed.
> [notice] The ja translation for google_tag has been confirmed.
> [notice] The ja translation for metatag has been confirmed.
> [notice] The ja translation for recaptcha has been confirmed.
> [notice] The ja translation for recaptcha_v3 has been confirmed.
> [notice] The ja translation for simple_sitemap has been confirmed.
> [notice] The ja translation for smtp has been confirmed.
> [notice] The ja translation for token has been confirmed.
// Fix for definition mismatch complete
-----
// Clear cache
$ drush cr
Result
The error display has disappeared from the terminal. The error display on the administration screen has also disappeared.
This has become a very long post, but the Drupal Core has been successfully updated to 10.4.0, and the module and theme dependencies are also working without any problems. This time, the main cause of the time taken to repair the error was that the PHP memory limit was set to 256MB, so the 10.4.0 update timed out partway through, and the update was performed in an incomplete state, which took time to repair the dependencies and incomplete state of the directories.
It was careless of me not to notice that the PHP memory limit was 256MB because the addition and updating of modules had been working without a problem until now. I feel that it was good that I was able to reconfirm the operating conditions of Drupal as a result of the problems with this update.
When Drupal Core was upgraded to a minor version, we unexpectedly struggled with updating the system without meeting the system requirements. In the process of fixing the errors, we were able to use composer and drush, which we had only used previously for specific commands, to fix the errors, and this ultimately led to us understanding Drupal's structure.
I am not an engineer myself and have almost no programming knowledge, but fixing the errors this time has also been a good opportunity to reaffirm that Drupal is a CMS that uses PHP and a database.
Until now, I had never encountered any major errors, so I had a kind of absolute belief in the stability of Drupal, but this experience has taught me that if you use it incorrectly, you will have a hard time fixing the errors.
This error has made me reaffirm the importance of staging, and I have decided to make it a habit to thoroughly test the local environment before making changes to the public site using the local environment installed on my MacBook.
As a side note, when I was investigating the error this time, I looked at Drupal.org and saw that the site design had been updated, and I had the opportunity to try out Drupal-CMS, which is due to be released in January 2015. I installed the Drupal-CMS test version on my MacBook and installed the Bootstrap5 theme and got it working.
In the near future, we are considering moving from Lightsail to EC2, but we would like to actively use Drupal 11.1x and Drupal-CMS to embody the evolution of Drupal.
I took the opportunity of updating to 10.4.0 to change the site design. The changes are minor, such as the colour scheme, the way the components and tags are spaced, and the font selection. Next time, I'll try to summarise the design changes.
