すべてのプラグインを無効にして試しましたが、やはりファイルブロックでPDFは表示されませんでした。

ZUISHUNさん

いつの間にか「解決済み」になっています。
自己解決ということでしたら、コメントを残していただけますと助かります。

投稿者:: @zuishun

↑

https://www.bungaku-sekai.com/memory-of-yuki-watanabe/

の投稿ページをつくった時はファイルブロックでPDFの表示ができていました。

上記は、私からは、以下のように見えます。

フォーラム質問後、問題等が解決した場合は結果を書き込んでいただけると幸いです。同様の問題で調べている方には、結果が一番気になる部分となります。

僕の環境では問題なくPDFが埋め込み表示されているように見えます。自己解決されたと言うことなのかな。

https://www.bungaku-sekai.com/memory-of-yuki-watanabe/

の投稿ページをつくった時はファイルブロックでPDFの表示ができていました。

(上記、初回投稿よりの抜粋)

現在は、それができなくなっている、という意味です。

つまり、未解決なんです。

よろしくお願いいたします。

【付帯状況加筆】

現在新規でファイルブロックによるPDF表示ができないのであれば、

冒頭URLもエラーで表示できなくなっている、というのが、整合性の

とれたことのように思えるのは確かです。

ですが、上記URLでは依然、ファイルブロックにPDF表示がされてい

るのですが、固定ページや投稿ページに、新規でファイルブロックに

よるPDF表示をやろうとすると、リンクとDLボタンは表示されるもの

の、肝心のPDFはまったく表示されない状態です。

エラーメッセージのようなものは皆無です。

お世話をおかけいたします。

ZUISHUNさん

「未解決」にしておきました。

 
そして、すみません、良く分かりません。

投稿者:: @zuishun

↑

https://www.bungaku-sekai.com/memory-of-yuki-watanabe/

の投稿ページをつくった時はファイルブロックでPDFの表示ができていました。

(上記、初回投稿よりの抜粋)

現在は、それができなくなっている、という意味です。

つまり、ご提示のページは、正常だということでしょうか。

では、不具合の発生しているページは、どこ拝見すれば良いのでしょうか？
テストページで構いませんので、不具合の発生している状態を確認させてください。

URLのご提示をお願いします。
また、編集画面の状態が分かるキャプチャ画像（スクリーンショット）の添付もお願い致します。
（ブロックの設定状況が分かるような）

例えばですが・・・。
「TVが壊れました。何が原因でしょうか。」

上記のように修理窓口に相談するとします。
実際にそのTVを見せることなく、何が原因かを探れということはとても難しいことだと思います。

今まさに、そういう状況かと思います。
（正常な状態をご提示いただいても、不具合の原因を探るのは難しいです）

これは申しわけありませんでした、汗。

今、テストページをつくりました。

URLは、以下です。

https://www.bungaku-sekai.com/test-web/

キャプチャ画像も添付します。

@zuishun さん
テストページでは以下の様に”hidden”:非表示が指定されています。
<object data-wp-bind--hidden="!state.hasPdfPreview" hidden 👈これ

この部分だけ削除するとPDFは表示されますが、ここはご自分で非表示指定されていませんか？

<div class="entry-content cf" itemprop="mainEntityOfPage">
      
<p>正常表示の時と同じPDFをファイル・ブロックで表示しようと試みました。</p>

<div data-wp-interactive="core/file" class="wp-block-file">
	<object data-wp-bind--hidden="!state.hasPdfPreview" hidden class="wp-block-file__embed" data="http://www.bungaku-sekai.com/wp-content/uploads/2025/05/NL81all.pdf" type="application/pdf" style="width:100%;height:600px" aria-label="NL81allの埋め込み。"></object>
	<a rel="noopener" target="_blank" id="wp-block-file--media-99e80fc7-9e60-4024-89c5-a9d8e441fd01" href="http://www.bungaku-sekai.com/wp-content/uploads/2025/05/NL81all.pdf">NL81all</a>
	<a rel="noopener" target="_blank" href="http://www.bungaku-sekai.com/wp-content/uploads/2025/05/NL81all.pdf" class="wp-block-file__button wp-element-button" download aria-describedby="wp-block-file--media-99e80fc7-9e60-4024-89c5-a9d8e441fd01">ダウンロード</a>
</div>
</div>

根本原因は、SSLサイト（https）に関わらず、PDFのリンク先がhttpとなっているのが問題です。

以下のページですが、Safariでは表示されません。
URLでhttpが混在しエラーとなっているので見直し願います。

https://www.bungaku-sekai.com/memory-of-yuki-watanabe/

@zuishun さん

テストサイトですが、Edge、Chrome、Firefoxと表示されません。
原因は先述の通り。

WordPress公式テーマ「Twenty Twenty-One」に変更して確認してみました。
PDF埋め込ファイルですがSafariだけ表示されません。

@zuishun さん

「ファイル」ブロックで埋め込んだ場合、objectタグでpdfが埋め込まれます。
iOSはobjectタグだと表示されない場合があるようです。

●対応策

zuishunさんの他のページではプラグイン「PDF Embedder」を用い、PDFを埋め込まれており。

そのため以下の手順で対応できます。

• 「PDF Embedder」でPDFを埋め込む。
• 「ファイル」ブロックで「インライン埋め込みを表示」をオフとし、ダウンロードボタンだけを表示する。

ご指摘の方法は既に僕の方でも思い付いていました。最悪、どうにもならない場合はそれもあるなと思っていました。

さて、

結果をお知らせします。
問題は無事、解決しました。ファイルブロックでPDF表示がきちんとできるようになったということです。
操作としては、左ペイン：管理メニュー　Cocoon設定 → 「その他」タブ → 「簡単SSL対応」で、「内部URLをSSL化する（簡易版）」のチュックボックスにチェックを入れました。オンにしたということです。

これで、PDFファイルをメディアライブラリに読み込んだ時点では、httpであるものが、ファイルブロックでそのPDFを表示する時点では、httpsつまりSSL対応扱い（この表現が妥当か否か分かりませんが）となり、つつがなく表示されるようになりました。

一方、今回、お尋ねしていない、随筆春秋公式サイト　 https://zuishun.net/ 　では、メディアライブラリにPDFなどを読み込んだ時点で、URLはhttpsつまりSSL対応になります。

この辺のことを全然知らず全く拘りを持っていませんでした。
どうも、サーバーにWordpressを設定する段階で、初期からSSL対応を図った場合（随筆春秋公式サイト）と、そうでない場合（文学世界ドットコム）という違いが恐らくあるようですね。多分そんなところだろうと思っています、汗。

今回はとても勉強になりました。ありがとうございました。

本件はCocoonの不具合ではありせん。

@zuishun さん

ご指摘の方法は既に僕の方でも思い付いていました。

質問以前に、プラグインをオフにする、テーマを変更して確認するなど基本動作の徹底願います。

それと文学のこと書いている割に、第三者への文面が伝わり辛いです。

その点も注意願います。

「文学世界ドットコム」を立ち上げた頃からこの「ファイルブロックでPDF表示を行なう」が上手くいかず、ここ３か月ほどは原因も分からず悶々としていました。それとプラグインをすべて外すなどの操作はいろいろと試しています。httpとhttpsの件、大門様にご教示いただくまではまったく見当もつきませんでした。本当に助かりました。日本語は、もっと分かりやすく書くようにいたします。今回は、大変お世話になりました。

ZUISHUNさん

以下のページですが。

投稿者:: @zuishun

↑

https://www.bungaku-sekai.com/memory-of-yuki-watanabe/

「Mixed Content（混在コンテンツ）」の状態にあります。

 
まず、以下は警告です。

ご教示ありがとうございます。なるほど、そういうものなのですね。
今回はyoutubeなど調べまして、http https 混在解消の動画を閲覧しました。
そこで、自分の場合、初期設定すら間違っていることに気が付きました。
管理画面‐設定‐一般設定、において、添付画像の赤線の部分ですが、sを加筆してhttpsとしました。
Cocoon設定‐その他（タブ）の「簡単SSL対応」はチェックを外しました。
その状態で、ファイルブロックでPDFを表示することができました。
「管理メニュー」から「メディア一覧」を表示し、その中のデータ（画像ファイルや文書ファイル）のURLはどれもhttps～になっていることを確認しました。
恐らくこれでOKなのではないかと思います。

ZUISHUNさん

投稿者:: @zuishun

↑

自分の場合、初期設定すら間違っていることに気が付きました。
管理画面‐設定‐一般設定、において、添付画像の赤線の部分ですが、sを加筆してhttpsとしました。

そもそも、そこが「http」だったので、アップロードするメディアが「http」だったということですね。

投稿者:: @zuishun

↑

恐らくこれでOKなのではないかと思います。

そんなに甘いものではないです。
それで済むなら、皆苦労しないのですけれど。

現状は以下です。

1. http://www.bungaku-sekai.com/wp-content/uploads/2024/09/BIZUDPMincho-Bold.ttf
2. http://www.bungaku-sekai.com/wp-content/uploads/2024/08/ShipporiMincho-Bold.ttf
3. http://www.bungaku-sekai.com/wp-content/uploads/2024/09/KleeOne-Regular.ttf
4. http://www.bungaku-sekai.com/wp-content/uploads/2024/08/ShipporiMincho-ExtraBold.ttf
5. http://www.bungaku-sekai.com/wp-content/uploads/2024/09/KleeOne-SemiBold.ttf

提示していただいた、「混在コンテンツ警告」の内容を見ると、僕が自分で導入した、Webフォントばかりですね。これは、＜Fonts Plugin | Use Google Fonts, Adobe Fonts or Upload Fonts＞　というプラグインを介して導入したものです。よって当該プラグインをアンインストールしました。

その結果、「混在コンテンツ警告」がほとんどが消えました。

トップページの背景画像もこの「混在コンテンツ警告」に挙っていましたので、HP内から一旦削除して、外部サイトから、拾い直しました。結果はOKでした。「混在コンテンツ警告」が出なかったということです。

僕の場合、字体には拘りを持っていて（文学サイトなもので）、Googleフォントの「海星オプティ」（400,500,700）に執着しています。本家Googleフォントで「埋め込みコード」を取得して、HTMLとCSSでそれぞれ書き込みました。サイト全体に適用したいので、CSSでは、最初に、＜body＞という文字列を入れました。現在は、太さ400（Regular）を使っています。

これで　 https://www.bungaku-sekai.com/ 　の画面で「右クリック→検証」を行なった場合、「混在コンテンツ警告」は表示されなくなりました。

遡って、今回一番最初に「Ｘサーバー」内の設定を確認したのですが、幸いにも、こちらでは、SSL対応の設定が成されていました。以前僕自身が設定しました。

今回、「混在コンテンツ」という概念を始めて意識しました。「右クリック→検証」という操作も初目耳でした。そういえば、普段のネット巡回でも、「混在コンテンツ警告」がGoogle Chromeから表示されることが、よく、ありますね。これまではあまり気にしていませんでした。

これで安心していいのか、いまいち、確信は持てませんが、とにかく、今回は、勉強になりました。ありがとうございました。

●補足

「ファイル」ブロックのPDFの「インライン埋め込みを表示」の際、注意書きが表示され。
WordPressの仕様のようです。

ご忠告ありがとうございました。おっしゃるようにWordPressにてファイルブロックでPDF表示を行なうと「混在コンテンツ警告」が表示されてしまうのですね。添付ファイルにもあるようにこちらの環境でも試してみました。

https://www.bungaku-sekai.com/30923-2/

ZUISHUNさん

投稿者:: @zuishun

↑

WordPressにてファイルブロックでPDF表示を行なうと「混在コンテンツ警告」が表示されてしまう

そんなことないですよね？
どういう風に理解なさっているのでしょうか？
（日本語の表現がおかしいだけ？）

 
非SSL（http）のメディアを使用しているからですよね。
（これまでの画像やフォントファイルと同様。ファイルブロックは無関係。）

「ファイル」ブロックのPDFの「インライン埋め込みを表示」の際、注意書きが表示され。WordPressの仕様のようです。（以上、大門氏の文章を抜粋）

と、大門未知子氏よりアドバイスがありました。

そこで、自分の環境でも試してみました。僕の書いた作品（Wordで書いた後PDFに変換）をアップロードしたところ、、大門氏のおっしゃるように、警告（混在コンテンツ警告）が右ペインに表示されていたので、ああそうなのかと思った次第です。

その大門氏のアドバイスに返信して、画像添付したのは、「心の叫び」というタイトルの僕の文章でした。今回は、その文書のメディアライブラリの中での有り様（といえばいいのでしょうか？）をキャプチャしたので添付いたします。

このPDFファイル＝コンテンツのURLは先頭が「https」となっています。これでSSL化が完了していると思っていいのですよね？

上記を、ファイルブロックで表示した場合、「右クリック＝検証」を行なうと、大門氏にお示ししたように「混在コンテンツ警告」が表示されてしまいます。

詳しくないので、確たる信念があって記述しているわけではありません。

ZUISHUNさん

理解が違います。

そして、私の先程の返信も、誤りがあります。

「Mixed Content（混在コンテンツ）」の警告が出ているのは、画像であり、PDFではないです。
（1つめの赤矢印、位置がずれていますね）

再編集していたら、間に合いませんでした。
続きです。
 

SSL化と非SSL化のコンテンツが混在することがよろしくない、ということは分かりました。
それが、ブロック・コンテンツと１対１に紐づいているものではないことも、分かっているつもりです。
そして、MK2様のおっしゃるように、お示しの「混在コンテンツ警告」が、*.jpgに対して出されているものだということ、画像より読み取ることができました。
こちらの、 https://www.bungaku-sekai.com/memory-of-yuki-watanabe/ 　ですが、現在の状況を添付しました。ウェブ上で「右クリック→検証」を行ない、右ペインのコンソールタブをクリックした状態です。
特に警告は出ていません。
MK2様がおっしゃっています。上記ウェブでは、ブロックコンテンツの警告は出ていませんよ、つまりSSL化しています。しかし、画像としては、非SSLです。ですから、スマホで閲覧した時には、このブロックコンテンツの部分が表示されていないでしょ、という論理なのでしょうか？
実は僕は、このところの、論理展開が、あまりよく分かりません。
（ちょっと席を外すので返信が明日になってしまうかもしれません、汗）

ZUISHUNさん

すみません、私もZUISHUNさんがお書きになった文章が、良く分からないです。

投稿者:: @zuishun

↑

こちらの、 https://www.bungaku-sekai.com/memory-of-yuki-watanabe/ 　ですが、現在の状況を添付しました。ウェブ上で「右クリック→検証」を行ない、右ペインのコンソールタブをクリックした状態です。
特に警告は出ていません。
MK2様がおっしゃっています。上記ウェブでは、ブロックコンテンツの警告は出ていませんよ、つまりSSL化しています。しかし、画像としては、非SSLです。ですから、スマホで閲覧した時には、このブロックコンテンツの部分が表示されていないでしょ、という論理なのでしょうか？
実は僕は、このところの、論理展開が、あまりよく分かりません。

「ブロックコンテンツ」とは何を指していますでしょうか。

そして、以下の文章ですけれど。

投稿者:: @zuishun

↑

しかし、画像としては、非SSLです。

これは何を仰っているのでしょうか？

以下のページに、非SSL（http）で読み込まれている画像はありません
  https://www.bungaku-sekai.com/memory-of-yuki-watanabe/  

ずいぶん昔のことになると思いますが。
webの通信に関することは、完全にSSL化すべしという方針になったと思います。

「Mixed Content（混在コンテンツ）」とは、完全にSSL化されていないということです。

SSL化（https）されたページの中に、非SSL（https）のリクエストが混ざっていることを指します。
（それが、「Mix」「混在」ということかと思います。）

「ファイル」ブロックやPDF表示自体とは、全く無関係です。

これてあっているのか・・・という気はしますが。

私はPC・スマホ共に、Chromeで閲覧しました。

すみません、先程の返信に誤記載が・・・。

https://wp-cocoon.com/community/postid/85524/

投稿者:: @mk2_mk2

↑

SSL化（https）されたページの中に、非SSL（https）のリクエストが混ざっていることを指します。
（それが、「Mix」「混在」ということかと思います。）

「ファイル」ブロックやPDF表示自体とは、全く無関係です。

上記ですが、以下が正しいです。
（青文字部分を修正しました）

SSL化（https）されたページの中に、非SSL（http）のリクエストが混ざっていることを指します。
（それが、「Mix」「混在」ということかと思います。）

「ファイル」ブロックやPDF表示自体とは、全く無関係です。

僕の場合、まったく理解が浅いので、本質論を知らず、上っ面を嘗めているような状態です。昔ながらの表現でいうと「見よう見真似」です。

さて、今、SSL化、非SSL化に関するサイトを少しだけ読み込みましたが、

「SSL化・非SSL化の根本は、文書ファイルや画像ファイルそのものではなく、どういう通信経路でそれを使っているかということである」

という理解でいいのですね。

「httpは、通信経路が暗号化されていないので情報漏洩の危険性がある。httpsは、通信経路が暗号化されているので一応は安心。httpとhttpsが混在しているサイトは、httpがボトルネックとなって、カード番号やパスワードなど情報が漏洩してしまう可能性がある。Google他各社でもここ数年、そういうSSL・非SSL混合サイトの撲滅を目指している。従って、これからウェブサイトを運営する個人や法人はそのことに注力すべし」

というようなことですよね。その事は理解できた、と思います。

もう全然本質からずれていると思います。

webを読み込む際、ページ自体にURLがあると思います。
しかし、それ以外にも読み込むものがあります。
それらもすべてがSSL化（https）されている必要があります。

例えば、画像を表示するには、画像を読み込む必要があります。
画像のデータがどこにあるか、URLが埋め込まれています。
それも、SSL化（https）されていないとダメということです。

例えば、以下のページですが。
（このページに問題がある訳ではありません。例として挙げただけです）

https://www.bungaku-sekai.com/memory-of-yuki-watanabe/

アイキャッチ画像を表示するために、URLが埋め込まれています。

繰り返しますが。

以下の件。

投稿者:: @zuishun

↑

ご忠告ありがとうございました。おっしゃるようにWordPressにてファイルブロックでPDF表示を行なうと「混在コンテンツ警告」が表示されてしまうのですね。添付ファイルにもあるようにこちらの環境でも試してみました。

https://www.bungaku-sekai.com/30923-2/

「WordPressにてファイルブロックでPDF表示を行なうと「混在コンテンツ警告」が表示されてしまう」
そうではありません。

混在コンテンツが警告されているのは、以下のJPEG画像です。

https ://www.bungaku-sekai.com/wp-content/uploads/2024/11/31066591_m.jpg

PDFではありません。

既に該当ページが404で閲覧できませんので、ZUISHUNさんが添付なさった画像のメッセージから、目視で手打ちしています。

webを読み込む際、ページ自体にURLがあると思います。
しかし、それ以外にも読み込むものがあります。
それらもすべてがSSL化（https）されている必要があります。

例えば、画像を表示するには、画像を読み込む必要があります。
画像のデータがどこにあるか、URLが埋め込まれています。
それも、SSL化（https）されていないとダメということです。

（以上MK2様書き込みから抜粋）

MK2様の書かれたこの部分と、僕の書いた以下の部分は同じ意味だと思いますよ。上のMK2様の書かれたことはよく理解できています。これを同じことをイメージして僕も以下のことを書きました。

「SSL化・非SSL化の根本は、文書ファイルや画像ファイルそのものではなく、どういう通信経路でそれを使っているかということである」

（当方書き込みから抜粋）

繰り返しになってしまいますが、

MK2様のいう、「画像のデータがどこにあるか、URLが埋め込まれています。それも、SSL化（https）されていないとダメということです。」というのは、その画像をウェブサイトで利用する際の通信経路が暗号化されていなくてはダメ、という意味ですよね。

こういうのもう止めませんか。
一応書きますけれど。

投稿者:: @zuishun

↑

上のMK2様の書かれたことはよく理解できています。これを同じことをイメージして僕も以下のことを書きました。

「SSL化・非SSL化の根本は、文書ファイルや画像ファイルそのものではなく、どういう通信経路でそれを使っているかということである」

この文章が理解できませんでした。
「通信経路」が、SSLや非SSLを表わすものとは、思いません。

通信の方式（プロトコル）が違うのです。
経路自体は同じに思います。

こういう風に、言葉の認識に違いがあるため、具体的な例を挙げて書いたということです。

これを書いている間に、追記されていましたので、こちらも追記です。

投稿者:: @zuishun

↑

その画像をウェブサイトで利用する際の通信経路が暗号化されていなくてはダメ、という意味ですよね。

私には、この意味が分かりません。

「http」で始まるものは、ものが何であれ、アウトということです。
（画像などのメディア・スタイルシート・Javascirpt等含め）

元々は、以下の件で認識が違いますよということだけなのですが。

＞もう止めにしませんか。
同意見です。僕もMK２様との言葉使いの違いを深堀する気は全然ありません。
一言でいって、MK2様が、技術者として正しい言葉を使っていると思います（そもそも僕は技術者の世界を本当には知らないので）

一応、僕自身の反省も兼ねてMK２様のご指摘と僕とのズレを以下にまとめてみました。問題提起ではありません。相変わらず分かってないな、と思われても全然構いません、汗。

MK2様の指摘――
「通信経路」がSSLや非SSLを表すものとは、思いません。通信の方式（プロトコル）が違うのです。経路自体は同じに思います。

これは技術的にも言語的にも非常に筋が通っていると思います。
実際、SSL/TLSの違いは「通信経路」そのものではなく、その経路上で使われるプロトコルの層における“暗号化の有無”にあります。

🔧 技術的に言えば：
- **通信経路（物理的な経路やIPルーティング）**は、SSLでも非SSLでも基本的に同じです。
- 違うのは、**その上で使われる通信プロトコル（HTTP vs HTTPS）**であり、HTTPSはTLS（旧SSL）を使って暗号化されているという点です。
つまり、「通信経路がSSLか非SSLかを表す」という表現は、厳密にはプロトコルの違いを、僕の場合は、“経路”という言葉で代用してしまっているということになります。

🧭 言葉の選び方の問題
MK2さんの意図は「通信の仕組みの違い」を指していたのかもしれませんが、僕が、「経路」という言葉を使ったことで、MK2様のように物理的・論理的な“経路”を想起する優秀な技術者（本当の職業は存じませんが）にとっては違和感があるのも当然です。

大体、以上のように理解しています。これぐらいで勘弁してください。

話を整理しますね。以下はMK２様に対するお礼というつもりで書きました。問題提起ではありません。
今回はとにかくありがとうございました。

【今回の経緯とお礼の気持ちを以下に記述します】

MK2様から、混合コンテンツの警告が多数出ています、と注意をされた。

1.　添付画像のようにＸサーバーでの初期設定はOKだった。SSLがONである。（添付画像参照）
2.　WordPress側、設定‐一般設定が間違っていた。httpをhttpsと修正を済ませた。
3.　MK2様から指摘された混合コンテンツ警告の大部分はGoogleフォントに関する通信経路だった。これは、あるプラグインで行っていたが、そのプラグインごと既にアンインストール済み。現在は、僕指定のGoogleフォントは、同サイトから「埋め込みコード」をコピーし、Wordpress側に、HTMLとCSSで書き込んでいる。
4.　MK2様から指摘された混合コンテンツ警告の残りの１点は、トップページ背景のイラストに関する通信経路だった。現在はこれを一旦削除し、外部コンテンツから拾い直し、現在は、SSL化された通信経路で画像を利用している。
5.　Really simple sslというプラグインをインストールし、設定はしないが（１度設定すると解除した時に問題が起こることあり）、分析のみ実行した。Ａ判定（Ａ＋が最高点）。

というところまで来ています。ありがとうございました。（用語の選定は間違っているかもしれませんが、その点はお察しください）

なお、これ以上のご返信は無用です。つき合わせてしまって申しわけありませんでした。お疲れになったことと存じます。
では。

ZUISHUNさん

スマホからですので、簡単に。

私は、webの専門家ではありません。

むしろwebに関しては素人で、このフォーラムに参加させていただいて、勉強させていただいています。

正確に伝えるためには、正しい言葉を使う必要があります。そのため、専門的と思われる言葉を使わざるを得ません。（そうすれば、読み手は言葉を覚えていくでしょうし、分からなければ調べて意味を知るはずです）

但し、言葉は伝わらなければ意味がありません。

そのため、表現を変えて、説明をしようと試みることも必要だとやっただけです。

言葉の認識が違う者同士では、そういうことも必要だと思います。

ただ、なぜここまで「Mixed Content（混雑コンテンツ）」の話ばかりになってしまっているのか、分からないです。

以下は関係ないんだとご理解ください。（「Mixed Content（混雑コンテンツ）」の話ではないです）

投稿者:: @mk2_mk2

↑

 

これは「Mixed Content（混在コンテンツ）」とは無関係ということです。

先に私が添付したテストサイトで、「ファイル」ブロックで、PDFを埋め込み表示しても、「Mixed Content（混雑コンテンツ）」になっていなかったと思います。それが証左かと思います。

それでは、日付が変わる頃にこのトピックはクローズさせていただこうと思います。

ああ、やっと分かりました。ご指摘の通りです。最初はブロック・コンテンツで、PDFが表示されない件でこのスレで質問をしました。その後、「Mixed Content（混在コンテンツ）」ということを知り、僕の関心は完全にコレに移っていました。それで僕はその方向性にどんどん話を進めてしまいました。これは僕のルール違反です。肝心の話題以外に、しかも断りも入れず、話を進めるのですから。もうしわけありませんでした。今回のすれ違いの原因はこの点ですね。やはり僕が原因でした。付き合わせてしまいもうしわけありませんでした。

ZUISHUNさん

いえいえ、最終的に伝わっているようであれば、幸いです。

私の書く文も、分かりにくい・伝わりにくいことが一因かと思います。
その点は反省材料かと思います。

それでは、クローズさせていただきますね。

ZUISHUNさんより、別トピックへ書き込みがありました。
このトピックの続きと思いますので、転記致します。

転記元は以下です。

「昨日、ブロックファイルにて、PDFを表示させようとすると、『インライン表示』をONにしていても、なにも表示されない」という僕の不具合カテゴリーの質問に対し、僕の誤った経験談を、そのスレッド内で公開してしまいましたので、ここで訂正をさせていただきます。
https://wp-cocoon.com/community/postid/85538/
 

「昨日、ブロックファイルにて、PDFを表示させようとすると、『インライン表示』をONにしていても、なにも表示されない」という僕の不具合カテゴリーの質問に対し、僕の誤った経験談を、そのスレッド内で公開してしまいましたので、ここで訂正をさせていただきます。

言葉遣いは端折らない様、なるべく正確、丁寧に書くつもりですが、至らない点などありましたら、申しわけありませんが、ご自分で補完して理解してください。

例：「通信回線による」という言い方……この場合、その通信回線の付帯事情まで含みます。例えば、通信回線は同じでも、その通信回線のプロトコルの違いのよる、といういい回しが正確である場合でも、その意味まで含むということです。これは、あくまでも、僕の書き言葉に関してです。ご了解ください。

まず、質問の現象が起きた原因は、Wordpressの「管理画面」の「設定」から「一般設定」と進んだとき、
◆WordPressアドレス(URL)、と◆サイトアドレス(URL)、の部分に記入するURLが「http」となっていることが原因でした。そのため、ブロックファイルで利用するPDFファイルのURLがhttp～となっており、Wordpressのセキュリティにはじかれたのだと思います。このURLを２つとも、httpsに修正をしたところ、問題は発生しなくなりました。「S」が付くか付かないかの問題でした。

これにともなって僕は誤情報を流してしまいました。ブロックファイルを使ってPDFを表示させた場合、その画面内容の「検証」を行うと、右ペインには「混合コンテンツ警告」が漏れなく発生しそれはWordpressの仕様と思われる、と書いてしまったことです。

端的にいって、これは僕の間違いでした。それに、この書き方ですと、「PDFファイルそのものが悪さをしている」というニュアンスになってしまいます。理屈の分かった人には、「あなたこの件、一体、どう理解しているのですか？」という大きな疑問を抱かせてしまいます。

僕は、「随筆春秋ポータルサイト」（ https://zuishun.net/ ）と「文学世界ドットコム」（ https://www.bungaku-sekai.com/ ）の、２つのサイトを開発・運営しています。その両者で、ブロックファイルを使い、PDFファイルの表示を試したところ、「混合コンテンツ警告」はどちらの場合でも、発生しませんでした。

この点、訂正させていただきます。同じ疑問を持った方々に少しでもお役に立てばと思い書かせていただきました。

では。

上記の転記について、少し訂正させていただきます。

「ブロックファイル」との記載がありますが、「ファイルブロック」のことと思われます。

投稿者:: @mk2_mk2

↑

そのため、ブロックファイルで利用するPDFファイルのURLがhttp～となっており、Wordpressのセキュリティにはじかれたのだと思います。

「Wordpressのセキュリティにはじかれた」は、誤りかと思います。

WordPress側からは、「http」の状態で、HTMLは出力されています。

「Mixed Content（混在コンテンツ）」で、読み込みをブロックしたのは、ブラウザ側です。
（This request has been blocked）

投稿者:: @chu-ya

↑

投稿者:: @mk2_mk2

↑

「混合コンテンツ警告」

上記のような記載がありますが。
今回の元々の事象では、「エラー」です。（警告ではありません）
（この直上の画像の通り）

「エラー」になって、読み込みがブロックされています。
（This request has been blocked）

「Mixed Content（混在コンテンツ）」は、警告になる場合と、エラーになる場合があります。

 
【ご参考】

混在コンテンツ
https://developer.mozilla.org/ja/docs/Web/Security/Mixed_content
  

投稿者:: @mk2_mk2

↑

その両者で、ブロックファイルを使い、PDFファイルの表示を試したところ、「混合コンテンツ警告」はどちらの場合でも、発生しませんでした。

昨日、何回か記載・画像添付させていただいた通りです。

投稿者:: @mk2_mk2

↑

メディアがSSL化(https)されていれば、ファイルブロックでも問題ないですよね。

ファイルブロックを使用すると、「Mixed Content（混在コンテンツ）」になる訳ではありません。
（メディアが非SSL（http）であることが問題）