フォーラムへの返信
-
投稿
-
お早いご返信ありがとうございます。
確かにJetpackをインストールしていましたので、頂いたURLから表示したページの真ん中あたりにある「ショートコード埋め込み」を「停止」してみました。
すると、今度は投稿画面〜表示したページの両方について「普通にインスタのURLを貼り付けただけの状態」で表示されてしまいました。（投稿画面ですでに埋め込みが生成されなかったのであれっとは思ったのですが）
Jetpackの埋め込みを停止しても、そちらの環境では動いていますでしょうか？私の設定が何か足りないのでしょうか・・・。
こんにちは。素人ですが教えてください。
今まではインスタURLを投稿のビジュアルエディタに貼り付けるだけで、その場でインスタ画像がエディタ上に表示され、アイキャッチボタンを押せばアイキャッチに表示されていたのですが、最近できなくなったようなのです。
以下のように「View this post on instagram」となり、このままではサムネイルを取得できないようです。
このまま投稿すると、問題なくインスタは埋め込まれ画像も表示されているのですが、アイキャッチは取得できないままです。
- 普通に画像をアップロードし、アイキャッチに設定することは可能です。
- 今まではできていた→いつの間にかできなくなりました。2018.9月くらい？
- Celtisは今現在の最新のものに入れ替えました。（Uninst→Inst）
Celtis側の問題というより、Instagramまたはembedの問題のような気もします。何かご存知の方がいらっしゃったら教えていただけませんか？
ご連絡が遅くなりました。
先週末に作業時間の確保ができたので、ブラウザのキャッシュクリア、.htaccess の点検など事前準備をしてから再び動作検証をしてみました。
Yasakaniキャッシュの「除外するページ」は有効状態、公開済みのフロントページの内容を更新したあと、別ブラウザでフロントページへ接続しました。
すると、これまでと動作状態が変わり即座に更新したフロントページの内容が表示されました。
.htaccess や php.ini の修正はしておらず、Webサーバーにキャッシュを残すような設定もしていませんでしたので、なぜ元に戻ったのかは分かっていません。この２か月間のモヤモヤはなんだったのだろう…(笑)
今回の件は、私の環境下による影響と判断いたしました。
貴重なお時間をいただき申し訳ございません。
また解決へのアドバイスを頂戴し有難うございました。今後ともよろしくお願い申し上げます。
enomoto さん
お手数をお掛けしております。
> 有償プラグインは確認できないので除いて、それ以外を同じにしてみましたが問題ないようです。
>
> プラグインの問題ではない可能性が高いですそうですか。やはり私の稼働環境に何か原因がありそうですね。
> 先程、ホーム／フロントページを除外する設定を確認してから
> キャッシュクリアをおこなったあと、フロントページの内容を更新して
> 他ブラウザで閲覧しましたが旧情報が表示されました
>
> これは、キャッシュクリアした後の最初のアクセスで旧情報が表示されたと言うことですか？
>やったことを書きますね。
【A】
「除外するページ」有効状態
↓
Yasakani:キャッシュをクリア
↓
(1) フロントページ …の内容を
(2) フロントページ …最新へ更新(MySQL格納)
※テーマの簡易ビューで更新状態を確認
↓
Webサーバーへ接続（別ブラウザで最初の接続）
↓
Webサーバーから降りてきたのは (1) 側のデータ…と言う手順でした。
このあとにキャッシュをクリアすると…
【B】
「除外するページ」有効状態
↓
Yasakani:キャッシュをクリア
↓
Webサーバーへ接続
(2) フロントページのデータが読み込まれ…
↓
Webサーバーから降りてきたのは (2) のデータ…になりました。
「除外するページ」の機能が有効状態ならばフロントページはキャッシュされない筈なので、上の例で言えば最新のフロントページ (2) 側が読み込まれ、Webサーバーから降りてくるのは (1) 側ではなく (2) 側になるだろうと考えています。
キャッシュをクリアすると (2) 側で降りてくるので、これがWebサーバーのキャッシュに残ってしまっているならば、私の場合だと堂々巡りに。事実、日頃の公開作業の手順では、【A】→【B】→【A】… の繰り返し状態です。(^^;)> ということは、YASAKANIでキャッシュデータが生成されていないのに旧データが表示される。すなわちリクエストはWebサーバーで処理されて、サーバーでキャッシュしたデータが出力されたと思われるのですがどうでしょうか？
> サーバーにそのような設定を行っていませんか今確認ができないのですが、記憶では特別にサーバーにキャッシュを”残す”ような仕掛けはしてなかった気がしています。勘違いもあるかもしれませんので調べてみます。
おそらく私の環境下だけで発生していることだと思います。
原因が掴みにくい流れになってきましたら、ご迷惑をお掛けしたくないのでクローズしたいと思います。enomotoさま
ご返事が遅くなりましてすみません。
お忙しいところサポートをありがとうございます。>> アクセスする度に Hit のみ表示されています
>
>これでわかるのは、少なくともブラウザ内でキャッシュが使われているわけではなくサーバーへリクエストが行われてYASAKANIキャッシュプラグインが応答したキャッシュデータが表示されているということです
>
>Webサーバー、プロキシー、ブラウザキャッシュ等の問題ではなさそうですなるほど、キャッシュ機能は動作していることが分かり安心しました。
> ということは、ぐるっと回って ホーム/フロントページを除外の設定がうまく機能していない可能性が高く WordPress の関数 is_home(), is_front_page() で誤判定している気がします
>
> あるいは、SQLite にキャッシュしたデータに何らかの不具合があるか？
>
> 念のために、メンテナンスモードのキャッシュクリアをして違いがあるか見ていただけますか？キャッシュクリアを毎回やっても、フロントページはキャッシュされてしまう状態です。
先程、ホーム／フロントページを除外する設定を確認してからキャッシュクリアをおこなったあと、フロントページの内容を更新して他ブラウザで閲覧しましたが旧情報が表示されました。また、ハードリセットも試みましたが結果は同じでした。※今確認ができないのですが、.htaccessファイルに圧縮絡みのコードは書いていなかったと記憶してます。こちらは後で確認します。
> また、支障がなければ使用しているプラグインを教えていただけますか？
メディア管理のプラグイン類を除いて、関係しそうな導入済みのプラグイン名を記します。
* は、有償プラグインです。—————————
Jetpack by WordPress.com
Nishiki Growing Beauty
* Nishiki GB Social
* Nishiki GB Share
* Nishiki GB Meta
* Nishiki GB Content
* Nishiki GB Aanalytics
WP Multibyte Patch
WP Total Hacks
Yasakani Cache
—————————JetPackは、サイトダウン時の通知機能のみ設定しています。
Nisiki GB は Nisikiテーマの専用プラグインです。関係するとすれば、Content あたりかもしれませんが、機能をOFFにしても症状は同じでした。
WP Total Hacks では、WordPressのVersionやwlwmanifestを書き出さない設定だけです。
Yasakani Cache は、全力で使用中ですｗ参考になりますでしょうか。
よろしくお願いします。
enomotoさん
お忙しいところご対応をありがとうございます。
—————
1.ホーム/フロントページを除外してアクセス
-> ログ上に “exclude_page” となり実行時間も１秒程度以上かかる2.ホーム/フロントページの除外をやめる
-> １回目のアクセス “Store” となり、やはり１秒程度以上かかる
-> ２回目のアクセスで “Hit” となり、キャッシュなので 数ms 程度3.ホーム/フロントページを除外
-> 再び “excluded_page” となる
—————お知らせいただいた手順で操作して試しました。
ログモードは「ログ＋統計」にもともと設定してあります。アクセスログの Type で確認したのですが、1度も exclude_page と Store は表示されませんでした。
アクセスする度に Hit のみ表示されています。根本的な確認のやり方が間違ってたらスミマセン。複数のWordPressを運用していますが（と言っても２つだけ）、それぞれ www直下に個別にディレクトリを作成して、単体のWordPressを構築して運用しています。なので、プラグインがディレクトリをまたいで影響するような構成にはなっていません。
enomotoさんのところで正常なのですから、私の動作環境に何等かの原因がありそうですね。
「さくら」か「他プラグイン」か「php.ini」周りか・・・、もう少し調べてみることにします。お手数をお掛けしました。
ありがとうございました。お世話になっております。
yamanomi さん、解決のヒントをありがとうございます。
enomoto さん、私のご質問の案件がクリアになって良かったです。先程、zlib.output_compression を OFFにして、8月上旬からOFFにしていたキャッシュ機能を再びONにして使用を再開しました。動作も問題なさそうです。
色々とありがとうございました。
今後ともよろしくお願いします。ご回答ありがとうございます！
ご指摘頂いた通り、設定ページで有効になっていませんでした;
設定し直して無事にタイプは表示されるようになったのですが、サムネイル画像が全て縦に並んでしまっています。…実はスライダーに特化したエフェクト効きまくりの有料テーマを使用していまして、以前から色んなスライダーを試しているのですが、どれもこのような症状になるので困っていました。
こちらのスライダーを見たとき、これなら！と思ったのですが、やっぱり同じ症状なってしまいました。これはもうテーマとの相性が悪いとしか考えられないのでしょうね…。さくらのレンタルサーバーでは以前、mod_deflateが使用できずwordpress等、phpを利用するユーザーはzlib.output_compressionを使って圧縮していた経緯があります。
そのへんの特殊な事情が今回の不具合が起こった理由だと思います。
お役に立ててよかったです！私もKenさんと同じくさくらのレンタルサーバーで利用しており、同じ状況になっていました。
このトピックを見つけて解決策がないこと知り自分でも原因を探ってみたところ、php.iniでzlib.output_compressionを無効にすると正常に表示されるようになりました。
htmlでphp実行を有効にしているのも関係しているのかもしれませんが、よくわかっていません。
もしzlib.output_compressionを設定しているのであれば試してみてはいかがでしょうか。お世話になります。
ご確認いただきありがとうございます。ご指摘頂いた事を踏まえ、色々と設定を試してみました。Wordpress管理メニューの[外観]-[カスタマイズ]-[サイト基本情報]はicoファイルを指定するとエラーになるので、jpgかpngになりますが、これだと反映されないのでしょうか？（実際されなかった模様）
次に、ファビコン関係のプラグインいくつかと<head>内に直接記載する方法を試しましたが、これらはhttpsから始まるURLを記載しても勝手に相対パスに置き換えられてしまいます。
<head>内にhttpから始まるパスを記載してようやくフルパス表記になりました。ただ、これでもブログカードの表示はすぐには変わらず、色々操作しているうちにいつのまにかブログカードに反映されていたので、結局何が原因なのか良く分からない状態です。
その後、<head>内のパスをhttpからhttpsに変えてもブログカードの表示は問題なかったので、その状態で使おうと思ったのですが、一旦Celtispackを無効にして再度有効にしたところで、またブログカードへの反映がなくなりました。wp-content\uploads\celtispack\iconの中のファイルは残ったままです。
<head>内のパスをhttpに戻してもブログカードは変わらなかったのですが、パスをhttpにしたためか、ブラウザのURL欄に「安全でないコンテンツがブロックされました」の表示が。
「安全でないスクリプトを読み込む」を選択した後ページを再表示したらブログカードに反映された様です（正直色々いじっていたのでその辺りは少し曖昧ですが…）。
その後、<head>内のパス指定はコメントアウトし、プラグイン「All in one Favicon」を有効にして使っていますが、とりあえずは問題無い様なのでこのまま使ってゆきたいと思います。
お手数お掛けしました。ありがとうございます。
