Advanced Custom Fields(ACF)がバージョン6系になって、日付の戻り値がバージョン５と異なっていた。いやそもそもDBへの格納される値が異なっている。
バージョン６からは、「/」が入った日付型になっていてバージョン５は数字だけだったのでおいおいって感じでクエリ等で操作しているときは気をつけたほうが良い。
ファイルで使用していたフィールドの内容変更が反応しない（更新や削除）
フィールド名が異なると問題なく動作する・・・どうしたもんか・・・
っていうか、全体的にACFの内容の編集ができない。どうしてだ。
→WP FrontEndプラグインとACFの連携が有効になっていたため、更新できなかった。連携をオフにした。
kinstaでPHP7.4→8.1に変更してざっくりと速度を測定してみました。
なんでざっくりかというとホームページを制作途中のため、ざっくりなページでで試してみましたｗ
| PHPバージョン | HTML読み込み終了までの時間 |
| PHP7.4 | 1.25秒 |
| PHP8.1 | 0.952秒 |
ざっくりと24%速度が改善しています。PHPバージョンを変更するだけでこれだけ改善します。計測用に何度も行ったわけではないのでご参考までに。
※Chromeのデベロッパーツールで計測しました。
アクセス速度を改善したい場合はこれはやるべき事項ですね。
PHP8.1の効果が2022年11月9日時点で効果が確認できかなったので結果掲載はやめました( ;∀;)
「エックスサーバーで運用するときは最新且つ推奨のPHPバージョンを利用しているのがよい！！」
という本日の結論でした。時代とともに変わると思いますが・・・。
とりあえず、エックスサーバーでワードプレスを運用中の方はPHP7.4で今のところ行きましょう！
Ads by datafeedr.comを入れたままPHP8に変更したら、そのまま動作はするが管理画面でエラーが発生なのでざっくりと対応してみた。
なんだかんだ代替プラグインがないこともあるんでどうにかね。
配列の問題ね。厳格化になっていっているからね。
１．ワードプレスのデバックモードを有効にする
２．エラーのプログラムと行と内容を特定する
３．今回はPHP7系で警告出ていると思うから内容を確認。
４．配列の定義あるときとないときの対処の記述がないのでそのあたりをごにょごにょと記述する。
「(get_option( ‘dfads-settings’ )」の値がないのに「$output[‘dfads_enable_shortcodes_in_widgets’]」＝XXXXって
それはそれは怒られます。
ざっくりとemptyで判定しといた。
$output = array(
'dfads_enable_shortcodes_in_widgets'=>0,
);
if(!empty(get_option( 'dfads-settings' )))
{
$output = get_option( 'dfads-settings' );
}
もう１箇所出ていたから同じような感じで。
あとは、phpの7と8で試してOKでした。
実用に向けて色々とやってみました。今回は、アップロードに関してです。
変更はできないとのこと。一時的なものは、SFTPなどでアップしてほしいとのこと。
配信サーバーに利用しようとしたんでないけど、動画ファイルアップロードしたいって言われたら、上記のことを言われた。動画配信は別サーバー使うけど。
速度が早い分気を使う点が多数あるので、単純に一般的な日本の共用レンタルサーバーからの移動は調整や作り変えなど必要によっては発生するかもしれません。
基本的にサポートは英語でしたが、Google翻訳でやりとりでOKでした。
実際のサイトデータを入れてどうかチェックしていきます。
運用想定サイト：会員向けの動的コンテンツがメインでほぼキャッシュ利用できない。
→個別に依頼してキャッシュを無効化していただく必要がある。
サイト公開まで「Password Protected」プラグインでパスワード保護していることが多いのですが、キャッシュに引っかかりました。
→対象のクッキー情報を送ってパスしていただきました。（プラグインの設定ページ記述されています。）
除外してもらうときの内容
Cookie 名:”bid_1_password_protected_auth”
はい。キャッシュにヒットしました。
→依頼して除外
無効化っぽい？です。回答あやふや。まあ、ちゃんと動いていたからいいや
この一択となりました。
今日は、kinstaにいれたサイトをdevkinstaを利用してローカルで作業を行ってみたいと思います。
１．devkinstaをインストールする(ここから)
２．kinstaアカウントでログインする
３．kinstaからデータを持ってくる
４．これで完成
で、開発作業はどうすればよいのか・・・
ちなみに、ローカルでも
・「All-in-One WP Migration」はNGです。
まず、ステージング環境が必要？？
選択肢としては、ファイルとデータベースという項目があります。
これはステージングからLIVE環境に反映でも同じようにあります。
テンプレートだけならファイル。
各種設定なら、データベースという感じで。DBの部分的なものは手動で反映です。
例：
プラグイン→反映
メディア→反映
まあ、そうですよね。
どっちが開発しやすいのか・・・
Windows端末を利用しているのでその場合は、ステージングで開発したほうが利用しやすいのでは？って感じもしました。
ざっくりとローカルで作り、ステージングで整え、本番に反映？使い方は色々研究中です。
→なんだかんだPCが重くなった気がしたので削除しました。ステージング環境で十分です。
思った以上に時間がかかるイメージです。
WordPressのサーバーを追い求めていたらKINSTAに出会った。早速試してみようと思ったけど、いつも利用しているバックアッププラグイン「all in one migration」が利用できなく、「Duplicator」というプラグインを利用してくれとのことだった。
※バックアップとキャッシュ系プラグインはkinstaでは利用禁止のため、最初に削除しておく必要があります。
kinstaで公開されている方法になぞっています。
１．まず本番と同じドメインでサイト準備する。all in one migrationでサイト複製
２．「１」のサイトで、「Duplicator」でデータを生成する
３．kinsta上は、WEBサイト追加だけを行い、WordPressはインストールしない。
４，「kinsta」のWEBサイトにSFTP等で接続して、「２」のデータ（installer.phpとZIPファイル）をアップロードする
５．「４」でアップロードしたinstaller.phpにアクセスする
６．kinstaのDB情報を入力する。
※先にPHPバージョンを合わせたほうが良い
７．サイトにアクセスする。一部停止になっているプラグインもあるので確認する。
８．「Duplicator」のファイルを削除する
これで、LIVE上にサイトが完了しました。やってみたら、すごく簡単でした。
１．kinstaでドメインを追加する（ドメイン追加と確認のTXTレコードを追加する）。
２．プライマリドメインにする（ここでドメインの置き換えが行われる）
３．wp-config.phpの「WP_SITEURL」を確認する
前 define( 'WP_SITEURL', 'https://xxxxxxxxxx.kinsta.cloud/' ); ↓ 変更後 define( 'WP_SITEURL', 'https://本番用URL/' );
４．hostsをkinstaに向けて確認する
５．DNSレコードを変更して本番運用を行う。
「1.kinstaへ移行するために。。。」で行ってもよいかと思います。
あとは、Duplicatorプラグインの有料版で実施してもよいかと。
あれ・・・なんかみれない。。
悩んだ結果、自分のところのインターネット回線が問題だったようです。
別回線では問題なかった。
１時間以内にDNSレコードを切り替えたのがいけないかな？？？
時間が解決してくれた。
Email Logというプラグインでメール送信履歴を残しているのだが、kinsta→Xserverへ「Duplicator」プラグインで戻したときに、日時が変わっているものがいくつかあった。
同じIDだが日時が異なる・・・。さして影響は無いのだが・・・
Googleアナリティクス管理画面を開いてみてあら、2023年7月1日からユニバーサルアナリティクスでは標準プロパティで新しいデータの処理ができなくなります。とのこと。
時間があるのでまだのんびりですが忘れてしまいそうな件です。
アナリティクスの管理画面に入って、プロパティで「GA4設定アシスタント」＞「はじめに」をクリックして指示に従っていきます。
そうするとGA4の設定が追加されます。データストリームから測定ID（G-XXX）を取得します。サイトに設定し、受信できることを確認します。
WordPressからツイッター投稿プラグインを導入して動作検証していたけど、認証できないとか、投稿からはツイートされるけど、カスタム投稿からツイートされないというとかプラグインによって動作が異なっていた。
「WP to Twitter 」「Social Media Auto Publish」「Twitter Auto Publish」のプラグインで同様に発生。
ログやエラーを見ていくと下記の内容が書き出されていた。
「You currently have Essential access which includes access to Twitter API v2 endpoints only. If you need access to this endpoint, you’ll need to apply for Elevated access via the Developer Portal. You can learn more here」
翻訳者いわく
「現在、TwitterAPIv2エンドポイントのみへのアクセスを含むEssentialアクセスがあります。 このエンドポイントへのアクセスが必要な場合は、開発者ポータルから昇格アクセスを申請する必要があります。 あなたはここでもっと学ぶことができます」
なんだかよくわかりません。
プラグインの使い方をネット上を見ても過去の記事焼き回しとかであまり情報がありません。
いろいろ調べていくと、2021年の１１月とか１２月以降にアカウント作った場合は「Essential」というランクのアカウントになるらしく、API ver2しか使えないそうで、V1を使うにはその上の「Elevated」（無料ね）のランクにアップデートしないといけないとのこと。
申請すれば使えるのだが、英語でなぜ使うのかをある程度の長文で記述が必要だった。
申請が通れば、問題なく利用可能だった。
とりあえずメモ。
iframeの件、セキュリティ上、ngnix初期は他ドメインからアクセスできないようなので設定方法をメモ代わりに残します。
・設定ファイル
/etc/nginx/conf.d/security.conf
下記の行をコメントアウト
#add_header X-Frame-Options SAMEORIGIN;
下記の内容に変更
add_header X-Frame-Options “ALLOW”;