[enomoto]

ちょっと原因がわかってきました

AMPプラグインの動作モードによる違いと思われます。Reader(classic mode) だとAMPに変換出来ると思いますが、Transitional だとAMP変換前の出力をキャッシュしてしまっているようです

キャッシュするための ob_start() 関数の実行タイミオングが AMP プラグインより後のタイミングとなってしまっているのが原因と思われます

AMPプラグインでは、template_redirect フックで ob_start を呼び出し、shutdown フックで通常の HTML を取得して、それを AMP HTML へ変換するという、なかなかのエグいタイミングで処理しています

従って、AMPプラグインより先に ob_start させることで、AMP HTML 変換後の出力を取得し、キャッシュすれば良さそうです。

修正と確認にはちょっと時間がかかりそうなので対応バージョン公開（数日中）まで少しお待ち下さい

 

[enomoto]

この情報だけでは原因ははっきりしませんが、いずれにせよAMPで問題が出るといることはCSS絡みと思われます

正常に機能しないというのはどういう状態？CSSがあたっていない感じですか

不具合はすべてのページ、あるいは特定のページだけでしょうか？

“CSS ファイルを非同期ロード / CSS Tree Shaking で縮小して埋め込み”  の設定を有効化していましたか

この設定を無効化してどうなるか試してみてもらえますか？

この設定を有効化するとCSSの非同期ロードのためCSSのメディア属性を最初に print にしているところか、あるいはCSS容量を削減するために未使用のCSSを取り除く CSS Tree Shaking 機能になんらかの不具合があるのかも知れません

 

 

[enomoto]

サイト少し拝見しました

メダカ日誌をほぼ毎日更新していて、とても頑張ってますね　(^^)

ちなみに一部背景画像が表示されていないページも見受けられたので、ブラウザキャッシュというよりも、サーバー側のキャッシュが働いていて反映が遅れているのだと思います（おいおい反映されると思います）

また、メニューやウィジェットに管理者ログインが表示されています。

すぐにどうこうという話ではありませんが、セキュリティーの意識が低いサイトと思われる可能性があるので消しておいたほうが良いです。

 

[enomoto]

Celtispackプラグインのトピックに追記されているようですが、おそらくテーマのことだと思いますので Celtis Speedy テーマへの質問としてお答えします

テーマの質問は、Celtis 製 WordPress テーマに関するフォーラムのほうにトピックを立ててくださるようお願いします

 

管理画面の 外観 -> カスタマイズ を開き、色にある背景色を設定すればOKです。

ちなみに、子テーマ(celtis speedy custom)をお使いの場合は、サンプルとして同包している style.css ファイル内で background: lavenderblush !important; が設定してあるのでまずは、これを消してください

そうしないとうまく反映されないです

背景画像の場合は、外観 -> カスタマイズ を開き、背景画像をセットすればOKです

変更しても変わらないよという場合は、ブラウザのキャッシュをクリアしてみてください

 

[enomoto]

返信が遅くなりました（承認待ちになっているのに気づかなかった）m(__)m

WordPress, bbPress、bbPress forum utility pack は最新版を使っていますか？

テスト環境で bbp-login ショートコードを使ってみましたが、ちゃんとログイン出来ましたので何か他の要因、キャッシュや jQuery/JavaScript 等による影響も考えられます

エラーのメッセージは、画像にある パスワードを入力してください/ユーザー名を入力してください　と出ているのでしょうか

ユーザー名、パスワードの前後に空白等の文字が入っていませんか？

ご使用のブラウザは何でしょうか、他のブラウザ chrome / firefox 等でも確認してみて下さい

 

 

 

 

[enomoto]

ver4.3.2 の不具合と言うことではなく、キャッシュを消したことによる一時的な高負荷の状態と思います

Celtispack のブログカードは oEmbed 埋め込みキャッシュを使っています。

WP Sweep の oEmbed Caches In Post Meta を実行すると Celtispack ブログカードのキャッシュも全て消されてしまいます

するとブログカードや youtube, Tweeter 等の埋め込みをしているページがアクセスされたときにブログカードを含めこれら埋め込みデータを外部サイトに再取得しに行きます

運用サイトで同時に複数ページがアクセスされると（ボット等でのアクセスも含む）そのページに埋め込まれているデータを一斉に再取得しに行くため負荷が高い状態が発生します

Celtispackを削除したところ落ち着いたとのことなのでかなり沢山のブログカードを埋め込まれていたのだと思われます

ページ毎のブログカードのキャッシュが全て作成されれば以降はキャッシュが使われるようになるので負荷はかからなくなります

ちなみに再取得できないブログカードのURLがある場合は、ページがアクセスされると再取得を試みますのでそのようなリンク切れのURLは記事中から削除するようにしてください

 

 

 

 

[enomoto]

ここは セルティスラボ製のテーマに関するフォーラムです

Celtispack プラグインに関するフォーラムは別途ありますので、今後はそちらへお願いします

ちなみに Twitter を埋め込んだ場合の拡張アイキャッチによるサムネイル画像の取得は、Twitter の内容により取得できる場合と取得できない場合があります

詳しくは、過去にも同じような質問にお答えしているトピックがありますのでそちらを参照してください

https://celtislab.net/forums/topic/instagram%e3%81%8b%e3%82%89%e3%82%b5%e3%83%a0%e3%83%8d%e3%82%a4%e3%83%ab%e3%82%92%e5%8f%96%e5%be%97%e3%81%a7%e3%81%8d%e3%81%aa%e3%81%84%ef%bc%8b%ce%b1/

 

[enomoto]

レスポンシブデザインでデバイスを区別せずに扱うのが一番わかり易い対応と思いますが細かいことにこだわるとなかなか悩ましい問題です

ここでモバイルとはなんぞやと改めて考えると

デバイスの違いによる下記のような差異が考えられます

1. 通信環境の速度と安定性（光通信等の有線 or モバイル回線や WiFi)
2. ユーザーインターフェースの違い（マウス or タッチパネル）
3. ブラウザ上の違い（マウスホバー等サポート対応CSSの違い）
4. 解像度の違い

WordPress標準のモバイルの扱いでは主に 1-3 を重視して iPad もモバイルに判定していると私は思っています。ここの部分による違いによりコンテンツや JavaScript, CSS を分けて扱えるようになっているので、YASAKANI キャッシュもこれに準じておくのが一番問題ないです

そこで４の解像度ですが、これはもう CSS のメディアクエリーで対応するということで良いのではないでしょうか

したがって、ktm さんの場合では、YASAKANIキャッシュをご利用いただくことを前提に考えるならば、スマホ用のCSS内でメディアクエリーにより解像度の広い ipad 等のタブレットに対応させるのが一番スッキリするのではないかと思います　(^^)

 

 

 

[enomoto]

過去のトピックまで見ていただいたようなので、Yasakani Cache のモバイル判定についての方針は知っていただけているものとして解答します

このプラグインとしては、 wp_is_mobile 判定と同等の判定を行っていて、それを変更する予定もありませんので iPad を特別に区別することはできません

キャッシュプラグインのプログラムが実行されるタイミングは、他のプラグインやテーマよりもずっと早いタイミングで行われるのでワードプレスのフィルターフック等の処理で対応することもできません

また、現在のキャッシュデータ処理の都合上、タブレットのキャッシュを分けるということも簡単にはできない状態です

唯一の対象方法としては、直接 YASAKANI Cache のPHPプログラムを書き換えることで、iPad をモバイルから除外するということは可能ですがおすすめはしません

以上を踏まえたうえでどうしてもという場合は、magatama_lv1.php の  409行目にある is_mobile 関数を書き換え ftp 等で差し替えるという手段がありますが、直接プログラムを書き換えると、YASAKANI Cache プログラムが更新したときに書き換えたところが元に戻ってしまいます

ちなみに、WordPress 標準で iPad はモバイルとして判定しているのですが、 あえて iPad をモバイルから除外したい理由とは何でしょうか？

 

[enomoto]

CSS preload 処理のバグを修正しました

ver2.2.5 に更新したので試してみてください

 

[enomoto]

YASAKANI cache の CSS preload 処理時にバグがあるようです

CSS中に url でファイルを読み込んでいる場合はインラインから除外しているのですが、その除外処理がうまく動作していないようです

連休明けには WordPress5.2 がリリース予定となっていますので、その動作検証と合わせて修正いたしますので、それまでの間は CSS preload をOFFのまま運用してください

 

[enomoto]

プラグインを停止してもダメということは、アフィンガー５のテーマだと何らかの問題が出てしまうということだと思います

推測ですが、画像を見るとCSSの内容がトップに表示されているようなので、おそらく一部のCSSがインラインで読み込まれるようになっていて、その部分がCSSとして処理できずに文字列として表示され、その為にSNSアイコンあたりのスタイルが当たってないと思われます

Yasakani Cache の CSS preload 非同期読み込み処理がうまく機能しない原因がなにかあると思いますが、アフィンガー５は有料テーマなので詳細な調査はできません

もし、テーマに高速化の設定として、CSSをインラインで読み込むようなものがあるのなら、それを無効化してみてはいかがでしょうか？

[enomoto]

Celtispack で提供していた Lazyload の機能ですが、次のバージョンでは削除致します

理由は、主に３つあります

１．フロント側での jQuery の使用を段階的に止める方向でいます。現在提供している LazyLoad は、かなり古いコードで jQuery に依存しておりモバイル等でのパフォーマンスもあまりよくありません。

２．現在 WordPress 5.0 から導入される Gutenberg という新しいエディターに対応したテーマを作成していまして（１２月初旬に公開予定）、テーマ側で Lazyload 機能を持たせました。この LazyLoad は、jQuery を使わずに仕組み的にもパフォーマンスがよいIntersectionObserverという機能を使っている Lozad.js をベースにする予定です

３．新しいテーマに合わせて、Celtispack 側でも Gutenberg に対応するために修正と機能の整理を行っています。

jericho さんがどのようなテーマを使用しているかはわかりませんが、Lazyload に関しては他の物をお使いになることをおすすめします　m(__)m

 

 

 

 

[enomoto]

WordPress の権限と bbPress のフォーラムの権限は別のものです

bbPress – Private Replies というプラグインは使ったことがないのでわかりませんが、bbPress forum utility pack プラグインにはオリジナル投稿者と管理者しか閲覧できないようにするような機能はありません

通常は、プライベート（非公開）の設定をすると、非登録ユーザーの閲覧は不可となりますが、登録済みフォーラムメンバーならだれでも閲覧できるようになります。

bbPress – Private Replies が別途リジナル投稿者と管理者しか閲覧出来ないような権限を追加していて、その使い方の問題と思いますのでそのプラグインのフォーラムへ問い合わせてみてください

 

[enomoto]

本来は勝手に置き換えるなんてことはないはずで、再現出来ればいいのですが…

原因はわからないけど何か想定外の問題がありそうですね

まったく思いつきませんが、何かわかったらここに返信しておきます　m(__)m

 

 

 

 

 

[投稿者]

投稿