KINSTAへの道3

実際のサイトデータを入れてどうかチェックしていきます。

サイトキャッシュ問題

運用想定サイト:会員向けの動的コンテンツがメインでほぼキャッシュ利用できない。

前提:専用サーバーもしくは1CPU,1RAMでないとサイトキャッシュの無効化できないとのこと

→個別に依頼してキャッシュを無効化していただく必要がある。

一時保護のためのサイトパスワードプラグイン

サイト公開まで「Password Protected」プラグインでパスワード保護していることが多いのですが、キャッシュに引っかかりました。

→対象のクッキー情報を送ってパスしていただきました。(プラグインの設定ページ記述されています。)

除外してもらうときの内容

Cookie 名:”bid_1_password_protected_auth”

動的にPDF生成しているページ

はい。キャッシュにヒットしました。

→依頼して除外

 

admin-ajax.phpでajax通信しているものってどうなのか?

無効化っぽい?です。回答あやふや。まあ、ちゃんと動いていたからいいや

 

 

結論:キャッシュが影響したらサポートに問い合わせしてキャッシュ除外をしていただく!!

 

この一択となりました。

 

 

KINSTAへの道2

今日は、kinstaにいれたサイトをdevkinstaを利用してローカルで作業を行ってみたいと思います。

 

道のり

1.devkinstaをインストールする(ここから)

2.kinstaアカウントでログインする

3.kinstaからデータを持ってくる

4.これで完成

 

で、開発作業はどうすればよいのか・・・

 

ちなみに、ローカルでも
・「All-in-One WP Migration」はNGです。

 

devKinstaの疑問点

まず、ステージング環境が必要??

ローカルで更新されたファイル、テキスト、メディアなどはどこまでkinstaへ反映させることができるのか?

選択肢としては、ファイルとデータベースという項目があります。
これはステージングからLIVE環境に反映でも同じようにあります。

テンプレートだけならファイル。

各種設定なら、データベースという感じで。DBの部分的なものは手動で反映です。

例:
プラグイン→反映
メディア→反映

まあ、そうですよね。

devKinsta or ステージング環境

どっちが開発しやすいのか・・・

Windows端末を利用しているのでその場合は、ステージングで開発したほうが利用しやすいのでは?って感じもしました。

ざっくりとローカルで作り、ステージングで整え、本番に反映?使い方は色々研究中です。

 

ステージングからLIVE環境への反映

思った以上に時間がかかるイメージです。

 

KINSTAへの道

WordPressのサーバーを追い求めていたらKINSTAに出会った。早速試してみようと思ったけど、いつも利用しているバックアッププラグイン「all in one migration」が利用できなく、「Duplicator」というプラグインを利用してくれとのことだった。

※バックアップとキャッシュ系プラグインはkinstaでは利用禁止のため、最初に削除しておく必要があります。

 

kinstaで公開されている方法になぞっています。

WordPress Duplicatorプラグインを使ってKinstaへ自力でサイトを移行する方法

 

1.kinstaへ移行するために。。。

1.まず本番と同じドメインでサイト準備する。all in one migrationでサイト複製

2.「1」のサイトで、「Duplicator」でデータを生成する

3.kinsta上は、WEBサイト追加だけを行い、WordPressはインストールしない。

4,「kinsta」のWEBサイトにSFTP等で接続して、「2」のデータ(installer.phpとZIPファイル)をアップロードする

5.「4」でアップロードしたinstaller.phpにアクセスする

6.kinstaのDB情報を入力する。
※先にPHPバージョンを合わせたほうが良い

7.サイトにアクセスする。一部停止になっているプラグインもあるので確認する。

8.「Duplicator」のファイルを削除する

これで、LIVE上にサイトが完了しました。やってみたら、すごく簡単でした。

 

2.kinstaで本番運用する

1.kinstaでドメインを追加する(ドメイン追加と確認のTXTレコードを追加する)。

2.プライマリドメインにする(ここでドメインの置き換えが行われる)

3.wp-config.phpの「WP_SITEURL」を確認する

前
define( 'WP_SITEURL', 'https://xxxxxxxxxx.kinsta.cloud/' );

↓

変更後
define( 'WP_SITEURL', 'https://本番用URL/' );

 

4.hostsをkinstaに向けて確認する

5.DNSレコードを変更して本番運用を行う。

 

3.kinstaから戻す・・・

「1.kinstaへ移行するために。。。」で行ってもよいかと思います。

あとは、Duplicatorプラグインの有料版で実施してもよいかと。

 

あれ・・・なんかみれない。。

悩んだ結果、自分のところのインターネット回線が問題だったようです。
別回線では問題なかった。

1時間以内にDNSレコードを切り替えたのがいけないかな???
時間が解決してくれた。

 

GoogleアナリティクスでUAで計測できなくなる件(2023年7月1日)

Googleアナリティクス管理画面を開いてみてあら、2023年7月1日からユニバーサルアナリティクスでは標準プロパティで新しいデータの処理ができなくなります。とのこと。

時間があるのでまだのんびりですが忘れてしまいそうな件です。

アナリティクスの管理画面に入って、プロパティで「GA4設定アシスタント」>「はじめに」をクリックして指示に従っていきます。

 

そうするとGA4の設定が追加されます。データストリームから測定ID(G-XXX)を取得します。サイトに設定し、受信できることを確認します。

 

 

WordPressからTwitter連携プラグインを使おうとしたけど使えなかった件

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年の11月とか12月以降にアカウント作った場合は「Essential」というランクのアカウントになるらしく、API ver2しか使えないそうで、V1を使うにはその上の「Elevated」(無料ね)のランクにアップデートしないといけないとのこと。

申請すれば使えるのだが、英語でなぜ使うのかをある程度の長文で記述が必要だった。

申請が通れば、問題なく利用可能だった。

とりあえずメモ。

 

 

 

SPFレコードは重複はNG

メールサーバーの電子メールの送信元ドメインが詐称されていないかを検査するための仕組みでDNSのTXTレコードに「v=spf…」って記載すると思うのですがこちらは、重複することができません。

 

それなので1行に記述しましょう。

 

気になった場合は下記のサイトでチェックしてくれます。

https://mxtoolbox.com/spf.aspx

Android端末のchromeのホームページをデバックするのに..

Android端末のホームーページのスタイルが適用されないなど発生したときにデバッグするのがめんどいなって思っていましたが

 

パソコンのchromeから操作できる方法を知り快適になりました。

 

手順

1.設定アプリを開く

2.「システム」>「詳細設定」>「開発向けオプション」を開く

3.開発用設定をオンにする

4.USBデバッグモードをオンにする

5.PC版「chrome」から下記の内容をアドレスバーに入力します。

chrome://inspect/#devices

6.remote Targetに表示されるのでデバックしたいサイトの「inspect」を押して表示します。

※Android端末上も同じサイトが開いている必要がある

 

 

スタイルを変更すると反映されるので非常に便利です。

 

WordPress5.3以降で大きな画像が強制的に小さくアップロードされるようになっていた

あんまりアップロードすることがないのですが、2560px以上の画像をアップロードした場合は、ワードプレス5.3から強制的に2560pxのサイズにリサイズされてアップロードされるようです。

 

元記事はこちら

 

大きい画像のサイズを無効化するには下記のコードをfunction.phpに追記すればOK

add_filter( 'big_image_size_threshold', '__return_false' );

 

 

2560px以上の画像って稀な感じもするけど。。。