Windows10 で php のモジュール intl、curl、imagick のロードエラー | WordPressのカスタマイズ

• php8.4 へのバージョンアップにおける Apache の起動不具合
• php8.2、8.3 においての curl のロードエラー
• 拡張モジュール intl のロード
• 拡張モジュール curl のロード
• libeay32.dll と ssleay32.dll はどこから入手した？
• 拡張モジュール imagick のロード
• php8.2 における zip のロード

WordPress サイトヘルスにおいて、1つ以上の推奨モジュールが存在しません

php 8.1 が、まめにバージョンアップされていて、この投稿を書いている時点ですでに 8.1.10 となっている。それに伴って Windows マシン達の php をバージョンアップさせていたわけだけれど、少し気がついたことが。

WordPress のサイトヘルスにおいて、1つ以上の php の推奨モジュールが存在していない、との表示がでている。この件は、少し前に Ubuntu において格闘したばかりのこと。ただ、Windows の場合は、Ubuntu とは異なり、それらの拡張モジュールは php 本体に同梱されているはずなので、php.ini の extension の項目のコメントアウトを取ってあれば、読み込みを設定されているはずなのだけれど・・・。

まぁ、結果を先に書いておくと、intl の場合は、php の本体のフォルダに同梱されている icu*.dll というのが4つほどあり、それを Apache の bin フォルダにコピーする。
curl の方は、これも php の本体のフォルダに同梱されている libcrypto-1_1-x64.dll 、libssl-1_1-x64.dll および libssh2.dll という3つのファイルを同じく Apache の bin フォルダにコピーする。もちろん双方とも php.ini の extension の設定が必須なのは言うまでもない。これでロードされるはず。以下を読む必要はなし。

※2024/12/29 追記

php8.4 へのバージョンアップにおける Apache の起動不具合

そういえば、php を 8.4 へとバージョンアップさせようとした時、Apache が起動する時にエラーが出て、起動しなかったことを思い出した。
新しい php のフォルダにある、icu～75.dll なファイルを４つ、libcrypto-3-x64.dll、libssh2.dll、libssl-3-x64.dll を Apache の bin フォルダへとコピーして、httpd.conf の php のフォルダ設定を変更、そしていざ Apache を起動、と、残念ながら Apache は起動してくれなかった。
と、いっても、php8.4 のファイルをダウンロードした時に、そのファイル名を見て、そうなることは薄々と感じていたことではあったのだけれど。

そのファイル名というのが、Win32-vs17-x64 という文字列を含むもので、vs17 ということで、ピーンときていたわけです。起動できなかった時の、Apache のエラーログを見ても、そこにはしっかりと、
PHP Warning:  ‘C:\\WINDOWS\\SYSTEM32\\VCRUNTIME140.dll’ 14.29 is not compatible with this PHP build ～ とある。

と、いうことで、最新のランタイムをダウンロードして、インストールするだけのこと。これにて Apache は起動してくれるようになり、php 8.4 も各モジュールを含め、問題なく使えるようになったという事でした。

※2024/06/20 追記

php8.2、8.3 においての curl のロードエラー

この下にある ※2024/01/06 追記 の件においては、php の バージョンが 8.2.20、8.3.8 になった時点においても、curl のロードがエラーになってしまう状況を改善できてはいなかった。と、いうか、curl にいたっては、まぁ、自分の使用においては何も問題にはならないことだったようなので、そのまま、あまり気にもせず、放置したままだった。

ただ、この時分になって、そろそろ何か新しい情報でも出てきているのではないかと思い、ネットなどを漁ってみたところ、Github にあるこの情報を見つけることができた。ここね→ https://github.com/php/php-src/issues/12491

そこでのやりとりを見ると、どうも Apache のバージョンが古い事が問題のようだ。ならば、と、さっそく最新バージョンの Apache にアップデートさせた。自分の Apache は、統合環境なんかに入っていたものではなく、Apache 単体をマニュアルにてインストールさせたもの。Apache のバージョンアップは、ややこしそうであるが、それが意外と単純で、単純なゆえにすぐに忘れてしまいそうなので以下にメモしておく。

• Apache Monitor にて稼働している Apache を停止。
• Windows のサービス管理ツールにて、Apache のサービスを無効に設定する。
• 現行の Apache のフォルダをリネームする。e.g. Apache24 -> Apache24_48
• ダウンロードした最新の Apache を旧 Apache と同じフォルダ下に解凍する。
• 新 Apache のフォルダを旧 Apache と同じフォルダ名にリネームする。e.g. Apache24_59 -> Apache24
• httpd.conf や php のモジュールに必要なファイルを新しい方へとコピーする。
• Windows のサービス管理ツールにて、 Apache のサービスを自動に設定し、開始させる。
• Apache Monitor にて Apache をスタートさせる。

ちなみに、稼働していた Apache のバージョンは、2.4.48
この時点での最新のバージョンは、2.4.59

Apache のバージョンアップ自体は、こんな具合でできた。
あと、大事なことは、htdocs フォルダにあるものを新しい Apache の方へとコピー、または移動させなければならない。膨大な量のファイルがあると、コピーさせると時間がかかってしまうので、バックアップとして取っておく必要が無いのなら、移動させてしまった方が全然速くすむ。

で、結果、新しい Apache （ 2.4.59 ）においては curl はエラーが出ることなくロードされるようになった。めでたしっと！

※2024/01/06 追記

php の進化が進み、2024年1月6日の点においては ver. 8.2.14 となっている（ちなみに ver. 8.3.1 もすでにリリースされている）。
確か、8.2.12 にアップデートされた時に、再び curl が読み込み不可となってしまったのだと思う。
libcrypto-*.dll、libssl-*.dll、libssh2.dll に関しては、アップデートされる度にそれらのファイルの更新具合もチェックして入れ替えていたので問題は無いはずだった。

これもいろいろ試してみたけれど、問題解決にはいたらなかった。
そこでふと思いついたのが、curl が正常にロードされていた ver. 8.2.11 に内包されている ext/php_curl.dll を使うってのはどうだろうか！と、いうこと。

結局はこれでなんとか curl は読み込めるようになった。今のところはこのままである。
しかし、この状況は ver. 8.3 でも同様に起きていて、もしや！とは思ったが、こちらは ver. 8.2 の php_curl.dll では解決しない。
で、https://www.php.net/manual/ja/curl.installation.php にあった、Apache の httpd.conf に以下のように記述して必要なファイルを指定してロードさせる方法をやってみたが、やはりだめだった。

LoadFile “C:\Apache24\bin\libssh2.dll”
LoadFile “C:\Apache24\bin\libcrypto-3-x64.dll”
LoadFile “C:\Apache24\bin\libssl-3-x64.dll”

と、いうことで、ver. 8.3 においてはいまだ未解決のままである。また vs16 のインストール具合の問題だったりするのだろうかと思いつつ・・・。

拡張モジュール intl をロードさせる

と、いうことで、まずは intl の件から。
とりあえず、環境はというと。

Windows10 Pro 64bit
Apache2.4.48
php 8.1.10

php 自体のフォルダは C:\server\php81\ というフォルダであり、Windows の環境変数において、すでに path は通してある。で、php.ini の extension=intl はコメントアウトを外してあり、設定有効の状態にある。もちろん、エクステンションフォルダの設定も、extension_dir = “C:\server\php81\ext” としてある。しかし、それでも、intl は読み込まれてはくれないという状況なのである。

intl に関しては 「php.net 国際化関数」にページがある。ここから「インストール設定」→「要件」とリンクをたどっていくと、ICU ライブラリに関して以下のように書いてあるページにたどり着く。

「この拡張モジュールをビルドするには、ICUライブラリのバージョン 4.0.0 以降をインストールする必要があります。 PHP 7.4.0 以降は、ICU 50.1 以降が必要です。
この拡張モジュールは PHP 5.3.0 以降のバージョンに同梱されています。 ・・・」

と、いうことなので、どれどれと php のフォルダを覗いてみると、たしかにそれらしい icu*70.dll と icu がついた dll が4つほど確認できる。ただ、ちょっと疑問が生じる。このフォルダにはパスを通してあるので、このファイルたちが読み込みに必要ならば、アクセスできるはずではなかろうか？と。しかし、結果的に intl は読み込めない状況。

疑問に思いつつも、それでは試しにと、それら icu*70.dll という４つあるファイルを、windows\system32\ のフォルダにコピーしてみた。Apache を再起動してみると、intl は無事、読み込まれるようになったと。まぁ、出来てしまえばなんてことはないことで。php 本体のフォルダにパスを通してあってもだめだということになる。

ちなみに、別の PC にて試してみたところ、icu*.dll を windows\system32\ フォルダではなく、 Apache の bin フォルダにコピーしてみてもロードされた。下の curl の件を考えても、まとめて Apache の bin フォルダにコピーしたほうが面倒がない。

拡張モジュール curl をロードさせる

で、お次は curl の方。
これももちろん、php.ini の extension=curl はコメントアウトを外してあり、設定有効の状態にある。
これも「php.net Client URL Library」から「インストール手順」のページへ進むと、以下のように書いてあるのがすぐに見つかる。

「注意：Win32 ユーザーへの注意
このモジュールを Windows 環境で使用可能とするには、 libeay32.dll および ssleay32.dll、もしくは OpenSSL 1.1 以降では libcrypto-*.dll および libssl-*.dll が PATH の通った場所に存在する必要があります。 また、libssh2.dll も PATH の通った場所になければなりません。 cURL のサイトにある libcurl.dll は不要です。」

で、読み込みエラーとなった時の状況としては、php は随分前のバージョンから動いていたので、すでに libeay32.dll と ssleay32.dll は windows\system32\ フォルダに存在していて、libcrypto-1_1-x64.dll 、libssl-1_1-x64.dll および libssh2.dll はもともと php に同梱されているものなので、パスの通してある php 本体のフォルダ内に存在していたということ。けれど、読み込みでエラーとなってしまう。

結果的には、libcrypto-1_1-x64.dll 、libssl-1_1-x64.dll および libssh2.dll の３つのファイルを Apache の bin フォルダ、C:\Apache24\bin\ に コピーしてみたところ、無事に読み込んでくれるようになった。結果だけ先に書いてしまうと実にあっけなく問題解決したように思えるけれど、この結果を得るまでには相当な紆余曲折があったのは言うまでもない。

実のところ、この時コピーしたのは libssh2.dll だけで、それでやってみたら良い結果がでたのだけれど、よくよく見たら、libcrypto-1_1-x64.dll と libssl-1_1-x64.dll はすでにそのフォルダ内にあったというわけで。たぶん、これは以前に OpenSSL を読み込ませるためにこのフォルダにコピーしたものだと思う。ちなみにバージョンは php 8.1.10 に同梱されている物よりも古く、日付を見てみるとそれは php 8.0 に同梱されていたものだった。それでも動いてはいるけれど、やはりちゃんとバージョンの揃ったものが間違いなく良いので、8.1.10 のものを上書きしておいた。

と、いうことで、このフォルダ C:\Apache24\bin\ から libssh2.dll を削除すると curl が読み込まれなくなるし、libcrypto-1_1-x64.dll と libssl-1_1-x64.dll を削除すると openssl の extension も読み込まれなくなる。なので、これら３つとも必要ということになる。ちなみに上の注意事項に「もしくは」と書いてある通り libcrypto-1_1-x64.dll 、libssl-1_1-x64.dll および libssh2.dll の3つがあれば、openssl も curl もロードされる。下の libeay32.dll と ssleay32.dll はもう必要ない。

libeay32.dll と ssleay32.dll はどこから入手した？

ちなみに、windows\system32\ フォルダに入れてある方の、libeay32.dll と ssleay32.dll は php 8.1 本体には同梱されていない。これはどこから手に入れたものだろうか。自分が以前に残しているメモによれば、Apache 2.4.41 + php 7.3 をインストールした時に、php 7 においては OpenSSL 1.0.2 以降のバージョンが要求されるということなのだが、Apache 2.4 にはそれがなかったので、Shining Light Productions – Win32 OpenSSL から Win64OpenSSL-1_0_2t.exe をダウンロードして入手したものとある。同じApache 2.4 でも php 5 であるなら、平常に OpenSSL が使えるとのことであるとも書いてある。

また、「より新しいバージョンの Win64OpenSSL-1_1_0L.exe も存在したが、こちらはインストールしても肝心のファイルが見当たらなかった。Win64OpenSSL-1_0_2t.exe をインストールするとそのフォルダにある libeay32.dll と ssleay32.dll をパスの通っているディレクトリにコピー。であるが、迷わずwindows の system32 にコピーしたほうが良いようだ。Apache24 の bin フォルダにパスを通してそこにコピーしてみたが、結果はだめだったから。」ともある。

そして、libeay32.dll と ssleay32.dll は、 php の 自分の持っていた 7.1.4 にも入っていたからそれが使えたのかもしれない、と書き残してある。どこかで古いバージョンの php をダウンロードできないものかと、探してみるとここにあった。「windows.php.net – /downloads/releases/archives/」。そのメモには 7.2.6 にも入っているそうだ、と書いてあるがダウンして中を見てみたが入っていなかった。7.1.4 と 7.1.9 には入っていた。7.1 と 7.2 では vc14 と vc15 という違いが有る。ただ、これらのファイルで試したわけではないので、実際に使えるのかどうかはわからない。

拡張モジュール imagick をロードさせる

そして最後に imagick。
これ、いろいろとネットを探し回っていると、imagick が使えない場合は gd を代わりに使ってるとのこと。imagick の方が高機能で画質的にも良いと言われているいうことで、比較検証してくれているサイトもいくつか見ることが出来るのだけれど、結果的に大差無いよう。圧縮率や処理速度的にも gd の方が上手のようであるし、そうなるとあえて imagick を使えるようにする必要もなさそうである。
と、いいつつも、とりあえず一度は使えるようにしておこうかと。

これに関しても php.net にページがある。「php.net – 画像処理 (ImageMagick)」。ここから「要件」のページへと進むと、その下の方に 「installation instruction」としてリンクがあって、そのページを参考にしてやってみた。「mlocati.github.io – Install the ImageMagick PHP extension in Windows」。
このページにあるリンクからダウンロードする。自分の場合は、thread-safe の php_imagick-3.7.0-8.1-ts-vs16-x64.zip をダウンした。

いつも、ダウンロードする時は、そのサイトが大丈夫なところだろうかと不安になるが、この場合のダウンロード元は、「windows.php.net – /downloads/pecl/releases/imagick/3.7.0/」なので、まぁ、大丈夫ではないだろうか。

手順は他とだいたい同じ。ファイルを解凍したら、php_imagick.dll を php 本体のフォルダにある ext フォルダにコピー。php.ini に extension=imagick を追加。しかし、これもやはりこれだけではロードされない。imagick を解凍したフォルダの直下にある全ての dll（ php_imagick.dll を除く ）ファイルを php 本体のルートフォルダ（ php.exe のある）、もしくは、パスの通してあるフォルダにコピーせよ、とある。

前例もあるので、試しにいろいろやってみた。まずは、imagick を解凍したフォルダにパスを通して、Apache を再起動。予想どおりこれはロードしてはくれない。
すでにパスを通してある、php 本体のフォルダに imagick 関連の dll を全てコピーして Apache を再起動。やはりこれでもロードしてはくれなかった。
ならばと、imagick 関連の dll を Apache の bin フォルダにコピーして再起動させてみると、これでやっとめでたく imagick をロードしてくれた。Apache のエラーログにもないし、phpinfo() でも表示されているし、WordPress のサイトヘルスにおいても、もう、推奨モジュールがないと怒られることもなかった。

まぁ、でも、これは必要ないということなので、あっさりとコピーしたファイルたちを消去して、ロードさせないようにしておいた。Apache の bin フォルダに、ほとんど必要のないファイルがたくさん居座ってるってのもどうも気に入らないしね。