ラベル PHP8 の投稿を表示しています。 すべての投稿を表示
ラベル PHP8 の投稿を表示しています。 すべての投稿を表示

2025年7月19日土曜日

MAMP 7.2 へのアップグレード（mysql 5.7系→ 8.0系へのアップグレード含む）

macOS の MAMP上で、PHPプログラムで作成したデータベースのテストや、WordPress のいくつかをテストしていることもあり、MAMPもたまにアップグレードしています。

今回は、MAMP 6.8 に php 8.4系と 8.3 系の最新をカスタムインストールしていたものを、MAMP 7.2 へアップグレードする方法を備忘録として残します。

この php バージョンのカスタマイズについては、下記を参考にしてみてください。

動作チェック環境

  • M2 MacBookPro 14inch
  • macOS Sequoia 15.5

STEP 1. 既存のMAMPを退避させる


/Applications/MAMP （Macintosh HD > アプリケーション > MAMP）

について MAMP2 など別の名前に変更します。

＊先に MySQL データを phpmyadmin ツールで、エクスポートしておいてもOKです（WordPressなど）

STEP 2. MAMP 7.2をインストールする


https://www.mamp.info/en/mac/

上記よりダウンロードしてインストールしましょう。

そして一旦動作するかどうか、MAMPを開いてみてください。そして「Start」ボタンを押してエラー無く動作するか確認してください。うまく動いたら「Stop」ボタンを押してサービスを終了したあとで、MAMPを終了してください。

STEP 3. データベースとデータをもとに戻す


/Applications/MAMP （Macintosh HD > アプリケーション > MAMP）

db をdb.org など別名にしてください。
また htdocs も htdocs.org など別名にしてください。

古いMAMPのフォルダから、dbとhtdocs を 新しくインストールした MAMPフォルダのへ移動するかコピーしてください。

/Applications/MAMP2 （Macintosh HD > アプリケーション > MAMP2）

そして db野中に mysql57とsqlite しかない状態であれば、
次に、db.org （新しいMAMPのDB）の中から、mysql8、redis、sasl フォルダーを dbへをコピーしてください。

もし dbや htdocs を Dropbox の領域に移動しており（複数端末で同一DBとデータを使いたいなら）、シンボリックリンクでMAMPと連携させているなら（~/Dropbox/MAMP/db と ~/Dropbox/MAMP/htdocs）
  • ln -s ~/Dropbox/MAMP/db /Applications/MAMP/db 
  • ln -s ~/Dropbox/MAMP/htdocs /Applications/MAMP/htdocs 
とした上でDropbox について、同期を「オフラインのみ」にしている場合には、一旦 Dropbox からサインアウトした上で、再度ログインするときに下記をしてオフライン利用（各端末の ~/Dropbox にデータが完全にダウンロードされて同期する手法）にしてください。
  • 「オンラインのみ」としてファイルを保存（オフにする）
  • 詳細設定にある「File Provider でのDroxbox fro macOS 改訂版を「オプトアウト」：

STEP 4. MAMPを起動する


もし http について 80番ポートを使っているなら、Preferences で 8888ポートから80ポートへ変更してください。
さらに、下記の手法でSSL化しているなら、再度下記の手法でSSL化してください。
また、Preferences の Server にある MySQL は 5.7.44 にしておいてください。




もし MySQL 5.7 系のDBを使っている（WordPress等）のであれば、そのDBをバックアップしておいてください。MAMPでバックアップするなら

https://localhost/MAMP（http://localhost/MAMP　あるいは http://localhost:8888/MAMP など人による） などにアクセスすることで phpmyadmin ツールが使えます。

STEP5. MySQL を 8.0系にする





Preferences の Server より MySQL を 8.0系にします。
MAMPを起動しなおしてください。
そしてサービスを Start としてください。
もし https://localhost がウェブサイトのトップであるなら
https://localhost/MAMPにアクセスし、上部「Tools」より「phpMyAdmin」を開くてください。


「データベース」より以前作成していた（バックアップした）、データベース名と同じデータベースを作成してください。


できたデータベースにアクセスして、「インポート」より、バックアップしたDBデータをインポートしてください。

これで従来アクセスできていた WordPress などにもアクセスできるようになるはずです！



STEP 6. Apacheの mod_rewrite.so モジュールを有効にする


WordPress など mod_rewrite モジュールを使っているサイトの場合、index.php?p=456 などパラメーターではアクセスできるものの、パーマネントによるアクセス（ /index.php/****/ ）はすべて404エラーになることがあります。

これは MAMPの Apacheのデフォルト設定では、rewriteモジュールが無効になっているからです。

/Applications/MAMP/conf/apache/httpd.conf
#LoadModule rewrite_module modules/mod_rewrite.so 
を下記のようにコメントを外しておいてください

LoadModule rewrite_module modules/mod_rewrite.so 



2025年7月19日 @kimipooh
2025年9月3日
 
投稿者 時刻: 0 件のコメント:
ラベル: ,

2025年4月30日水曜日

BackWPUP 5.2 のアップデートした後に WordPress サイトがアクセスできなくなった問題への対処と起こった理由

2025年4月30日、手持ちの WordPress サイトについて「重大なエラー」ということでサイトにアクセスできなくなる問題が発生しました。実際にはキャッシュ系プラグインをいれていたおかげて、本日更新したか（キャッシュ更新した）、最近アクセスしていなかった（キャッシュがない）場合にのみでていたので、気づくのに少し時間がかかりました。

WordPress のデバッグを有効にしてみると、下記のようなエラーが表示されました。
Query Monitor というデバッグ用のプラグインもいれていたので、整理された状態でエラーがでてますね。原因は、「cal_days_in_month」関数が定義されていないよというもの

対処方法


暫定的な対応としては、FTPなどをつかってサーバーにある WordPress フォルダから、 wp-content > plugins に移動して、「backwpup」のフォルダを削除する、ということになります。ようするにプラグインを WordPress から消すということです。

今回の問題が修正されたあとに、改めてBackWPUP プラグインを新規インストールすれば、設定などはデータベース側に残っているのでそのまま使えるでしょう。

あるいは他のプラグインの乗り換えるという手もあります。
また、自前でバックアップシステムを構築可能なら、その方が安全かもしれません。


自前でバックアップシステムを構築する（技術者向け）


サーバーを管理運用している人対象、つまりはサーバーに ssh などでログインして、シェルスクリプトや cron などを使って自動バックアップなどを手掛けたりしているなら、参考になるかなと思います。

WP-CLI を利用したバックアップツールを作成して、下記に置きました。
UNIX系OSのサーバー管理をしているならわかるかなと思います。自由に使ってもらっても構いません。



WordPress には、WP-CLI というコマンドベースでユーザー制御したり、データベースからデータをバックアップしたり、プラグインや本体のアップデートなども可能なツールがあります。プラグインが WP-CLI に対応していれば、コマンドからプラグインの対応している機能を実行できたりします。BackWPUP も対応しており、WP-CLI を通じてバックアップを行うこともできます。

筆者も下記のような感じでバックアップしておりました。

Knowledge for WordPress: 複数サイトのメンテナンスを WP-CLI でやろう！（サーバー管理者編）

こうしたものを使えば

1. WP-CLI をサーバーにインストールする
＊単体で実行可能。レンタルサーバーによっては wp コマンドとして存在する場合もあるがバージョンが古いこともある

2. WordPress のデータベースバックアップ
wp db export --default-character-set=utf8mb4

コマンド（4バイト UTF-8に対応）でSQL形式でバックアップできます。

3. WordPress本体を tar コマンドで tar.gz 形式でバックアップ

これらができれば、プラグインに頼らずともバックアップ可能になります。
ただ古いバックアップを削除するときには、下記のように7日より古いファイルは削除するなどの find コマンドなどの併用利用は必要になってくるでしょう。ただこのあたりはコマンドの意図するところを正しく理解できないなら、使うべきではありません。うっかり本体データごと削除してしまうおそれがあるためです。

find バックアップフォルダ/ -name "backup_*.tar.gz" -type f -mtime +7 -exec rm -f "{}" \;

以下、今回なぜこんなことが起こったのかをまとめておきます。

cal_days_in_month 関数が未定義のためにエラーがでた


PHPの公式ドキュメントによれば、年月をいれるとその月が何日あるのかを調べることができる関数のようですね。

PHP: cal_days_in_month - Manual

特に PHP8など最新版でも動作するようなので、これだけ見ると？？？という感じです。

いずれにせよ関数がないなら、Warningだけにとどめて無視してほしいという気持ちもありますが、それはそれで意図した動作をしないおそれもあるのでエラーで気づかせてくれるというのもまた必要ではあるので難しいところです。


cal_days_in_month 関数は標準で実装されていないかもしれない問題

下記をみると、Windows版 PHP にはこの関数は標準実装されているようですが、Linux OS 等が利用されてることも多い、レンタルサーバーなどでは明示的に別途 PHP を --enable-calendar オプションつきで実装（コンパイル）する必要があるようです。

PHP: Installation - Manual
https://www.php.net/manual/en/calendar.installation.php

手持ちのさくらインターネットのサーバーで、下記のようにテストコードを書いて、phpコマンドから実行すると、

 <?php
ini_set('display_errors', "On");
cal_days_in_month(CAL_GREGORIAN,2,2025);

下記のように関数が定義されていないとエラーになります。

Fatal error: Uncaught Error: Call to undefined function cal_days_in_month() in /home/****/sample.php:4
Stack trace:
#0 {main}
  thrown in /home/***/sample.php on line 4

さくらインターネットのWeb UIから、php.ini において下記を参考に

さくらのレンタルサーバのPHPの環境を確認、整えてみよう | さくらのホームページ教室

extension = calendar.so

をいれてみるも駄目。

phpinfo() コマンドで calendar 系のモジュールが入っているがどうか調べると、一応入っているのは入っているが、この関数が使えるものではなさそう。

% php -r "echo phpinfo();" |grep -i calendar
Calendar => Shane Caraveo, Colin Viebrock, Hartmut Holzgraefe, Wez Furlong

そのため、結局はプラグイン作者側が未定義関数がでそうなものについては、その関数がない場合のエラー処理をしてくれているのがよいということになるなぁという感じです。それ以前に、GitHub Actions 等標準的な環境での PHP Unit Test を開発者側もしてほしいものですね。もし、していても問題が発覚しないならどうしようもないですけれども...

2025年4月30日 @kimipooh


投稿者 時刻: 0 件のコメント:
ラベル: , , ,

2025年3月30日日曜日

GitHub Actions で WordPress の PHPUnit テストをする方法

開発した WordPress プラグインなどを GitHub で公開しているなら、ローカルで PHPUnit テストをするのではなく、GitHub Actions でやりたい！ということはあるかもしれません。ただ、出来た！と思っても、GitHub側のシステム、 WordPress の本体バージョン、PHPのバージョン、MySQLのバージョンなどによって動かなくなることもあります。

そこで、GitHub Actions で WordPress の PHPUnit テストをする方法についてまとめページを作ろうと思いました。

ここでは、 WordPress の PHPUnit のテストが GitHub Actions で動くまでを書きます。2025年3月30日時点では、PHP7.4, 8.0〜8.4までのテストを対象にしています。

なお、ここでの作業のみでは GitHub Actions で WordPress の環境を作って、プラグインを有効化して致命的なエラーなく動作はするまでのテストができるということになります。

もし各プラグイン等でいろいろテストしたい場合の実装は PHP テストの作成（WordPress.org）を参考にしてみてください。

以下は下記の筆者の極めてシンプルなプラグイン（プラグインは WordPress が用意するショートコード一覧を表示する）をベースに説明していきます。

https://github.com/kimipooh/view-shortcodes

検証日：2025年3月30日


STEP 1. GitHub の環境を整える


こちらについては、出来ているものとします。


あたりで GitHub を使えるようにした上で、Sourcetree のような GUI ツールを使うのもありかなと思います。

STEP 2. PHPUnit をインストールする


こちらについても、ローカルではできているものとします。

WordPressでテスト駆動開発(PHPUnit)〜インストール編 | 【新潟】WordPressならminescope

や

https://phpunit.de/getting-started/phpunit-9.html

あたりを参考に Composer を使ったローカルでテスト環境を１つは作成してください。

とりあえず体験してみたい！という場合には、下記を参考にしてみてください。


このあたりがわからない場合


下記より PHPUnit 環境込みのプラグインデータをダウンロードして、

https://github.com/kimipooh/view-shortcodes

自分のプラグインフォルダへ

composer.json
phpunit.xml.dist
phpunit フォルダ
tests フォルダ

をコピーした上で、次に進んでください。


STEP 3. 必要なファイルを用意する



を例にとって説明していきます。
こちらのプラグインは WordPress が用意するショートコード一覧を表示するだけであり、特別なテストは不要です。WordPress 上でプラグインを有効化して致命的なエラーがでなければ良しとしています。

以下、上記のデータをベースに変更箇所についてお伝えします。
すでにローカルでテストされているなら、「１」「２」は不要な場合もあります。
また 「２」「３」については、補足説明します。

1) tests/bootstrap.php 

require dirname( dirname( __FILE__ ) ) . '/view-shortcodes.php';

を
require dirname( dirname( __FILE__ ) ) . '/自分のプラグインのメインファイル名.php';

に置き換える。

2) composer.json

        "name": "kimipooh/view-shortcodes",

        "description": "The plugin is for displaying active shortcodes in the admin main menu.",

を

        "name": "ご自身のGitHubユーザー/自分のプラグインのメインファイル名",

        "description": "自分のプラグインの説明",

に置き換える。

また "authors" にある、下記も変更してください。

                       "name": "自分の名前を入れる",

                       "email": "公開するメールアドレスを入れる"



3) .github/workflows/wordpress.yml（隠しファイル）

name: view-shortcodes plugin test

を

name: 自分のプラグインのメインファイル名 plugin test

に置き換える。


補足説明


直感的にわかりにくいところの説明をします。

composer.json


         "phpunit/phpunit": "^9.5 || ^10.5 | ^11.5 | ^12.0"

上記は PHPUnit テストのどのバージョンを使うかを指定します。複数使いたい場合には || で区切ります。上記のケースでは、 9.5、10.5、11.5、12.0 のそれぞれ最新版を使うということです。11.5.13 などピンポイントで指定することもできます。

PHPUnit として使えるバージョンは、下記のサイトを確認してみてください。

https://phar.phpunit.de/

また PHPUnitのバージョンによっては利用できる PHPバージョンも異なります。

こちらについては下記を参考にしてください。

https://phpunit.de/supported-versions.html

PHP7.4 や 8.0 をテストしたいなら、PHPUnit 9が必要

PHP8.1 なら PHPUnit 10を、PHP8.2 なら PHPUnit 11を、PHP8.3なら PHPUnit 12がサポートしています。ただし。サポートしていなくても動く場合もあります。PHP8.4 については PHPUnit 12で動作しました。

wordpress.yml


こちらについては GitHub Actions のワークフローファイルになります。
拡張子 yml のファイルを .github/workflows/ フォルダ以下にいれることで GitHub Actions で読み込まれます。

参考：GitHub Actions のクイックスタート - GitHub Docs

matrix: 以下にテストしたい PHP バージョンや WordPress バージョン、PHPUnit テストバージョンを列挙していくということになります。

こちらのテスト環境については、下記などを参照・利用しています。

https://github.com/shivammathur/setup-php

WordPress 5.4 や MySQL 5.6 や 8.0 などの条件分岐を設けていたりしますが、大きく分けて PHP 8.0 以上か、それ未満かで Composer の v1 か v2 のいずれを使うかが異なるのでその部分の条件分岐もいれています。

また WordPress のマルチサイトのテストも含めています。

STEP 4. GitHub へプラグインとPHPUnit テストをアップロードする

問題なければ下記のようにテストが成功します。


付録. エラー例




上図のようにすべてのテストが失敗することもありますし、一部バージョンのみだめな場合もあります。


エラー例１）SVNコマンドが GitHub Actions が利用するOS (Ubuntu) から削除されていた


エラー情報


+ svn co --quiet https://develop.svn.wordpress.org/tags/6.7.2/src/ /tmp/wordpress/
phpunit/install.sh: line 38: svn: command not found
Error: Process completed with exit code 127.

phpunit テストが GitHub Actions でエラーが起きてますね。

下記をみると svn コマンドが削除されていたようで、存在しないというエラーになっていました。つまりは明示的にインストールする命令を与えないといけないようですね。

参考：Build/CI: Explicitly install SVN within GitHub Actions due to Ubuntu 24.04 update #337

上記を参考に、下記のようなコードが必要でした。

phpunit/install.sh において

install_wp_and_test_suite() {

の前に下記を追加。

install_svn() {
# Function to check if a command exists
command_exists() {
command -v "$1" >/dev/null 2>&1
}

# Check if SVN is installed
if command_exists svn; then
echo "SVN is already installed."
else
echo "SVN is not installed. Installing SVN..."
# Install SVN
sudo apt-get install -y subversion
fi
}

その上で、一番下の関数を呼び出している
install_wp_and_test_suite
の前に
install_svn を追加する必要ありました。

全体は、下記を参考にしてみてください。


エラー例２）PHP8.1 以降で Configuration.php on line 570 とでて GitHub Actionsが止まる


Run vendor/bin/phpunit
PHP Fatal error:  Cannot acquire reference to $GLOBALS in /home/runner/work/view-shortcodes/vendor/phpunit/phpunit/src/Util/Configuration.php on line 570
Error: Process completed with exit code 255

下記にあるように、PHP 8.1 以降の $GLOBAL の扱いが変わったことが問題でした。

こちらについては テストする PHPバージョンに対して、 PHPUnit が古いことが原因でした。

PHPUnitの Supported Versionsを参考にすると、
  • 9.5の最新：PHP7.4と8.0用
  • 10.5の最新：PHP8.1用
  • 11.5の最新：PHP8.2用
  • 12.0の最新：PHP8.3と8.4用
となっていますが、PHP 8.0以降すべて PHPUnit 9.5 を使っていたため、PHP8.1 以降にエラーがでていたのでした。

2025年3月30日 @kimipooh

投稿者 時刻: 0 件のコメント:
ラベル: , , ,

2024年4月21日日曜日

【救出】7年前から更新されていない contact-form-7-to-database-extension プラグインを WordPress 6.5.2 with PHP 8.3.6 で警告なく動作させる

基本的に開発者によってサポートされなくなった（長期間更新されていない）プラグインは、使うのは非推奨、他の代替プラグインへの乗り換えを考えるというのが素直な流れです。しかしながら、サーバー移転や PHPバージョンアップグレード、WordPress のアップグレードなどによって動作しなくなったプラグインについて、とりあえず延命したい、データを取得するためにも一時的にも動作させたいという要望はあると思います。

そこで、自身がそうした対応をしたプラグインについてどうしたのかを備忘録として残していきます。

今回は、下記のプラグインが対象です。

７年前から更新が止まっており、WordPress 4.8.28 がテストされた最後のバージョンです。
Contact Form 7 の投稿データをデータベースに保存してわかりやすく WordPress 内でチェックできる大変重宝したプラグインでした。代替プラグインとしては、Contact Form CFDB7
などがあります。新規利用なら、こちらを利用するのがよいでしょう。

WordPress 6.5.2 with PHP 8.3.6 での状況


このプラグインは、公式リポジトリでは 2.10.29 になっていますが、 GitHub のほうには、2.10.37 があります。ここでは、2.10.37 を元に説明します。

下記の２つの問題がありました。いずれも警告ではありますが、DEBUG を true にしていると２つ目の警告によって、データがうまく表示できない問題がありました。
  1. PHP 8.1 からの型不一致問題による警告
    Deprecated: htmlspecialchars(): Passing null to parameter #1 ($string) of type string is deprecated - CFDBViewWhatsInDB.php on line 71
  2. PHP 8.1 からの浮動小数点型（float）から 整数型（int）への暗黙の変換が非推奨になったという警告
    Deprecated: Implicit conversion from float-string "1692501560.5118" to int loses precision - CF7DBPlugin.php on line 1227
    参考：https://www.rectus.co.jp/archives/20218

これらの対処は下記の通りです。

1. PHP 8.1 からの型不一致問題による警告への対処


CFDBViewWhatsInDB.php on line 71 において、
下記のコードが 71行の前に下記のコードを追加する。

if($currSelection === NULL) $currSelection = "";

これは、下記の htmlspecialchars の第１引数については string 型（文字列型）を求めているのに、$currSelection に NULL データが入る可能性があるということで、それが PHP 8.1 からは非推奨になるということです。
$currSelectionEscaped = htmlspecialchars($currSelection, ENT_QUOTES, 'UTF-8');

2. PHP 8.1 からの浮動小数点型（float）から 整数型（int）への暗黙の変換が非推奨になったという警告への対処


CF7DBPlugin.php on line 1227 において、コードを下記のように書き換えます。
実際には $time 変数について整数型 int をキャストして、date 関数に引き渡す前に整数にしてしまうということです。
 
return date(CF7DBPlugin::$customDateFormat, (int)$time);

date 関数は 第２引数として整数型を求めており、$time については float 型 であるため、従来だと暗黙の型変換が起こって int 型として処理されたのですが、 PHP8.1 では float 型から int 型への型変換は明示的にせよということになったため。

上記修正を施したバージョンへ置き換えるには？


修正を施したバージョンは、下記に Fork して保存しています。


こちらの Code の▼ より Zip 形式でダウンロードして、WordPress にインストールしてみてください。フォルダとしては contact-form-7-to-database-extension-master と公式プラグインの contact-form-7-to-database-extension と異なるため、上書きではなく新規で同じプラグインが追加されます。バージョンとしては 2.10.37k としているので、公式プラグインのほうを無効化して、新しいものを有効化すればよいです。

バージョンにアルファベットをいれたのは、あくまで新しい WordPress や PHP でのエラーや警告を消しただけであり、機能追加していないこと、また Fork もとのほうが新しいバージョンをだしてきたときにややこしくなるので、区別するためにそうしています。

2024年4月21日 @kimipooh

投稿者 時刻: 0 件のコメント:
ラベル: , ,

2021年3月18日木曜日

Contact Form 7 version 5.4 以降 動かなくなった Contact Form 7 add confirm プラグイン（Contact Form 7 に確認を追加する）を動作させるには

 筆者自身は、「上記内容で間違いありません」のチェックボックスを設けるぐらいで回避したり、Googleフォームも確認がないので利用はしていませんでした。

でもこの「Contact Form 7 add confirm」プラグインについては、WordPress勉強会か WordCampのコントリビューターディか忘れましたが、そうした場所で「開発したー」というのを聞いた記憶が朧気ながらあるのです。まぁそれを証明するものがないので漠然とした記憶だけです。

まぁともあれ、Contact Form 7 のバージョン5.4 から動作しなくなったという情報が、ちらほら目につくようになりました。

これについて、サポートフォーラムで修正方法が掲載されたので備忘録をこめてメモしておきます。


対処方法


Contact Form 7アップデートでContact Form 7 add confirmが効かない（WordPress.org 日本語版サポートフォーラム）

にあるように、

plugins\contact-form-7-add-confirm\includes\js\scripts.js

223行目と 226行目の、event.detail.id → event.detail.unitTag に変更すれば動くというものです。

変更前


変更後


ということですね。

実際に手持ちの WordPress 5.7 + PHP 8.0.0 でも動作することを確認しました。

2021年3月18日 @kimipooh

投稿者 時刻: 0 件のコメント:
ラベル: ,

2021年3月5日金曜日

MAMP 上の WordPress で PHPキャッシュ「APCu」モジュールを有効にしてみよう！

MAMP 6.3 から PHP 8.0 をサポートするようになりました。

ローカル環境として、いくつかのツールを併用しており、MAMPはその一つです。

MAMP上の WordPress は最近とても動作が遅くなってきました。そのため、パフォーマンスを改善するための PHPキャッシュをつかいたいと思うようになったので、設定したメモを備忘録として残しておきます。

準備と条件


次のことを前提としています。
  1. macOS であること（検証したOSは macOS 10.15.7）
  2. MAMP 6.3がインストールされていること
  3. MAMP上にWordPressをインストールして動く状態（管理ダッシュボードにログインえきる）
MAMP無料版では、PHPバージョンの選択は２つまでです。
したがって、
  • /Applications/MAMP/bin/php
にある PHPフォルダのうち、２つ以外は別フォルダへ移動しておいてください。そうすることで、選択したい PHPバージョンにできます。たとえば、php8.0.0と php5.6.40 だけのフォルダを残せば、下図のようにその２つのバージョンを選択できるようになります。


STEP 1. PHPキャッシュ APCu モジュールを有効化する


MAMPのデフォルトでは、 APCu モジュールは有効になっていません。
これを有効化するには、 php.ini の変更が必要です。MAMP上では、php.ini はバージョンごとに別フォルダで用意されています。MAMPの php 8.0.0 の場合、
  • /Applications/MAMP/bin/php/php8.0.0/conf/php.ini
になります。

このファイルにある
  • ;extension=apcu.so
の先頭のコメントを外してください。
  • extension=apcu.so
そして、MAMPのサービスを終了して、再度起動しなおします。
ターミナルアプリより
  • /Applications/MAMP/bin/php/php8.0.0/bin/php -m
を入力してEnterすることで、PHPで利用できるモジュール一覧が出てきます。
その中に apcu が存在すれば、APCu モジュールが有効になっているということになります。

STEP 2. WordPress で有効化


＊注意：下記で紹介する WP-FFPC プラグイン 1.11.2 （2021年3月5日時点）は、そのままでは PHP 8.0.0 では動作しません。

WP-FFPC プラグイン 1.11.2 （2021年3月5日時点）を利用する場合には、
を参考に、プラグインソースの変更が必要です。変更しなければ PHP 8.0ではサイトがエラーでアクセスできなくなります。したがって事前にFTP接続などサイトのWordPressファイルを直接いじることができるようにしておくのがよいです。

MAMPのようなローカル環境ならサイトエラーが出てから、上記リンク先を参考にプラグインのソース・ファイルを後から修正することで対応は可能です。

しかし本番環境では、
  • https://wordpress.org/plugins/wp-ffpc/
より WP-FFPCプラグインをダウンロードし、FTP経由でプラグインをインストールし、問題の箇所を修正するのがよいでしょう。

また一時的な措置としては構いませんが、プラグインが更新されたときに変更した部分が上書きされて、サイトがエラーでとまってしまうリスクがあります。したがって、PHP 8.0で利用する場合には、本番用では対応するまで使わないほうがよいでしょう。

プラグインを有効化できたら、設定 > WP-FFPCより、APCu を選択して保存すれば有効になります。


ローカル環境だとそれでいいですが、本番環境だとキャッシュの期限を調整するとよいと思います。


2021年3月5日 @kimipooh

投稿者 時刻: 0 件のコメント:
ラベル: ,

WordPress プラグイン「WP-FFPC」を PHP 8.0で動かす！

 WordPress で PHPキャッシュ（APCu等）を有効化するプラグイン「WP-FFPC」ですが、PHP 8.0 ではエラーがでてサイトが止まってしまいます。PHP 7.4 では動きます。PHP の APCu モジュールは、さくらインターネットのレンタルサーバー等、APCu モジュールが使える PHPで有効化するとサイトのパフォーマンスがかなり上がる無くてはならないものです。それが PHP 8.0になるとサイトが止まってしまうのは大問題です。

そこで WP-FFPC 1.11.2 （2021年3月5日時点）を修正して問題を解決してみました！その備忘録をまとめておきます。

PHP 8.0.0 上で、WP-FFPCをインストールすると・・・


有効化するまえに、下記のエラーでサイトが止まります。

これらを参考にソースコードをチェックした結果、下記の赤文字の部分の問題があることがわかりました。どのような問題かは後述します。

wp-ffpc-class.php
1016-1018行目

public function plugin_options_migrate( &$options ) {

if ( version_compare ( $options['version'], $this->plugin_version, '<' )  ) {


問題を解決する方法


この 1017行目に
if($options === false) $options = array('version' => '0.0');
を追加することで本問題を回避できます。
実際には、下記の青のコードを追加するということです。
	public function plugin_options_migrate( &$options ) {
		if($options === false) $options = array('version' => '0.0');
		if ( version_compare ( $options['version'], $this->plugin_version, '<' )  ) {

原因の説明


これはプログラムのバグです。
wp-ffpc-abstract.php
514行目から
public static function _get_option ( $optionID, $network = false ) {
if ( $network ) {
static::debug ( sprintf( __( '- getting network option %s', 'PluginUtils' ), $optionID ) );
$options = get_site_option( $optionID );
}
else {
static::debug( sprintf( __( ' – getting option %s', 'PluginUtils' ), $optionID ));
$options = get_option( $optionID );
}

return $options;
}
において、 戻り値の $options は、false (bool値）, 配列等いくつかのパターンがあり、最初にインストールするときに、WP-FFPCの設定が WordPressで利用するデータベースに存在しないことから、$options の値が false (bool値）となります。

そうすると、下記の $options['version'] が存在しないことになり (falseとなる）、version_compare の第１引数が false になります。しかし、version_compare は引数に string を期待しているため、型の不一致が起こります。PHP 8.0からはそうした場合にはエラーになるということです。

wp-ffpc-class.php
1016-1018行目

public function plugin_options_migrate( &$options ) {

if ( version_compare ( $options['version'], $this->plugin_version, '<' )  ) {


このバージョンチェックは、WP-FFPCプラグインのバージョンが、インストール前のバージョンよりも新しければというチェックをしています。つまりプラグインが更新したときの処理でしょう。そのため、初期値を 0.0 にすることで、最初にインストールしたときには、必ずこのチェックが真になるように、下記のように比較前にコードを追加してあげればよいです。
if($options === false) $options = array('version' => '0.0');

これでエラー無く動くので、あとは一度でも WP-FFPCの設定を保存すれば、以後は $options が false になることはないはずです。

開発者の GitHUBに ISSUEとしてあげておきました。

さらに WordPress.org のプラグインサポートのほうにも投稿

修正されることを祈っておきます！

付録A) APCu キャッシュを有効にできる他のプラグイン等について


なかなか思うようなプラグインには出会えず。

  • Power Cacheプラグイン: https://ja.wordpress.org/plugins/powered-cache/
    • ドロップインに追加されるが、エラーがでてしまっている。wp-content/object-cache.php → wp-content/plugins/object-cache.php  へシンボリックリンクを張れば動く。



  • APC Object Cache Backendプラグイン：https://wordpress.org/plugins/apc/
    • PHP 8.0では重大なエラーがでて有効化できず

付録B)  Deprecated: contextual_help の使用はバージョン 3.3.0 から非推奨になっています ! への対応


作成：2021年3月8日

Deprecated: contextual_help の使用はバージョン 3.3.0 から非推奨になっています ! 代わりに get_current_screen()->add_help_tab(), get_current_screen()->remove_help_tab() を使ってください。 in /****/wp-includes/functions.php on line 5234

これは、wp-admin/ 以下の管理画面の上部にヘルプタブに追加する機能のようです。
が使い方が書かれていますが、結構修正は大変のように見えます。
これなくても機能としては問題ないため

wp-ffpc-class.php
 add_filter('contextual_help', array( &$this, 'plugin_admin_nginx_help' ), 10, 2);
を
//  add_filter('contextual_help', array( &$this, 'plugin_admin_nginx_help' ), 10, 2);

wp-ffpc-abstract.php
 add_filter('contextual_help', array( &$this, 'plugin_admin_help' ), 10, 2);
を
// add_filter('contextual_help', array( &$this, 'plugin_admin_help' ), 10, 2);

とコメントして無効化しておけば、とりあえず問題なさそうですね。


2021年3月5日 @kimipooh
2021年3月8日 付録2) を追記

投稿者 時刻: 0 件のコメント:
ラベル:
登録: 投稿 (Atom)