I have installed Drupal CMS on my MacBook Pro. I am using it more for testing the latest technology than for development, and since I haven't touched it for a while, there are a lot of updates pending, so I will proceed with the updates.
My Drupal CMS is running a pre-release version. As mentioned in a previous article, Drupal CMS was released while still under development, so I am using Beta-version modules, which are causing errors and warnings to appear on the admin interface.
To fix these errors and warnings, I have performed actions such as force-deleting modules, leaving my Drupal CMS in a slightly irregular state.
Since Drupal Core was still at version 11.1.5, we will update it to the latest version, Drupal Core 11.2.2. We will perform the update using Composer, but the update stops at Drupal Core 11.1.8 due to dependency issues, preventing further updates to 11.2.0.
The update is restricted due to dependencies with modules that have irregular settings. We will attempt to update the modules causing the issue and repair the dependencies, but the process is currently stuck due to errors.
After researching various options, I decided that a clean installation would be faster and better in the long run than attempting to repair errors or rebuild the system. Therefore, I will delete the currently installed Drupal CMS and install a new one.
My Drupal development environment on my MacBook Pro uses OrbStack and DDEV. This setup allows me to easily add or remove projects, which reaffirmed the benefits of using a Docker environment.
- Recently, I have begun to understand the advantages of virtual environments and containers. It is easy to set up LAMP environments with different specified environments (such as PHP versions and DB versions) that can be easily added or deleted.
- The ability to develop in different specified environments (such as PHP versions and DB versions) is extremely beneficial when building websites for multiple platforms.
I am running Drupal in the following configuration using these two applications.
- Run Orbstack's Linux virtual machine on your local Mac environment, running as a container by default.
- We are installing Drupal by building a LAMP environment (optimised for Drupal) using DDEV on a Linux virtual machine.
Introduction.
It's been a while since I've worked with a local environment, so I've forgotten how to use DDEV, Composer, and Drush. Since the local environment has no SSH administrator permission restrictions for security reasons, most tasks can be completed using Vscord. Being able to check code, confirm file hierarchies, and manage the terminal all in one place is extremely efficient.
As an aside, the Drupal site we have published is managed using the Drupal admin interface and SSH, rather than VsCord+Git. Drupal is a CMS, and most of the editing work is done through the admin interface. Using VsCord for Git management would be cumbersome, so we have opted for this management method.
For tasks such as modifying CSS that require an editor, I use vi from the terminal. While I perform actual work using the terminal, I use an SFTP client (I use Transmit) to quickly check file locations and directory structures. Since I do not have sudo permission except for SSH, I cannot perform SFTP operations, but the advantage of being able to confirm server configurations via GUI is significant.
There are several advantages to using an SFTP client, so I would like to write an article about it when I have the opportunity.
This task
- Update the installed Drupal CMS > The update is not progressing properly, so reinstall > Delete the existing Drupal CMS
Try installing the new Drupal CMS on App > Give up due to problems installing App > Delete Drupal CMS installed on App
- Installing Drupal CMS with DDEV > Checking and responding to errors
1.Deleting Drupal CMS
Due to forced resolution of warnings and errors in development modules, there are dependency issues with the modules used in the Drupal CMS. As a result, the update to Drupal Core 11.2.x series is not proceeding smoothly. Considering future considerations, it seems more appropriate to delete and reinstall the existing Drupal CMS.
Since the Drupal CMS is also managed via DDEV, we will use DDEV to perform the deletion.
Deleting Drupal from DDEV
Deleting a Drupal project in DDEV will delete the web and DB managed by DDEV. After deletion in DDEV, Drupal configuration files will remain in the directory, but if you do not need them, you can delete the directory as well.
// Deleting a DDEV project
---
% ddev delete drupal-cms --omit-snapshot --yes
---
# ddev delete : Deleting a project
# drupal-cms : Project directory
# --omit-snapshot : Database backup
# --yes : Do not confirm deletion
---
// Confirmation of DDEV project
% ddev list
┌──────────┬────────────────────┬────────────┬───────────────────────────┬──────────┐
│ NAME │ STATUS │ LOCATION │ URL │ TYPE │
├──────────┼────────────────────┼────────────┼───────────────────────────┼──────────┤
│ dr-cv-tm │ stopped │ ~/dr-cv-tm │ │ drupal11 │
├──────────┼────────────────────┼────────────┼───────────────────────────┼──────────┤
│ dr103 │ stopped │ ~/dr103 │ │ drupal10 │
├──────────┼────────────────────┼────────────┼───────────────────────────┼──────────┤
│ dr11 │ stopped │ ~/dr11 │ │ drupal11 │
├──────────┼────────────────────┼────────────┼───────────────────────────┼──────────┤
│ Router │ OK │ ~/.ddev │ http://127.0.0.1:10999 │ │
└──────────┴────────────────────┴────────────┴───────────────────────────┴──────────┘
# drupal-cms has been deleted.The project has been deleted from DDEV, so we will now delete the directory. Select the directory in Finder, choose ‘Move to Trash,’ and then empty the Trash to completely delete it. To delete from the command line, use the following command.
# Delete the Drupal CMS directory
% rm -rf drupal-cms
# Please check the path of drupal-cms.2.Installation using Drupal-CMS Desktop App
Drupal CMS can also be installed from desktop apps, so I decided to give it a try this time.
- Download the desktop app (Apple Silicon).
- Unzip the Zip file.
- Move the Desktop app to the Mac application directory.
- Launch the desktop app and install it.
That's all there is to it! Installation is now complete.
After installation is complete, an issue occurs when attempting to log in to the management screen. The specified URL is localhost:8888, but an error is displayed when accessing it in a browser.
The website encountered an unexpected error.
We will check the installation destination to find the cause of the error. We will look in directories such as htdocs where the local Apache path is accessible, but we cannot find the directory where drupal-cms was installed.
I was surprised when I searched for ‘drupal-cms’ in Finder. The installation destination was the Mac Documents directory... This is obviously not acceptable, so I gave up on installing the Drupal-CMS Desktop App for the first time and decided to install it the traditional way using DDEV and Composer.
Since neither the Drupal CMS nor the desktop app installed this time are necessary, we will delete them. There are no particular dependencies, so you can simply select them in Finder and move them to the Trash. However, there is a possibility that MySQL or Apache may still be running, so it is safer to confirm this with the following command before deleting them.
% ps aux | grep drupal
s-takeda 28475 0.0 0.0 410724848 1440 s002 S+ 3:56AM 0:00.00 grep drupal
# Since it is only grep drupal processes, Drupal and MySQL are not running.3.Installing Drupal CMS
I deleted the Drupal CMS I had installed in the past and also deleted the desktop app, so I will install Drupal CMS using DDEV.
Installing DDEV's Drupal CMS
It's been a while since I used DDEV, so I'm going to install Drupal on my MacBook and review how to use DDEV.
In DDEV, projects are organised by directory. Place .ddev in the directory to manage the project.
# Create and move the project directory
% mkdir dcms-01 && cd dcms-01
---
# Set up the project.
% ddev config --project-type=drupal11 --php-version=8.3 --docroot=web
# The project uses Drupal :Drupal11. : --project-type=drupal11
# The PHP version is 8.3 series. : --php-version=8.3
# Set the document root path to the web directory. : --docroot=web
# Normally, you would need to specify the database, but QuickInstall does this by default.
---
# Starting DDEV
% ddev start
---
# Installing Drupal CMS
% ddev composer create-project drupal/cms
# Install using Composer.
---
# Starting and configuring Drupal
% ddev launch
# Drupal CMS starts up, select the type of site (select Blog)
Enter your email address and password to log in to the Drupal CMS administration screen.
---That completes the installation of DDEV's Drupal CMS.
Check installation status
You can check the configuration status with ddev describe. Since this is local, the DB password is db/db and root/root, but please set a User/Pass that cannot be guessed in the production environment.
It consists of web, db, mailpit (useful for testing local form emails), and containers. One of the advantages of Docker is that you can change the PHP version for each project and the DB version.
# Check installation status
% ddev describe
┌─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Project: dcms-01 ~/dcms-01 https://dcms-01.ddev.site │
│ Docker platform: orbstack │
│ Router: traefik │
├──────────────┬──────┬──────────────────────────────────────────────────────────────────────────────┬────────────────────┤
│ SERVICE │ STAT │ URL/PORT │ INFO │
├──────────────┼──────┼──────────────────────────────────────────────────────────────────────────────┼────────────────────┤
│ web │ OK │ https://dcms-01.ddev.site │ drupal11 PHP 8.3 │
│ │ │ InDocker -> Host: │ Server: nginx-fpm │
│ │ │ - web:80 -> 127.0.0.1:32788 │ Docroot: 'web' │
│ │ │ - web:443 -> 127.0.0.1:32789 │ Perf mode: mutagen │
│ │ │ - web:8025 -> 127.0.0.1:32790 │ Node.js: 22 │
├──────────────┼──────┼──────────────────────────────────────────────────────────────────────────────┼────────────────────┤
│ db │ OK │ InDocker -> Host: │ mariadb:10.11 │
│ │ │ - db:3306 -> 127.0.0.1:32791 │ User/Pass: 'db/db' │
│ │ │ │ or 'root/root' │
├──────────────┼──────┼──────────────────────────────────────────────────────────────────────────────┼────────────────────┤
│ Mailpit │ │ Mailpit: https://dcms-01.ddev.site:8026 │ │
│ │ │ Launch: ddev mailpit │ │
├──────────────┼──────┼──────────────────────────────────────────────────────────────────────────────┼────────────────────┤
│ Project URLs │ │ https://dcms-01.ddev.site, https://127.0.0.1:32789, │ │
│ │ │ http://dcms-01.ddev.site, http://127.0.0.1:32788 │ │
└──────────────┴──────┴──────────────────────────────────────────────────────────────────────────────┴────────────────────┘
The language setting is defaulted to English, so I will change it to Japanese.
Installing translations with Drush
The default language setting in /admin/config/regional/language is English, so add Japanese and set it as the default. Even if you specify Japanese here, it will not be reflected immediately, and the administration screen will remain in English. Therefore, we will use Drush to translate everything at once and change the administration screen to Japanese.
# Display projects that require translation updates
% ddev drush locale:check
---
# Download and import translation files
% ddev drush locale:update
---
# Clear cache
% ddev drush cr
--- That completes the conversion of the administration screen from English to Japanese.
Consideration of errors
The Drupal Core installed with this installation is the latest Drupal Core 11.2.2. The modules are also installed with the latest versions, but some development modules have been installed in the core program, resulting in errors and warnings.
The errors and warnings generated by this development module are officially recognised by Drupal. (You can basically ignore these errors and warnings.) I recently realised that the root cause of the errors and warnings I encountered last time with automatic_updates and package_manager, which I had struggled to resolve, were actually errors and warnings officially recognised by Drupal.
Drupal CMS is evolving from its traditional image as a CMS used by developers to a CMS that can be easily used by general users, similar to WordPress, in order to expand its user base.
The interface has been refined, and it has evolved into a more user-friendly CMS with a GUI that can handle everything instead of a command line, and distributions packaged for specific purposes.
We are currently implementing features that allow users to build and operate websites without having to be aware of the system, such as downloading and automatically installing modules and themes with a single click from the administration screen, similar to WordPress, and automating updates with cron. As a result, we are currently experiencing errors and warnings such as the one mentioned above.
# error
Package Manager
Package Manager is available for early testing. To install the module set the value of 'testing_package_manager' to TRUE in your settings.php file.
# warning
Experimental modules installed
Experimental modules found: Navigation, Package Manager. Experimental modules are provided for testing purposes only. Use at your own risk.
Drupal CMS
By searching for modules and themes in the Project Browser GUI and installing or updating them from the GUI using the Package Manager, you can build an interface similar to that of WordPress themes and plugins.
This has the potential to create a third-party market. Excellent modules and themes may be used even if they are paid, so as development progresses and the number of users increases, a virtuous cycle may be created that will promote the spread of Drupal.
For the developers, they were in the midst of dealing with a development process that was like a birth pang of dealing with an interface that was different from the past, and they happened to encounter the distribution of an experimental module that had been prepared as a response, and when they thought that the end result of trying to force a solution was the error handling that they had struggled with last time, they were convinced that this was the case.This is an event that makes sense.
I myself am impatient and like new things, and my style of operation is to respond immediately to updates, and to deal with problems as soon as possible.This incident made me think that it is necessary to be cautious and take a wait-and-see approach when dealing with major updates such as this one, which can change the system itself.
Change permissions on settings.php
Home > manage > Report > Site status.
Protection disabled.
The file sites/default/settings.php is not protected against modification and is therefore a security risk. Please change the file permissions to write-protected.
As it is local use, it can be basically ignored, but it is a routine part of the Drupal installation, so it is supported.It must be supported in the production environment.
This error is a problem with the permissions on setting.php, as setting.php is set to 644 when Drupal is installed, change the permissions to 444 [read-only].The following command usually solves the problem.
$ cd web
$ chmod 444 sites/default/settings.php
Change as soon as possible.
Changing permissions
Enter the command from iTerm and change the permissions.
Composition of DDEV
DDEV runs in containers.The following is a configuration diagram.
|-ddev-dcms-01
| |-db
| |-web
|
|-ddev-router
| |-ddev-router
|
|-ddev-ssh-agent
|-ddev-ssh-agentThe settings.php to change the permissions to resolve this error is located in the Orbstack container ddev-dcms-o1/web, not in dcms-01/web, which is displayed in the Mac terminal.You need to change the permissions on this settings.php, so you need to connect to the ddev-dcms-01/web container with ssh to change it.The ssh connection to the container is made with the DDEV ssh command.
ssh connection to containers with DDEV
Enter the container via DDEV ssh and change the permissions on settings.php.
# Log in to the container using ddev ssh.
% ddev ssh
---
# Check directory structure
$ cd web/sites/default
$ ls -al
# The permissions for settings.php are read/write.
-rw--r--r--- 1 s-takeda dialout 36727 Dec 7 18:37 settings.php
---
# Change of authorisation.
$ chmod 444 settings.php
# Confirmation of changes.
$ ls -al
// The system has been changed to read-only 444.
-r--r--r-- 1 s-takeda dialout 36727 Jul 4 18:37 settings.php
---
# Clear the cache.
$ drush cr
[success] Cache rebuild complete.
---
# Termination of ssh.
$ exit
---
# Reference When working in a Mac terminal, you need to enter ddev before entering commands due to paths, but in a container you do not need to enter ddev.
# Mac Terminal
% ddev drush cr
# In Orbstack containers
$ drush crThe protection disabled warning was resolved by entering the DDEV container via ssh and changing the permissions on web:/var/www/html/web/sites/default/settings.php from read-write to read-only.
Checking for errors in the Admin console
Home > Manege > Report > Site status.
1 error 1 warning 29 confirmed
1 error, 1 warning, in the development module, but it was updated without problems.
Conclude.
It has been six months since Drupal-CMS was released in December 24.We think that we need to wait a little longer to use it in a production environment.It has evolved in six months from its pre-release status.We thought the management screen with different interfaces was difficult to use at first, but now that we have taken the time to check the placement of each function, the interface is very sophisticated.
I have been using Drupal myself for less than a year and there is still a lot to understand, but there are many advantages of Drupal over WordPress and many things that I feel are right for me.Although this is not a common assessment, the rigour of the structure and the strictness of the rules are the biggest advantages of using Drupal for me.
Stricter structures and stricter rules remind me of PC-UNIX, which was introduced 30 years ago, where UNIX was ported to PCs and actual use became possible, and from there Linux and Free BSD appeared and spread.Looking at the current situation, the spread of Linux is overwhelming and Free BSD has not spread as much as Linux.
At the time, the engineers around me were all using Linux (RedHat systems) and FreeBSD was in the minority.It was natural to use RedHat systems, which had many users, established usage and had consolidated its position as the industry standard, but I preferred FreeBSD.
The reason for this was that the structure and rules were strictly enforced, it was easy to understand what was installed where, and it was easy to use in the application of building a light system (e.g. removing drivers) by thoroughly eliminating unnecessary things from the fragile hardware structure of the time.
The fact that I feel that Drupla's policies are somehow close to the FreeBSD philosophy of the time is the main reason I use Drupal.
We hope that the release of Drupal-CMS will broaden the base of users while making use of the good aspects of Drupal so far.
Tentative) Security management of Dupal.
I will summarise Drupal security management, which I originally intended to summarise in this article.However, as this is a security-related article, I am wondering to what extent I can summarise it as an article.