ラベル プラグイン の投稿を表示しています。 すべての投稿を表示
ラベル プラグイン の投稿を表示しています。 すべての投稿を表示

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年7月3日水曜日

【備忘録】WordPress.org で２段階認証を有効にする方法

突然、WordPress.org へのログインができなくなって ??? と思ったのですが、WordPres.org Plugin Directory からのメールをみて納得しました（6月29日に届いていた）。

件名：[WordPress.org] Password Reset Required for Plugin Authors

内容としては、一部のプラグイン作者がパスワードの使いまわしをしていて、そのパスワードが WordPress.org とは異なるサイトで漏洩してしまい、これを悪用されたかで WordPress.org のプラグインディレクトリのいくつかのプラグインに悪意あるコードを追加されてしまった模様という感じですね。

Password Reset Required for Plugin Authors – Make WordPress Plugins

一時的に全プラグインのコミットはチームによる承認制なって対策していたということです。現在は解除されているとのこと。

で、プラグイン作成者とセキュリティ研究者によって漏洩したとおもわれるパスワードを使っていたユーザーについて、WordPress.org へのログインパスワードを無効化（強制リセット）したということです。

プラグイン作成者は、パスワードのリセットが必要になったわけですが、同時に２段階認証を有効にするように推奨しています。というわけで私のパスワードも無効化されていたのでした。

WordPress.org は、2023年5月から２段階認証を導入していた


下記のようにプラグインコミッターは、少なくてもパスワードに20文字以上で、大文字小文字記号を含め、他のサービスで使いまわししないようにとあります。私自身はランダム生成のパスワードをつかっているので、使い回しはありませんが、パスワードは12文字だったので今回20文字以上にしました。

Keeping Your Plugin Committer Accounts Secure – Make WordPress Plugins

プラグインコミッターでなくても、アカウントへの不正アクセスを防ぐためにも２段階認証は有効にしたほうがよいですね！ 私もしていたつもりがしていなかったので今回してみました。

STEP 1. Two-Factor App と Two-Factor Backup Codes を有効にしてみる




下記にアクセスします。


Two-Factor Apps


あらかじめ、 スマートフォンに Google Authenticator や Microsoft Authenticator など２段階認証用のアプリをインストールしておきます。そして、Two-Factor App をクリックして、表示されたQRコードを、そのアプリで読み込みます。すると6桁の数字が一定時間ごとに変更されたものが表示されるので、その数字を入力して設定を完了します。

Tw-Factor Backup Codes


ここをクリックすると10個の緊急時用の１度のみ使えるバックアップコードが発行できます。もし２段階認証として使っていた端末やアプリが使えなくなったときにログインできるコードになります。どこかにメモっておきます。

STEP 2. Two-Factor Security Key を有効にする


最近流行りのパスキーです。

パスキーの詳しい話は、Googleの公式ヘルプあたりをチェックするとよいかなと思います。

パスワードの代わりにパスキーでログインする - Google アカウント ヘルプ

こちらは端末ごとに設定しておくことになります。パスキーに対応している端末をお持ちの場合には設定しておくと便利ではあります。

下記の「Register new key」をクリックして、名前をつけて設定します。
macOS をお使いなら、iCloud キーチェーンのほうに保存しておくのがよいでしょう。


設定するとパスキーがメインの認証方法になります。


STEP 3. 実際にログインを試してみる



各ブラウザについてプライベートモード（Cookieとキャッシュを無効化したログインしていない状態）にして、WordPress.org にログインしてみます。

アカウントとパスワードを入力すると、下記のようにパスキーを聞いてきます。
macOSと iPhoneをセットで持っているなら、iCloud キーチェーンで同期しているため、iPhoneのカメラで下記のQRコードを読み取ってアクセス。iPhoneのほうで認証します。iPhoneで顔認証を有効にしていれば、顔認証をすることで認証できることになります。

それができない（オンラインでない）場合には、「キャンセル」ボタンをクリックして、下記のようにエラーがでてきたら「User your authenticator app」を選択して、スマートフォンに設定したはずの認証アプリに表示されている WordPress.org 用の6桁の数字を入力すればよいです。この認証アプリについてはオフラインでの利用が可能です。


２段階認証を有効にしておけば、パスワードが漏洩したとしてもログインされることはなくなります。特にパスワードの使い回しをすると、他の脆弱なサイトで漏洩する危険性があるので、そうしないように気をつけないといけませんね

なおパスワードを考えつかない！という場合には、パスワード生成してくれるサイトは検索すればいろいろでてきます。そうしたものを活用してパスワードをランダム生成して、それをブラウザのパスワードマネージャーに保存する、メモするなどをしておくとよいかと思います。

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

2024年6月21日金曜日

【備忘録】APCu の object caching が原因で WP-CLI の wp plugin list でプラグインの更新状況が確認できない場合の対処

PHP を利用したページ表示を高速化する APCu キャッシュを WordPress で有効化すると、かなりサイトの表示速度を向上することができます。利用するためには、PHP で APCu が有効になっている必要があります。たとえば、さくらインターネットやエックスサーバーなどのレンタルサーバーでは、標準で有効となっています。

WordPress でも手動の場合には、下記の方法もありますが、

何らかのプラグインを使っていることも多いはず。

以前は、WP-FFPCプラグインを使っていて、長期メンテナンスされておらず PHP8.0に非対応だったので対応させたりしてましたが、手動でやるのは限界があります。したがって、最近は APCu Manager プラグインを使っています。

 

WP-CLI の wp plugin list で更新が出てこない問題


下記のように、backwpup プラグインは 4.1.1 が最新であり、WordPress の管理画面にログインするとプラグイン更新画面には出てくるのに、WP-CLIでの update_version には出て来ない場合があります。 このことはずっと原因がわからなくて、ようやく「wp plugin list stopped working [with W3 Total Cache object caching] #1047」の情報にたどり着いたのでした。2014年からこの問題はあったのですねぇ。なおこの問題が起こった場合、WordPress 管理画面から設定するプラグイン自動アップデートも機能しませんでした。あくまで更新ボタンを押して手動で更新しなければ、更新できない問題があったということです。


% wp plugin list
+------------------+----------+--------+----------+-------------------+-------------+
| name             | status   | update | version  | update_version    | auto_update |
+------------------+----------+--------+----------+-------------------+-------------+
| apcu-manager     | active   | none   | 4.0.0    |                   | off         |
...
| backwpup         | active   | none   | 4.1.0    |                   | off         |
...
| object-cache.php | dropin   | none   |          |                   | off         |
+------------------+----------+--------+----------+-------------------+-------------+

このケースにおいては、APCu のキャッシュ機能を有効にしていた場合には無効にして試してみてください。下記のように更新がでてくれば、このキャッシュ機能と WP-CLI問題だということになります。

% wp plugin list
+------------------+----------+--------+----------+-------------------+-------------+
| name             | status   | update | version  | update_version    | auto_update |
+------------------+----------+--------+----------+-------------------+-------------+
| apcu-manager     | active   | none   | 4.0.0    |                   | off         |
...
| backwpup         | active   | none   | 4.1.0    |     4.1.1              | off         |
...
| object-cache.php | dropin   | none   |          |                   | off         |
+------------------+----------+--------+----------+-------------------+-------------+

対応方法


そもそも、WP-CLIをつかうのは、プラグイン更新を自動化したい目的もあるはず（ wp plugin update --all など）。となると、下記の一連の操作をしたいと思うはず！
  1. APCu の object caching を一時的に無効にして
  2. WP-CLI によるプラグインを更新して
  3. APCu の object caching を有効化
APCu Manager プラグイン は WP-CLI による制御が可能ため、このプラグインをつかうことで、うまくいきました。
  1. wp apcu settings disable object-caching --yes
  2. wp plugin update --all
  3. wp apcu settings enable object-caching

APCu Manager プラグイン の状況は、
wp apcu status 
コマンドでわかります。

2024年6月21日 @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 件のコメント:
ラベル: , ,

2022年11月21日月曜日

【備忘録】Backwpup プラグイン 4.0.0 に起因するサイトエラーに対する対応について

2022年11月21時点で自身が管理する WordPress サイトがエラーで表示できないトラブルが出てきました。ブログやTwitterを見ていると、11月16日に Backwpup 4.0.0 へメジャーバージョンアップしたときｋらのようですね。エラーログをチェックしていると、Backwpup プラグインの影響であることが判明。数日前に問題のある Backwpup 4.0.0 をリリースしたようです。

下記のプラグイン開発者の投稿を見る限り、本来含めるべきファイルを含めるのを忘れていたということでした。

エラーとしては、Fatal error : require(): Failed opening required  から始まって

wp-content/plugins/backwpup/vendor/composer/autoload_real.php on line 59

あたりまでような感じです。ファイルが読み込めないというエラーになりますね。


対処方法は？

まず現在問題は修正され、Backwpup 4.0.0 として公開されています。この時点で新規インストールする場合には、問題ありません。

問題のある Backwpup 4.0.0 へアップデートやインストールしてサイトがエラーになる（キャッシュの影響でサイトはエラーになっていない場合もあります）、あるいは管理画面にログインしようとするとエラーになっている場合には対処が必要です。

  1. FTPやSSHなどでサーバーに直接アクセスし、WordPressをインストールしたフォルダの wp-content/plugins/backwpup フォルダを別の場所に移動するか削除します。
  2. これで WordPress が正常に表示されていると思うので、管理画面にログインして、再び backwpup をインストール＆有効化します。

上記の方法であれば、Backwpup に設定した以前のバックアップ設定はそのまま表示されているはずです。

参考：https://wordpress.org/support/topic/4-0-0-crashed-multiple-sites-again/


2022年11月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 件のコメント:
ラベル: ,

2020年12月11日金曜日

Travis-CI と GitHUB連携で WordPress プラグインの PHPUnit によるテストを実行する（PHP 7.4対応）

 もうすぐ PHP 8.0対応のWordPress 5.6がリリースされる（2020年12月8日予定）ということで手持ちの公式プラグインを Travis-CIにてチェックし始めました（WP CLI 2.4.0 の wp scaffold plugin-tests プラグイン名 で吐き出すてｓ）。ところが、いつの間にか PHP 7.3以上については Travis-CIが PHPUnit 8.x（PHP8.0.0-devは PHPUnit 9.x）を使うため、PHPUnit 7.x までしか対応していない ため、現行のWordPressでは下図のようにエラーがでて動かなくなっていました。１年前ぐらいは問題なかったのですけどね。WordPress 5.6からは PHPUnit 8.x をサポートするそうです。この記事は WordPress 5.6がでる前（WordPress 5.6 RC2〜RC3）のときに検証した結果です。 WordPress 5.6も検証していますが、PHPUnit 8.x は未検証です。

付録（後述）で、MAMPを使った PHPUnitテストも説明しています。
また GitHubとTravis-CI 連携はできているものとします。そのやり方は検索したらいろいろと情報がでてくるでしょう。



PHP 8.0.0-devはうまくいかず

また数日調べたり、試してみましたが PHP 8.0.0-dev については、うまくいきませんでした。というわけで、こちらは素直に WordPress 5.6が出てから考えることにしました。


PHP 7.3/7.4 利用時に Travis CI に PHPUnit 7 を強制させる

PHPUnit 8.x対応の WordPress 5.6がでたら不要になるかもしれませんが、2020年12月1日現在は、WordPressが PHPUnit 7.x 以下しか対応しないため、やむを得ません。

変更するのは「.travis.xml」です。また composer.json がないと 「Composer could not find a composer.json file in XXX 」のようにエラーがでる場合があります。

したがって追加や変更点は

  • .travis.xml の変更
  • composer.json
  • phpunit.xml.dist の test-sample.php の除外設定をコメントアウトする
    （<!-<exclude>./tests/test-sample.php</exclude> -->）
の三点です。

詳細は
のコードを参考にしてみてください。

なお WP-CLIが吐き出す PHPUnit （wp scaffold plugin-tests）に含まれる .travis.xml は、２点古い書き方があります。

  1. matrix キーは、jobs キーへ変更（matrixはjobsへのエイリアス）したので、今後は jobs キーを使うこと
  2. sudo: は廃止キーだから削除推奨

また、PHP 7.3, 7.4 については、Travis CIで失敗しても許容するように、allow_failures キーを設定しておきます。ここで指定しておけば失敗しても Travis CIのジョブとしては失敗とはみなされないということになります。

まず jobに PHP 5.6〜 7.4を追加します。 PHP 7.4については WordPress 5.6（リリース候補）も含めておきます。

うまくすべてが成功していれば、下図のように allow_failures に含めた PHP 7.3と 7.4でもテストが成功していることがわかります。なお、ここでの WordPress nightlyバージョンとは、WordPress 5.6 RC2あるいは RC3を指します。

付録：MAMPを使った PHPUnitテスト方法

2020年12月9日時点（日本時間）においては、 WordPress 5.6の日本語版もリリースされました。ただ PHPUnit 8.5.13 を実行しようとすると

Error: Looks like you're using PHPUnit 8.5.13. WordPress requires at least PHPUnit 5.4 and is currently only compatible with PHPUnit up to 7.x.
Please use the latest PHPUnit version from the 7.x branch.
とでます。
をみる PHPUnit 9以降は PHP8以降のみサポート。PHPUnit8 は PHP7.1以降のサポートだとか。とりあえず、ここでは PHPUnit 7でのやり方を説明します。

検証環境

  • macOS Big Sur (11.0.1）
  • MAMP 5.7 （最新の6.2 は Apacheの80 ポート利用でコケるのでまだ使っていない）
    • PHP 7.4.2
  • zsh（シェル）
  • プラグインテストの準備
  • svn をインストールしておきます（Big Surには標準搭載されていない）
    • Xcodeには含まれなくなったため、Homebrew をインストールして、 brew install svn からインストールできます。

STEP 1.  MAMPの phpや mysql等コマンドを優先する PATHを通す

ターミナルが起動しているときのみの一時的な有効化になりますが、
ターミナルを起動して次の2つのコマンドを、順番に実行してください。
＊bash/zsh 両シェル対応

export php_path="`ls -d /Applications/MAMP/bin/php/php* | tail -1`"
export PATH="${php_path}/bin:/Applications/MAMP/Library/bin:$PATH"

これによって、MAMP内の最新 PHPを php コマンドに一時的に割り当てます。
which php
でパスが /Applications/MAMP/bin/php/php7.4.2/bin/php （今回の場合）になっていることを確認しておくことが重要です。

STEP 2. wp scaffold plugin-tests が吐き出す bin/install-wp-tests.sh の変更

  • https://github.com/kimipooh/view-shortcodes/blob/master/bin/install-wp-tests.sh
のうち、下記の赤文字の部分を削除してください。
MySQL 5.6以降、コマンドラインから DBへのアクセスにパスワードを指定することは、セキュリティ上好ましくないので警告を出してできないようになっているようです。
  • mysqladmin: [Warning] Using a password on the command line interface can be insecure.
回避するためには、「パスワードを入れてmysqlコマンドを実行すると「Warning: Using a password on the command line interface can be insecure」が表示される」などの記事にあるようにファイルにパスワードを記載してそれをコマンドに読み込ませるという方法もありますが、ここでは素直にパスワードをキーボードから入力することにします。

変更前（bin/install-wp-tests.sh）
  • mysqladmin create $DB_NAME --user="$DB_USER" --password="$DB_PASS"$EXTRA

変更後（bin/install-wp-tests.sh）
  • mysqladmin create $DB_NAME --user="$DB_USER" --password $EXTRA

こうすることで MAMPの初期設定（MySQLポート 8889、ユーザー、パスワードともに root）であれば、

STEP 3. テスト用 WordPress のインストール

bash bin/install-wp-tests.sh view-shortcodes root 'root' 127.0.0.1:8889 latest

というコマンドを叩くことで、WordPress最新版（latest）が、 

/var/folders/_6/ユニークキー/T/wordpress/

あたりにインストールされるでしょう。

STEP 4. PHPUnit7 のダウンロードと実行

  • https://phar.phpunit.de/phpunit-7.phar
より PHPUnit 7の最新版をダウンロードします。
phpunit7 とリネームして
chmod 755 phpunit7 と実行権限を付与しておきましょう。
これをパスが通っている場所に移動しておきます。
MAMP限定なら、/Applications/MAMP/Library/bin にいれておけばよいです。
STEP 1 で上記へのパスは一時的に有効になっているはずです。

あとは、 テスト環境野整った プラグインフォルダで

phpunit7

と実行すれば

Installing...
...
...
OK (1 test, 1 assertion)

のようにテストされるはずです。

2020年12月11日 @kimipooh

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

2020年3月11日水曜日

WordPress では /?author=数字 で WordPressのユーザー名（ログインID）が漏洩してしまう件の対応について

何が問題か


WordPress では、
  • WordPressサイトのURL/?author=数字
にアクセスすることで、
  • WordPressサイトのURL/author/ユーザ名
に自動転送される仕組みになっています。
これを悪用すれば、
  • WordPress のユーザー名に割り当てられている「すべての」ユーザー名（ログインID）を知られてしまいます。
このことは
にあるように脆弱性診断システムなどで脆弱性ありと判断される場合があります。

対策しているかどうかの確認方法


コマンドラインツール curl を使えば（macOS には標準搭載）、たとえば、 http://example.com に WordPressのサイトがあるとすると
  • curl -v -D -  "http://example.com/?author=1"
と Mac ならターミナルから入力することで、標準出力にヘッダー情報が出てきます。
そこの location: をみると
  • location: http://example.com/author/ユーザー名/
になってユーザー名が見えてしまっています。これが存在しない場合、ユーザー名でない場合には何らかの対策がされているということになります。

実際にウェブサーバーログをみると、
?author=1
?author=2
?author=3
?author=4
...
など大量にスキャン（ポーリング）されているサイトもありました。

ユーザー名が漏洩したからといって即座に問題になるとは限らない


先に説明しておきますが、ログインのユーザー名が漏洩したからといって、それだけで不正ログインされるわけではありません。一般的にはパスワードが必要だからです。しかしながら、他のサイトとパスワードを同一（パスワードの使いまわし）をされていれば、もし他のサイトからパスワードが漏洩してしまうとログインできてしまいます。ですので別途ログインについては、下記のようなセキュリティ対策を施しておくのがよいです。
  • IPアドレス制限
  • 認証にクラウドサービス（Google認証等）をつかう
  • 総当り攻撃（ブルートフォース攻撃）への対策（一度に大量アクセスを防止）
などです。そうすれば、たとえユーザー名が漏洩したとしても問題はなくなります。

とはいえ、WordPress にどのユーザーがログインできているのか知られることは嫌ですよね。ですので対策したほうがよいでしょう。
ここでは

1. ウェブシステム側で止める
2. WordPress プラグインで止める（自作）

に絞って備忘録として残しておきます。

対策１. ウェブシステム側で止める


各ウェブサイトの設定において、先頭から
  • /?author=***  = 404エラーとする
  • /author/*** = トップページへリダイレクトする
これが可能なら、WordPress に到達する前に止めることができるのでウェブサイトへの負荷が減ります。
/author/** のケースは、 /hogehoge/author/** を除外するかどうかが、ややこしくなります。たとえばカテゴリー名に使った場合とかです。とはいえ、author は予約語でもあるので、まぁそこは除外するでよいでしょう。

Apache での設定方法


WordPress側では、RewriteBase が設定されているはずなので
  • RewriteRule ^\?author=(.*)? / [NC,R=404,L]
  • RewriteRule ^author/(.*)? / [R=302,L]
の2つを追加すればよいです。
管理者画面側では、?hogehoge=**&author=**
となるので、管理者画面では除外できるはずです（未検証）。
うまくいかなければ、RewriteCond ルールなどを併用すればいいでしょう。筆者は NGINX しかほぼ触っていないので、詳細は

NGINX での設定


nginx は if 文など条件を入れ子構造にできないという問題があります。
したがって細かな条件を書くのが超大変です。
ここではドメインやサブドメイン直下（http://example.com やhttp://hogehoge.example.com/） のように http://example.com/hogehoge というサブディレクトリに保存されていないと仮定すると、汎用性がある設定としては、

set $rp_flag  flag;   
set $rp_flag2 flag; 

if ($request_uri ~ "^/wp-admin/"){
        set $rp_flag false;
}
if ($request_uri ~ "^/author/"){
        set $rp_flag2 "${rp_flag2}_true";
}
if ($args ~ "author=(.*)"){
        set $rp_flag "${rp_flag}_true";
}
if ($rp_flag = flag_true){ 
        return 404;
}
if ($rp_flag2 = flag_true){
        return 302 /;
}


上記コードでは、

1. /wp-admin/ （管理画面）は対象外（リダイレクトしない）
　＊つまり公開している側のみリダイレクトする
2. /author/ か GETパラメーターに author= があるかのいずれか
上記をすべて満たす場合に、トップページへリダイレクトする

ということになります。
「１」が必要な理由は、管理画面の投稿や固定ページ等で各ユーザーごとに一覧を表示するのに、author パラメーターが使われているためです。それは必要だろうという判断です。

このように、フラグを文字連結させた上で、それを文字判定させる手法になります。
さらに、requiest_uri に ? があるとパラメータ扱いになって、$args に保存されるという仕様もあってなおややこしい。

参考：

対策２. WordPress プラグインで止める（自作）



ウェブサーバーのほうで止めることができない場合（設定をいじれない）もあると思います。その場合には、テーマの functions.php に書くなどの方法もありますが、サイトが大量にあるとやってられません。
公式プラグインだと WP-CLIコマンドなどで一括インストールが可能になるので、その設定をしていれば、
  • wp @all  plugin install  プラグイン名  --activate
プラグインを作成してそれを公式プラグインに登録しちゃえばよいのです。
幸い筆者は WordPress の公式プラグインをいくつかアップして、メンテナンスしているのでそのあたりのやり方は知ってます。

ただ問題はどのような手法で止めるのかがかなり悩みました。

など速度低下が著しい模様。wp_safe_redirect をつかうのも同様じゃないかなぁと思います。そこで結局は
で提示された方法を採用しました。また /author/ の場合を追加して、その場合にはトップへリダイレクトすることにしました。author=数字 は明示的に攻撃しているといってもいいですが、 /author/ はもしかして誤って入力したかもしれず、表示されないよりはリダイレクトにしたほうがいいかなぁという想いです。つまりは、
  1. 管理画面以外（公開されている部分のみ）に適用
  2. QUERY_STRING に「author」項目がある = 404エラー
  3. REQUEST_URI に /author/ があること =  トップへリダイレクト
  4. redirect_canonical にも対応し、自動補正時にもチェックが走るようにする
という感じです。

2020年3月11日 @kimipooh

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

2019年9月13日金曜日

Google開発の画像遅延プラグイン「Native Lazyload」を試してみた！ #wordpress

試してみよーと思ってすっかり忘れてしまっていた「Native Layload」プラグイン。




をみるとウェブサイトの画像を遅延読み込みすることで全体的な表示速度を向上しようという仕掛けのようです。たしかに最近の画像はスマートフォンが 1000画素を超えるようになってきて数MBは普通に事になってきましたしね！

翻訳


日本語の翻訳はまだ完成していませんでした。ので分かる範囲で翻訳作業をしましたー。１件だけわからないかったので、誰かによろしくーーー

試す！


とりあえず手持ちで管理しているサイトにいれてみました！！
なお、現在この遅延ロードの恩恵を受けられるのは、 Google Chrome のみのようです！
確かに画像の <img>タグに対して、 loading="lazy" 属性は追加されてますね！！

で、速度はどうなの？


Google PageSpeed Insight


プラグインなし


プラグインあり（有効化）


若干向上してますね！

GTmetrix 



プラグインなし





プラグインあり（有効化）


スコアはほぼ変わっていませんが、 Full Loaded Timeがかなり速くなっていると思います。

このテストサイトは画像が少ないのであまり参考にならないかもしれません。
筆者は今週末から海外にいくので、帰ってきたらメインサイトに順次いれてテストしていこうかなーと思ってます！

2019年9月12日 @kimipooh 




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

2019年7月27日土曜日

【複数拡張子対応】拡張子アップロード追加許可プラグイン WP ADD MIME TYPES（WordPress） 2.4.0リリース #wordpress

WordPress.org のサポートフォーラムにて筆者が開発し公開している wp add mime types プラグインについて
というリクエストが来ました。内容としては、拡張子が複数ある場合への対応です。
具体的には、 *.min.css や *.min.js などのケースですよね。

wp add mime types の仕様関連

基本、興味を引いたらガッと開発するタイプなので、緊急対応が必要な何か以外は返事が１ヶ月なしとかあります。そのあたりはまったりお待ち下さい。たぶん、そのうち見るでしょう。

WordPress は拡張子が複数ある場合にファイル名をサニタイズにしてしまう

対応自体はそれほど難しくないのですが、WordPressのファイルアップロードに対するフックで、そのあたりをサポートしていないのにはなにか理由があるはず！ということで、WordPress のソースを漁ってみたら

wp-includes/formatting.php の sanitize_file_name 関数内にありました。


まず、拡張子が１つのケース（hogehoge.jpg など）ではサニタイズしません。それは上記のコードで明らかです。では複数の場合にはどうでしょうか。


コメントにも書かれていますが、
  1. 拡張子は一番最後に発見されたドット（.）を起点とする
  2. それ以前に発見されたドット（.）について 2文字〜5文字の範囲かつ許可された拡張子以外なら、ドット（.）の前にアンダーライン（_）を挿入する
の２点です。. が _. になってもセキュリティ面でのサニタイズ処理ではないので、ドット（.）が複数あることに対する何らかのポリシーがあるのでしょう。その理由は少しネット検索しましたが見つけることができませんでした。

しかし、それでは困るケースもあります。ファイル名に複数拡張子がついているケースは珍しくないためです。実際に WordPress でも *.min.css 等で使われているケースがあります。たとえば、自作したコードをアップロードしてサイトで提示したい場合に、ファイル名が *.min_.css となってしまうと、ダウンロードもその名前になってしまって混乱を生んでしまいます。

そうしたことを考えた上で、wp add mine types では複数拡張子に対応することにしました。

アプローチ


最初に考えたのが、次のことでした。しかし、後述する問題があるのでプラグインでは実装しませんでした（実際には実装を試して動作確認までしましたが、やめたという感じですね）
  • ファイル名に存在する拡張子すべてを許可する
こうすることで先程の２番目の条件
  • それ以前に発見されたドット（.）について 2文字〜5文字の範囲かつ許可された拡張子以外なら、ドット（.）の前にアンダーライン（_）を挿入する
の「許可された拡張子以外」になるので、サニタイズされません。

しかしプラグイン側でそれをやると意図しない拡張子も許可してしまうことになります。ですのでプラグイン側では素直に
  1. 拡張子は一番最後に発見されたドット（.）を起点とする
  2. 複数拡張子があるときのみ、サニタイズされたファイル名を修正する（_. を . に変更する）
で対応しました（バージョン 2.4.0）。


ところで、いつのまにか有効インストール数が 2万を超えてるんですね。
最初は勉強会のハンズオン題材にーということで準備、その後プラグイン公開までを目指していたので公開し、ついでだからと仕事で必要だったこともあり使い始めたのが 2013年。途中マルチサイトに対応してくれー（対応した）とか、WordPress 4.7.2からうまくアップロードできなくなった（WordPress 4.7.1からデータ内をチェックしてMIME判定するようになり、誤検出とか出てきた。対応した。）とか、いくつかのリクエストを経ましたがもう 6年経ったのですね。シンプルなのですが、割と使っていて今後も対応していければーと思っています。

2019年7月27日 @kimipooh






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

2017年11月16日木曜日

LogBook プラグインを使って WordPress の重要操作ログを手軽に取ってみよう

LogBook プラグインは、WordPressの操作をログとして保存するプラグイン LogBook をリリースしました（TaroSky）で紹介されている通り、ログ関連のプラグインです。

開発した宮内氏は、筆者も WordPress 管理運用をする上で欠かすことのできないコマンドラインツール WP-CLI チームの日本唯一のコミッターです。WP-CLIのコミッターになってからの４週間でやったことと感じたこと（Capital P）での宮内氏の発言をみるだけでも、ものすごく沢山のコミットを積極的にされているのが伺えます（というか GitHUBみたら、最近の1年間は少なくても毎日なにかの更新されてます @@!）。

また見逃していましたが、「WP-CLIをつかってWordPressのDBをコマンド1回で別のサーバーに引っ越す」ってのは、すごすぎですよね！

また WP-CLI で引っかかるメモリ問題に関してもしっかり記事「WP-CLI でメモリ不足のエラーが出る時の対処法（Quiita）」をかいていて、これも活用させてもらってます。

さらには、最近 Google Analytics を埋め込むプラグインが Jetpack と相性が悪いのが動作しなくなったサイトがあったときに、宮内氏が開発されている WP Total Hacks にもお世話になってます。

その宮内氏が、サイトの重要なイベントに対して負荷をあまりかけずにログを記録するというプラグインを開発したとなれば、これはもう使ってみなくちゃいけません！

WP-CLI からプラグインのアップデートしたら





フムフム、サーバー上（127.0.0.1）から、WP-CLI にてプラグインを２度アップデートしたと記録に入っていますネ！その通り！

管理画面からプラグインを停止・有効化してみたら




ホウホウ、筆者端末のIPアドレスから、ユーザー kitani （筆者）で Antivirus プラグインを停止したと。

あれ、「なし」が入っているのはバグかな (^^;　って思ったら、こちらの特定１サイトのみの現象でした。これはこのプラグインではなく別の何かに原因がありそうですね。

WP-CLI から バックアップ > プラグイン更新 > コア更新 > 翻訳更新 > プラグイン更新 をしてみたら




むむ、コア更新 > 翻訳更新しか記録されていませんね。
なぜかを検証してみましょう。

まずバックアップから翻訳更新までは、ちょっと特殊な更新方法をしています。
（wp は /usr/local/bin/wp）

  1. wp backwpup --jobid=ID番号
  2. wp plugin list | cut -d '|' -f 2 | awk '{print "/usr/local/bin/wp plugin update "$1}' | sh
     ※アクティブプラグインだけ更新
  3. wp core update 
  4. wp core update-db
  5. wp core language update
  6. wp plugin list | cut -d '|' -f 2 | awk '{print "/usr/local/bin/wp plugin update "$1}' | sh 

という流れになっていて、赤文字のところだけが記録されています。

これを次のコマンドに変更して実行してみました。
  1. wp backwpup --jobid=ID番号
  2. wp plugin --all 
     ※アクティブプラグインだけ更新
  3. wp core update 
  4. wp core update-db
  5. wp core language update
  6. wp plugin --all 
するとプラグインも認識しました。
6番目は更新プラグインがないのでログには記録されていません。
※２度目のプラグイン更新の意味は、時々 WordPress の新バージョンのみ更新可能なプラグイン（プラグイン新バージョンが新しい WordPress を求めている場合）があり、新バージョンにしてから更新リストに出てくる時があるため。



個別のプラグイン更新（wp plugin update ◯◯）はちゃんと登録できているので書き方なんですかねぇ。まぁもうcut を使ってアクティブプラグインだけ更新するのはやめたのでいいんですけどね。
※なお cut などを間に挟むようなことをしていたのは、特定プラグインを除くなどの目的だったのだが、wp plugin update --all --exclude=logbook などで logbook 以外のプラグインすべてをアップデートとかできちゃうので、もう不要なのですよね。

２，３のサイトで数日テストして問題ないようなら、
【備忘録】WP-CLI エイリアスを利用したリモートサーバーの WordPress 管理 #wckyoto2017
を参考に、
wp @all plugin install logbook
wp @all plugin activate logbook
で手持ち端末から WordPress やサーバーにログインせずに、一括インストールと有効化するかなー

ってことで終わりにしようと思いましたが、このプラグイン、日本語化されていないのですよねぇ。個人的には翻訳不要なのですが、翻訳する分量が 70ぐらいなので翻訳してみるかぁと思ってやってみました。

LogBook プラグインの翻訳




最近の WordPress プラグイン翻訳は、https://translate.wordpress.org より手軽にすることができます。自分のプラグインならどのような場面でその言葉を使っているかわかっていますが、他人が開発したプラグインは、その利用場面によって翻訳内容が変わるときがあります。
また翻訳するにあたっては、


を参考に、長音文字、受動態はできるだけ能動態へ変換する、半角文字と全角文字の間には、半角文字1字分のスペースを入れる、などのよくあるものに特に注意を払いながら訳していくことになります。
翻訳（実際には提案）が完了したら、日本語版 WordPress Slack の #requests チャネルで翻訳の承認を依頼します。そうすれば、翻訳の達人の皆さんがチェックをしてくださることでしょう、きっと。最終的には、承認権限をもっている方によって承認されれば、めでたくみんなが使えるようになるってことです。

各プラグインの翻訳トップページに移動するには、各プラグインのダウンロードページにアクセスし、下記のように出てくれば、まだ日本語翻訳されていないことになります。


下図のように表示されれば、少なくても一度は翻訳済みになります。
ただし、プラグインが更新されていくなかで、翻訳が不十分になっているケースもあります。「Help translate it!」あるいは「翻訳の改善のご協力ください」のいずれかのリンクをクリックすることでそのプラグインの翻訳トップに移動します。


LogBook は翻訳して承認待ちなので、Waiting に入っています。



すでに 100%翻訳されていて、承認済みの場合には下記のように 100% の表示になります。



確か 95% を超えて、これが承認されればプラグイン本体に翻訳が反映されるようですね！


2017年11月16日 @kimipooh

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

2017年9月17日日曜日

WordCamp Tokyo 2017 に参加して（二日目 コントリビューターDAY） #wordcamp #wctokyo

台風が関西に近づいてます...
その影響でコントリビューターDAYは午前中のみにして、昼から帰ることにしました。
ちょっと残念ではありますが、明日は外せない用事があるので安全を取ることにしました。だからといって、コントリビューターDAYで手を抜くわけではありませんよ！



会場にはお菓子も結構な種類用意されてました！



楽しそうにやってますね！
結構な人数が参加したなぁという感じです。

複数の公開 Google カレンダー をマージして 一覧表示するプラグインを公式プラグインにアップしてみよう！


様々なプロジェクトなどに関わっているとイベントも盛り沢山で、１つの Googleカレンダーで管理するには限界が生じます。ならばマージして一覧表示してしまえばいいんじゃね？という発想です。仕事では現時点では１つの Googleカレンダーの各イベントにハッシュタグを作って、言語判別（#lang）、主催者（#organizer）、種別（#type）などをどんどん追加することで管理するようにしてます。しかし、いずれは破綻するでしょう。そのため複数カレンダーをマージするのは必須なのです。

そこで筆者が仕事で利用するのに開発し公式プラグインにアップしているプラグイン「Google Calendar List View」について公開された複数 Google カレンダーからデータを取得し、それをマージして一覧表示する機能を付与してみたいと思います。

本当は一日あれば、List View for Posts という、これまた筆者が仕事で利用するのに開発した公式プラグイン（固定、投稿、カスタム投稿を纏めてマージして一覧表示、さらにカテゴリーやタクソノミーによるカテゴリー表示もできる）について、RSSもマージしてやるかぁとおもっていたのですが、それはまた別の機会にすることにします。

どうやって実装する？


すでに１つのカレンダーからの一覧表示は完成しています。
そこに複数のカレンダーをいかに設定してもらうかがキーになります。
手軽にやるには、ショートコードにカレンダーIDを複数設定してもらうことですね。できれば Calendar APIもカレンダーごとに複数設定できればよしです。なぜなら、Calendar APIの一日のクエリが 100万クエリと制限（無料で利用できる範囲）されているためです。

[gc_list_view g_id="Google カレンダー ID"  g_api_key="Google Calendar API"]

が基本的なショートコードの形です。
これを複数設定できるようにするためには、次のようにするとよいかなと思います。

[gc_list_view g_id="Google カレンダー ID"  g_api_key="Google Calendar API" g_id_2="Google カレンダー ID 2"  g_api_key_2="Google Calendar API 2" ]

つまり、 g_id_任意  と g_api_key_任意 で名前がユニークならそれをもってGoogleカレンダーからのデータ取得を試みるっていう実装方法ですね。これなら苦労はしなさそうです。

新幹線から参戦！




12時過ぎに大枠では実装できました。
しかし台風が近づいているのでタイムリミット。WordSlack の #plugin に上記コメントを残して 会場を後にしました。

でもふと思いました。新幹線からでも参戦できるじゃん！

そして Twitter に参戦するぜ！ってコメントして、実際に参戦しました。

ネット遅すぎる・・・

と悶ながらも、
  1. プラグインのアップデート
  2. プラグインの翻訳（アップデートしてから20〜30分ぐらいで翻訳可能になる .. GlotPress に対応している場合）
  3. ドキュメント書き換え（日本語と英語）
  4. 本ブログの作成と公開
「４」以外は 15時30分の発表までに間に合ったぜぃという感じです。


で実際のスライドはこちら


そのうち SlideShareに移動するかも。とりあえず時間がなかったので、Google スライドのやつをそのまま公開しました。

なんとか公開までいけてよかったです。。。

2017年9月17日 @kimipooh
投稿者 時刻: 0 件のコメント:
ラベル: ,

2017年9月1日金曜日

WordPress 公式プラグインに PHP 対応バージョンを表記できるように（でもまだ必須じゃない）


まだ単なる表記だけのようですが、そのうち必須になる流れなのかなと思います。
現状 PHP7 以降しか使えない三項演算子「??」が使いたくてウズウズしていたので、必須になったら気兼ねなく使えそうですね！




書き方


WordPress公式プラグインリポジトリが対応PHPバージョンの表記に対応（@高橋 文樹 氏）

などに詳しく説明されていますが、筆者自身への備忘録のためここでも説明しておきます。

readme.txt に「Required PHP: バージョン」を追加せよ！
ってことですね。実際には下記のような感じです。
このプラグインは PHP 5.3 以降（三項演算子 ?: 使っているので）が必須ですが、PHPのサポート状況を考えることとテスト環境が PHP 5.6.x と 7.0.x と 7.1.x なので、表記するなら PHP5.6 からかなぁと。




これが Required at least （WordPress のバージョン）のようにインストール時の必須項目になったら、三項演算子「??」をつかいまくってやる！！


と密かに思っているのでした。
ちょうど、 PHP カンファレンス 関西 2017 で三項演算子についてまともに話を聞いて、それから三項演算子ファンになってしまったのでした。ただ PHP 5.3や 5.6では ?? が使えないのですよね。

もし $hoge["foo"] が確実に存在するなら、
$hoge_foo = $hoge["foo"] ? $hoge["foo"] : "none";

を

$hoge_foo = $hoge["foo"] ?:  "none";

とかけるのだけど、存在しない場合があるなら未定義エラーになります。
ので、下記のように書かざるをえないわけですが、

$hoge_foo = isset($hoge["foo"]) ? $hoge["foo"] : "none";

PHP7から実装された ?? を使えば、

$hoge_foo = $hoge["foo"]) ?? "none";
とスマートになるわけですよね。

そんなわけで、「Required PHP: バージョン」が必須になる日が待ち遠しいのでした。

2017年9月1日 @kimipooh
投稿者 時刻: 0 件のコメント:
ラベル: ,
登録: 投稿 (Atom)