Skip to main content

For non-Japanese speakers

All the articles and content on this website are written in Japanese.

If you would like to read them in a different language, please use the translation function on your browser.You may not be able to understand the finer points of the text, but you should be able to get the general idea.

Notice

Xserverの新サーバーがMariaDB 10.11.xに対応したことで、サーバー移転と、Drupal 11.xにアップデートしました。

記事が長くなりましたので、2回に分けています。

  1. サーバー移転と環境整備、移転で出た不具合の修正
  2. Drupal 10.6.8 >>> Drupal 11.3.9 へのアップデート

Drupal Core 11.x

当Webサイトは、Xserverビジネススタンダード上で運営しています。これまで、Drupal10.x系で運営をしてきたのは、XserverビジネススタンダードのDBのバージョンによる制約からDrupal11.xの稼働条件を満たしていない事が理由になります。

Drupal 11.xの最低稼働条件に「PHP8.3以上 」、 DBが「MriaDB10.6以上」の条件があります。Xserverで使用出来るPHPは安定版として8.3.30がデフォルトになっています。ユーザー側でのトラブル対応が条件ではありますがPHP8.4やPHP8.5も選択出来ます。

PHPのバージョンは対応していましたが、DBがMariaDBは10.5.xより新しいバージョンに対応していなかったので、Drupal 11.x系の動作条件を満たしていなかったことから、これまで稼働条件を満たしている、Drupal 10.x系で運営しています。

先日、Drupal Coreのアップデート通知が来ていたので、最新版であるDrupal 10.6.8にアップデートしています。Drupal10.xのセキュリティサポートも期限が見えているので、11.xへのアップデートを考えていました。

Drupal 10.x系のサポートは2026年12月で終了します。

Drupal 11.x系のサポートは2028年までありますので、今年中にはDrupal 11.x系へのアップデートを考えており、Xserverビジネスの対応が難しいようであれば、XserverのVPSにシステムを載せ替えようと考えていました。

そんな中、使用中のXserverビジネスが新サーバーに移転を行うことで、Drupal 11.x系の動作環境に対応したことで、新サーバーに移転を行い、Drupal 11.xにアップデートしました。

Xserverビジネスプラン

2026年5月11日より、新サーバーの稼働がアナウンスされ、機能説明の中に、MariaDB10.11系へのアップデートが記載されています。ただ、新規申し込みの適用なので、現在稼働中のサーバーには該当していません。

詳しく、説明を見ると、過去に契約したサーバーの今後のアップデートと、アップデートに対応が難しい契約から年数を経たサーバーに関してはサーバー移行にて対応しています。

私の、契約サーバーも移行サービスに対応していることがわかります。早速移行手順を調べ、移行への段取りをします。

新サーバー簡単移行

Xserverの特徴に、様々な機能をプログラムを意識することなく使用できます。代表的な機能にWordPress簡単セットアップの機能などがあり、技術者のような専門知識がなくても、簡単な操作でサーバー上にWordPressをインストールして運営出来ます。

今回、サーバーを移転しなければいけないので、結構大変かと考えていたのですが、Xserverが用意する、新サーバー簡単移行のチュートリアルを読むと、非常に簡単にサーバーが移行出来ます。

[ Xserver 新サーバー移行手順(Opens in a new tab/window) ]

AWSなどは、大規模な機能のアップデートを行う際、旧インスタンスと新インスタンスを並行で動かし、丸々載せ替えを行い、最後は、DNSで静的IPを変更して、運営するサービスを停止せずにシステムの載せ替えが可能になっています。

簡単に言えば、旧サーバーから新サーバーに丸コピーを行い、並行で動かしながら、新サーバーの準備が出来たら切り替えるというプロセスが柔軟に出来ます。

AWSの場合、対象が、大規模なシステムなので、知識や経験のある技術者が行う事が多く、システム移行のリスクを踏まえ、リスクを回避した形で移行を行います。

Xserverのサーバー移行のプロセスも、AWS同様、基本は丸々コピーで、コピー元とコピー先のバージョンによる依存関係をある程度Xserverが精査していますので、システム上、難しい場合は移行不可であり、基本的な諸問題をクリアされているケースは、移行がOKとなっています。

AWSのケースと異なり、移行に関わる調査や段取りを、ユーザーではなく、Xserver側がある程度組んでくれているので、作業は非常に簡単です。ただ、Xserverの簡単移行は、システム上一般的な依存確認になるので、移行後に不具合が出る可能性はゼロではありません。

簡単移行でほとんどの移行は完了しますが、サーバー名が変更になるので、使用メールソフトの送受信サーバーの再設定は必須であり、FTPや、SSHの設定の見直しなども行う必要があります。

特殊なプログラムを組んでいたりすると動作が保証されていませんので、その辺りの確認もユーザーが行う必要があります。

実際の移行

私のケースでは、WordPressが3サイト、Drupalが1サイトと小規模なので、それほど大変ではないと考え、トラブルが出てもある程度は対応可能と考えた事があります。

また、移行後深刻なトラブルが発生し、修復不可能になった場合でも、14日間は、元の旧サーバーに戻せますので、なんとかなるだろうと考え、移行に踏み切ります。

移行の手順

  1. Xserverの管理コンソールにログインして”新サーバー簡単移行”をクリックします
  2. 最新サーバー環境への移行を希望するサーバーの一覧が表示されるので”選択する”をクリックします。
  3. データコピー申請をクリックします。
  4. データコピー中と表示されます。数時間程度かかりますので、そのまま待てばOKです。
  5. データコピーが完了すると、データコピー完了と表示されます。
  6. この時点では、旧サーバーが稼働しています。新サーバーの動作確認を行います。
  7. [ 動作確認方法 Xserver(Opens in a new tab/window) ]
  8. 動作確認を行い問題なければ”サーバー切り替え”をクリックします。
  9. 切り替え可否の確認が出ますので、問題なければ”サーバー切り替えをする”をクリックします。
  10. ”サーバー切り替えが完了しました。”と表示されるとサーバー切り替えは完了しています。
  11. 詳しくは [ Xserver 新サーバー移行手順(Opens in a new tab/window) ] を参照ください。

移行完了後の確認

移行が完了するとサーバーが変わります。

DNSの反映に数時間程度かかります。私のケースは2時間くらいで反映されました。DNSに反映されるまでDNS設定のAレコードにエラーが出ますが、DNS反映後に消えますので、心配はいりません。

  1. es123.xbiz.ne.jpのように旧サーバーの英字2桁から始まる3桁の数字が変更になります。
  2. サーバー変更によりサーバーのIPアドレスも変更になります。
  3. サーバーID : xb123456 xb数字6桁は変更されません。

確認は、Webサイトの表示状況、WordPressの管理画面、Drupalの管理画面など、Web上の表示やWeb上のプログラムで動いているサイトにエラーがないかの確認をします。

  • Drupalはレポート > サイトの状態にMariaDB10.11.15と表示されていれば、新サーバーに移行されています。
  • WordPressはサイトヘルスでサイトヘルス > 情報 > データベースにMariaDB10.11.15と表示されていれば新サーバーに移行されています。

メール設定は、送受信のサーバー名が変わりますので、設定を変更する必要があります。

sFTPソフトやSSHの確認も行いますが、ログインはサーバー名ではなく、サーバーIDを使用しているので、最初のログイン時に確認メッセージが表示（認証鍵の確認）されますが、OKでそのまま利用できます。

アップデートの確認

サーバー移行が完了し、動作や運営に問題がないので、Drupalを10.6.8から11.3.9にアップデートします。

composer update --dryrunで確認してみます。

$ composer update --dry-run

Loading composer repositories with package information

Updating dependencies

Your requirements could not be resolved to an installable set of packages.



  Problem 1

    - Root composer.json requires drupal/civictheme ^1.13 -> satisfiable by drupal/civictheme[1.13.0].

    - drupal/civictheme 1.13.0 requires php >=8.3 -> your php version (8.0.30) does not satisfy that requirement.

  Problem 2

    - drupal/core[10.0.0-beta1, ..., 10.6.8] require php >=8.1.0 -> your php version (8.0.30) does not satisfy that requirement.

    - drupal/core[11.0.0-beta1, ..., 11.3.9] require php >=8.3.0 -> your php version (8.0.30) does not satisfy that requirement.

    - drupal/recaptcha 3.4.0 requires drupal/core ^10 || ^11 -> satisfiable by drupal/core[10.0.0-beta1, ..., 10.6.8, 11.0.0-beta1, ..., 11.3.9].

    - Root composer.json requires drupal/recaptcha ^3.4 -> satisfiable by drupal/recaptcha[3.4.0].



Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.

Problemの内容を見るとPHPのバージョンがPHP8.0.30になっています。念の為、Drupal管理コンソールでPHPのバージョンを確認しますが、PHP8.3.7となっています。

このケース、初めてXserverのビジネスにDrupalをインストールした時に遭遇した覚えがあります。

Xserverなど、国内のホスティングは、管理コンソールからPHPのバージョンを設定できるのですが、システム領域においてバージョンの異なる安定版のPHPで動かしています。

  • システム領域 home/ php8.0.3.
  • Web領域 home/public_html /php8.3.7

XserverビジネスはWeb領域とシステム領域で異なるPHPのバージョンを使っていたので、シンボリックリンクでシステム上のPHPを指定してDrupalに対応可能なPHPを呼び出して動かしていた事を思い出します。

SSHでComposerやdrushを使うので、Web上だけでなくシステム領域で指定のPHPバージョンを使用できないと不都合なので、シンボリックリンクでDrupalに対応しているPHPのバージョンを使用可能にしています。

今回の移転は、サーバー丸コピーなので、旧サーバーのデフォルト状態であり当時の安定バージョンであるPHP8.0.30が標準のPHPバージョンとしてコピーされてしまい、移転で指定していたシンボリックリンクが破損していた為に起きた現象である事が推測されます。

旧サーバーでDrupalを動かす為に、以下のPHPのバージョン切り替えを行なっています。

  1. Xserverのサーバー管理にログインしPHP.ver切り替えでphp 8.3.7を選択します。
  2. php -vでphpのバージョン確認　もし変更されていなかったらパスの問題を疑う
  3. find /opt/php-*/bin -type f -name 'php'　利用可能なPHPを確認
  4. $ mkdir $HOME/bin　バイナリーフォルダ作成
  5. $ ln -s /opt/php-8.3.7/bin/php $HOME/bin/php　作成フォルダからシンボリックリンク
  6. $ vi $HOME/.bashrc　.bashrcのパスを書く
  7. export PATH=$HOME/bin:$PATH　これを記述
  8. $ source ~/.bashrc  設定の更新
  9. php --version　バージョンが指定のものに変わったかの確認

.bashrcのexport PATH=$HOME/bin:$PATH記述は残っています。

設定していたシンボリックリンクが動いていないので再度設定します。

シンボリックリンクの修復

PHPとDrushのシンボリックリンクの修復を行います。

PHPの修復

PHP8.3.7にシンボリックリンクを貼ります。

$ ln -s /opt/php-8.3.7/bin/php $HOME/bin/php

$ source ~/.bashrc

$ php -v

PHP Warning:  Version warning: Imagick was compiled against ImageMagick version 1692 but version 1693 is loaded. Imagick will run but may behave surprisingly in Unknown on line 0

PHP 8.3.7 (cli) (built: May 20 2024 12:36:36) (NTS)

Copyright (c) The PHP Group

Zend Engine v4.3.7, Copyright (c) Zend Technologies

PHP8.3.7になりました。

Imagick に関する Warning が出ていますが、これは Xserver 側のライブラリの微細なバージョン不一致によるもので、Drupal の動作や PHP の実行自体に致命的な影響はありません。

セキュリティパッチや細かなバグ修正が含まれた安定版である8.3.30 にしておくのが安全なので、PHPのバージョンを8.3.30にします。

利用可能なPHPを確認します。

$ find /opt/php-*/bin -type f -name 'php'

/opt/php-5.1.6/bin/php
/opt/php-5.3.29/bin/php
/opt/php-5.4.45-sys/bin/php
~~~~~~~~~   >>   中略
/opt/php-7.4/bin/php
~~~~~~~~~   >>   中略
/opt/php-8.0.30/bin/php
/opt/php-8.0/bin/php
/opt/php-8.1.22/bin/php
/opt/php-8.1.29/bin/php
/opt/php-8.1.32-2/bin/php
/opt/php-8.1.34/bin/php
/opt/php-8.1/bin/php
/opt/php-8.2.22/bin/php
/opt/php-8.2.28-2/bin/php
/opt/php-8.2.30/bin/php
/opt/php-8.2.9/bin/php
/opt/php-8.2/bin/php
/opt/php-8.3.10/bin/php
/opt/php-8.3.21/bin/php
/opt/php-8.3.30/bin/php    >>   安定版
/opt/php-8.3.7/bin/php
/opt/php-8.3/bin/php
/opt/php-8.4.12/bin/php
/opt/php-8.4.19/bin/php
/opt/php-8.4.20/bin/php
/opt/php-8.4/bin/php
/opt/php-8.5.1/bin/php
/opt/php-8.5.2/bin/php
/opt/php-8.5.4/bin/php
/opt/php-8.5.5/bin/php
/opt/php-8.5/bin/php

PHPのバージョンは5.x系、7.x系、8.x系が用意されています。Xserverが推奨する安定版である8.3.30もありますので、シンボリックリンクを8.3.7 >> 8.3.30に変更します。

$ rm $HOME/bin/php
$ ln -s /opt/php-8.3.30/bin/php $HOME/bin/php
$ source ~/.bashrc
$ php -v
PHP 8.3.30 (cli) (built: Mar 24 2026 11:28:58) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.3.30, Copyright (c) Zend Technologies

PHPが安定バージョンである8.3.30になりました。

Drushの修復

Drushの不具合を修正します。

$ drush updatedb

PHP Warning:  Version warning: Imagick was compiled against ImageMagick version 1692 but version 1693 is loaded. Imagick will run but may behave surprisingly in Unknown on line 0

The Drush launcher could not find a local Drush in your Drupal site.

Please add Drush with Composer to your project.

...

ImagickのWarningはPHPのバージョンを8.3.30にしていますので解決しています。

「The Drush launcher could not find a local Drush in your Drupal site.」のメッセージは「Drush Launcher（サーバー全体に入っている古いDrush起動ツール）」が、プロジェクト内のDrush を見つけられていない状態です。

Drushのシンボリックリンクを確認します。

$ find $HOME -name drush -type f -executable
/home/.../drupal.hooked-on01.com/recommended-project/vendor/bin/drush
/home/.../drupal.hooked-on01.com/recommended-project/vendor/drush/drush/drush
/home/.../bin/drush

drush の動かない原因は、一番下の /home/.../bin/drush が「古いパス」を指したままの壊れたリンク（または古い実体）になっているようです。

home/binを確認してみます。

$ cd bin
$ ls -al

合計 3244
drwxr-xr-x  2 サーバーID members      62  5月 14 19:14 .

drwx-----x 23 サーバーID members    4096  5月 14 15:38 ..

-rwxr-xr-x  1 サーバーID members 2994603  8月 10  2024 composer

-rwxr-xr-x  1 サーバーID members  317929  8月 10  2024 drush

...

-rwxr-xr-x  1 サーバーID members  317929  8月 10  2024 drush

このファイルは、シンボリックリンク（lrwxrwxrwx）ではなく、2024年8月にそこに置かれた 「プログラムの実体（おそらく Drush Launcher の単体バイナリ）」 です。

これの何が問題かというと：

古い PHP を探しに行く: このバイナリは、実行時に内部で /usr/bin/php（つまり 8.0.30）を勝手に見に行ってしまう設定になっている可能性が高いです。

プロジェクトを無視する: 8.3.30 を用意しても、このファイル自体が「2024年当時の古いルール」で動こうとするため、新サーバーの環境と喧嘩してしまいます。

あまり気にしていませんでしたが、XserverにDrupalを初めてインストールした2024年当時、/binにDrushをインストールしたものがそのまま残っていました。

古い、Drushのバイナリーを削除して、新しいシンボリックリンクを貼ることで解決します。

古いDrushのバイナリーを削除
$ rm /home/サーバーID/bin/drush   

$ cd bin

binの確認
$ ls -al 

合計 2932

drwxr-xr-x  2 サーバーID members      45  5月 14 19:28 .

drwx-----x 23 サーバーID members    4096  5月 14 15:38 ..

-rwxr-xr-x  1 サーバーID members 2994603  8月 10  2024 composer

lrwxrwxrwx  1 サーバーID members      23  5月 14 19:14 php -> /opt/php-8.3.30/bin/php


新しいDrushのシンボリックの作成
$ ln -s /home/サーバーID/.../vendor/bin/drush /home/サーバーID/bin/drush

$ source ~/.bashrc

Drushの確認
$ drush --version
Drush Commandline Tool 13.7.3.0

Drushの動作確認
$ drush updatedb
 [success] No pending updates.
$ drush cr
 [success] Cache rebuild complete.

Drushの修復が完了しました。

サーバー側の環境整備完了

サーバー移転にて、不具合が出ていたPHPのバージョンと、Drushの修復が完了しました。

Drupal 11.x系にアップデートする為の条件である。

PHP 8.3.x以上

MariaDB 10.6.x以上

アップデート作業で使うDrushの最新バージョンである

Drush 13.x以上

の条件が整いましたので、Drupal 10.6.8からDrupal 11.3.9にアップデートします。

 

次の記事

Drupal 10.6.8 > Drupal 11.3.9へのアップデート

Xserverの新サーバーへの移転で、Drupal 11.xの動作環境が整いましたので、Drupal 10.6.8 > Drupal 11.3.9へのアップデートを行います。Drupal Coreのメジャーアップデートなので、依存関係を確認してから行います。次回の記事で、Drupal 10.6.8 > Drupal 11.3.9にアップデートするプロセスをまとめます。

前の記事

Private file system is not set.の解消

Drupalのインストール以降、実運営に影響がないため対処は必要ないと考えそのままにしていたエラーがありましたので、今回そのエラーの対応をしてしまいます。対応するエラーは Private file system is not set : プライベートファイルシステムの設定に関わるエラーであり、プライベートファイルシステムが設定されていない事でセキュリティ警告のエラーが出ています。

#D39
  • Drupalの記事
  • 環境構築
Return focus to the top of the page