Luxeritas 3.22.0.1 リリース
Luxeritas Theme 3.22.0.1 をリリースしました。
WP 6.0 で、ブロックパターンを登録しても投稿画面のブロックパターンに「Luxeritas block pattern」が表示されないという報告をもらったので修正。
SEO最適化、レスポンシブ、高カスタマイズ性、とにかく速い、無料の WordPress テーマ
Luxeritas Theme 3.15.0.3 リリースしました。 不具合報告 ...
Luxeritas Theme 3.7.2 をリリースしました。 Lightbo ...
Luxeritas 1.20-alpha リリース。 AMP に対応しました(ま ...
Luxeritas 2.2.3.1 をリリースしました。 細かい不具合の修正だけ ...
Luxeritas Theme 3.21.1 をリリースしました。 軽い不具合の ...
Luxeritas は、Web ページを高速に表示するための仕組みを多く搭載しています。 ...
Luxeritas では CSS に関する知識がなくとも、 WordPress の「外観 ...
Luxeritas では、テンプレートごとに、1~3 カラムを自由に設定できます ...
設計方針 Luxeritas の設計方針について。 文法エラーは出さない html5 以 ...
Luxeritas では汎用的にマークアップできる箇所には、schema.org で構造化...
選べる SNS シェアボタン SNS ボタンは、通常タイプの他にカラータイプとホ ...
Luxeritas は、安定したレスポンシブデザインを提供するために、 GitHubで最 ...
Luxeritas はボタン一発で簡単に AMP に対応できます。Luxeritas の AMP 対応は ...
PWA(Progressive Web Apps)を有効化すると Web サイトを、あたかも Web アプリのように ...
るなの ほしい物のリスト です
ディスカッション
コメント一覧
るな様
いつもお世話になってます、んにゃんにゃ(https://thk.kanzae.net/etc/note/t8679/)です。
今回は「提供元表示消去プラグイン」のfilesystem関連の記述が古いような気がしての質問なのですが、書き込む場所がここしか無いのでここに記載いたします。
【発端】
KUSANAGIサーバのPHPを7.4から8.0に上げ、同時に、それに必要なwp-config.php内の’FS_METHOD’値を’ftpsockets’から’ftpext’に変更したところ、
提供元表示消去プラグイン関連でFatal errorが発生しました
[ログなので管理者側で削除]
【当方で調べたことのまとめ】
有料プラグイン内の classes/filesystem.php を調べました。
add_filter( ‘request_filesystem_credentials’, ‘__return_true’ );の存在理由がわかりませんでした。
$creds = request_filesystem_credentials( $url, ”, false, false, null );が二重に定義されてるようでした。
という点が気になりましたが、WordPress公式 https://wpdocs.osdn.jp/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0API の書き方に沿っていて何も問題なく見えました。なのにエラーが出ます。
一方で、Luxeritasテーマ本体の各種ファイル書き込みには問題なさそうなので、本体のinc/thk-filesystem.phpを見てみました。
プラグイン内のclasses/filesystem.phpと大まかな記述は同一でしたが、大きく異なったのが$credsの二重定義が消えたことと、init_filesystem()内の49行目以降、この記述です。
// direct accsess
$access_type = get_filesystem_method();
if( $access_type !== ‘direct’) {
add_filter( ‘filesystem_method’, function( $a ) {
return ‘direct’;
});
//以下略
この16行分をプラグインの方にコピペし、$credsの二重定義を1つにしたら、あら不思議、Fatal Errorが消えてなくなりました…
中でもadd_filter( ‘filesystem_method’, function( $a ) {return ‘direct’;});の部分が重要みたいで、これをコメントアウトしたら再びFatal Errorが再発しました。
本来は’ftpext’なのに’direct’になぜ上書きしていいんだ…?と疑問ばかりです
この土日を使っていろいろ調べたのですが、私にはこれ以上のことはわかりませんでした。
KUSANAGIのファイルシステム周りが面倒なことはよく知られていますが、それを加味してもプラグイン側で対処できる問題のような気がしました
【お聞きしたいこと】
おそらく有料プラグイン内の classes/filesystem.php は記述のアップデートが必要だと思うのですが、どのようにするのがベストでしょうか?
有料プラグイン内の classes/filesystem.php とクラス名だけ変えた同一記載にして良いものでしょうか?
【当環境】
– PHP 8.0.19
– WordPress 6.0
– MariaDB 10.5.16
– nginx/1.21.6
– CentOS Linux release 7.9.2009
– AWS EC2 t3a.medium
– KUSANAGI Version 8.7.1-1
【蛇足】
ちなみに$access_type = get_filesystem_method();は’ftpext’が返ってきます。
$credsは、trueが返る場合と、ftp接続情報Arrayが返ることがあります
//direct accsess ←これ、スペルミスですね
欲しい物リストののこぎり、「この商品は、ほしい物リストなど、ギフト用に登録されたお届け先には発送できません。」とエラーが出て贈れませんでした…
落ち着いたらなにか他のものお贈りしますね
んにゃんにゃさん。
ありがとうございます。
本体の方は、ver 1.45 で修正したものです。ver 1.45 のリリース記事にある「KUSANAGI とかいう VPS だと~云々」って書いてあるとおりです。
プラグインの方で filesystem の記述があるの忘れてたので、そのままになってたみたいです。
本体の init_filesystem() の中身をそのままコピペするだけで良いかと思います。
るなさま
光速のご返信ありがとうございます。
まさか5年前の修正事項とは…恐れ入りました。
Luxeritas本体のinit_filesystem()の中身をそのままプラグインのinit_filesystem()にコピペし、どうやら無事に動いているようです。
誠にありがとうございました♀️
いつもいつも当方がbot判定されるので、返信が遅れ失礼いたしました。