Drupal - Weekly Maintenance
Every week some time should be dedicated to reviewing the status and general health of Drupal and modules.
Last updated
Was this helpful?
Every week some time should be dedicated to reviewing the status and general health of Drupal and modules.
Last updated
Was this helpful?
It is not necessary to complete all steps each week. In some weeks the module update will consume 100% of the time available, and other weeks there will be no module updates required, or the decision is made not to update any modules this week.
In general, the maintenance process should start with the review of module updates, as this is a cornerstone of any maintenance program and ensures the balance of issues are being addressed on a completely updated site.
There are many ways this task can be effectively completed. This way has the advantage of being responsive and relatively low-burden between cycles.
If the basic parts of this process are not conducted weekly, then to ensure the site is kept up-to-date and is adequately patched, there will be a need for monitoring of Drupal/Acquia channels to determine when various patches are available.
Login to the production website at and then navigate to the available updates report page at . All available updates which managed by composer are listed on this page.
Update Type
Action to take
Security Updates
These should be applied ASAP. Ideally these are deployed as the only change in a new commit.
Normal Updates
It is not necessary to rush these updates and time can be taken to investigate what will be affected and consider if this will affect the website.
Even though these are not important, it is best practice to apply updates as they are ready because not applying may block other updates from happening. It may be convenient to include in the next scheduled deploy.
Following Drupal Best Practices, the downloading and version control of contributed modules (including Drupal core itself) is managed by composer.
Note: Composer is not fully installed on any Acquia server (and does not need to be). Package/Module admin is done by running composer commands locally in development containers.
Compare the version rules in your local composer.json with the versions listed on the in Drupal. If necessary, change rules in composer.json so that the recommended module version will be downloaded.
Run composer update in your local development container.
Check the output of the composer command, and verify that the modules/packages you expect have been added/remove/updated and that patches have been applied without errors. If necessary fix the errors by updating the composer.json file and re-running lando composer update.
If you see this message:
Writing lock file Generating autoload files
In CopyRequest.php line 91:
fopen(/app/docroot/sites/default/default.services.yml): failed to open stream: Permission denied
Then you need to change the permissions on your local (i.e. on your host not in the docker container)docroot/sites/defaultfolder to 777, and then rerun the composer command.
After the update is completed, update the Drupal caches (so that the Drupal registries are updated).
Then, see if the updated modules need to apply any updates to the database. This step is done to ensure that the updates will apply properly on the Acquia servers when the deploy scripts run this command.
[Optional] We can export the configuration. It is unlikely that there will be changes to configuration, but it is theoretically possible, so to be safe this is a recommended step. Take care with this and ensure that any configuration changes are changes you expect. You should expect configuration updates only to .yml files from contributed modules updated by composer during this maintenance cycle.
Finally, commit into the main public d8 repository:
- thecomposer.lock and (if changed) thecomposer.json files -it is very important to include both (see "final note" box-out below), and
- any config files generated from drush cex -these will always be in the /config/default folder.
again, take care to check these over, changes to settings files (in particular) could affect production settings.
SUMMARY: Recommended overall composer strategy:
- Manually maintain the composer.json file locally, and usecomposer update in the local container to update the composer.lock file, then
- Commit and merge both the composer.lock and composer.json files into the main repository, then
- Deploy scripts will execute composer install (on Travis) during the site build process so the exact same versions of all packages are deployed on all Acquia servers.
Navigate to the Drupal 8 Production environment.
Click on the "Insight" menu item to view a list of config setting mods recommended by Acquia. Note: Acquia Insight provides fairly generic best-practice type comments and it may not be appropriate to adopt/change all of the settings recommended - do some research first, and use common sense.
Click on Stack Metrics to view a series of graphs related to resource consumption and basic network performance. Take a look over these, paying particular attention to disk space and memory utilization graphs.
login to http://www.mysiteimprove.com and check the console for any significant/new issues highlighted.
Tip: You can see what changes will actually be made when updating by first running:lando composer update --dry-run
and comparing the output with the to see that the required modules have been added, removed and updated.
(Note: you can expect composer to update a considerable number of modules which are not listed on the status report because composer also checks dependencies and symfony components that Drupal does not)
composer update: [] reads the composer.json file, works out the package versions which meet all rules (and recursive dependencies), compares versions with the existing packages in the local environment and downloads the packages and dependencies which need updating.
Finally, it updates composer.lockwith the exact versions of each package that are currently installed.
composer install: [] reads the composer.lock file, compares to existing packages and downloads those packages and dependencies which need updating.
If there is no composer.lock file found then composer will read the composer.json file and essentially run the composer update process.
After Step 1 has been completed, and all module updates have been applied through to production the can be checked. Pay attention to the Errors and Warnings sections of this report.
Login to the