WordPressのショートコードがそのまま表示されるとき｜書式・提供元・出力先の確認手順

WordPressのページに、角括弧で囲まれた文字がそのまま出る場合は、何度も貼り直す前に「コードの文字列」「それを処理する機能」「入力した場所」を分けて確認してください。ショートコード用のブロックへ入れただけで、どんな文字列でも機能するわけではありません。

この記事は企業の更新担当者と制作会社向けです。原本を保ち、一つの対象を確認して、書式の修正で済むか、提供機能や独自実装の調査が必要かを判断します。公開中のフォームや共有部品を、原因が分からないまま置換しないようにします。

1．文字の表示、空白、操作の失敗を分ける

どこで何が起きたかを記録する

記事のURL、編集画面、問題の位置、表示された文字、直前の変更を控えます。編集画面でコードが見えることと、公開画面でそのまま文字として見えることは別です。プレビュー、保存後の公開、ログインしていない閲覧で状態を分けてください。

文字列は出るが処理されない、文字は消えるが何も出ない、フォームなどは出るが操作できない、という違いも記録します。これらをすべて「ショートコードが無効」と同じ原因にしないようにします。

実際のコードか、説明用の例かを確かめる

説明記事の中には、コードの書き方を文字として見せる例があります。その例が公開ページに出ること自体は不具合とは限りません。機能を動かしたいのか、使い方を読者へ説明したいのかを先に決めます。

不明な文字列をインターネットから拾って実行せず、利用中のテーマやプラグイン、制作担当が案内した正式なコードを確認してください。非公開のIDやトークンが含まれる場合は、初回相談へ全文を貼る必要はありません。

2．変更前の本文と、必要な提供機能を残す

投稿の本文、問題箇所、公開表示、提供するテーマやプラグインの名前と版を保存します。復元する対象が投稿だけか、設定やファイルも含むかを整理し、戻せる範囲を確認してから試します。

過去の投稿で使うコードは、現在のトップページだけを見ても分かりません。機能を停止すると他の記事やフォームにも影響する場合があります。使われている場所が分からないままプラグインを一括停止・削除しないでください。

他の人の編集が続いている場合は、どの版を調べるかを共有します。元の投稿全体を古いリビジョンへ戻すと、問題箇所以外の修正まで失う可能性があります。一つのコードの修正と投稿全体の復元は範囲を分けます。

3．コードの書式と入力先を照合する

提供元の説明と文字列を比べる

名前、角括弧、属性名、引用符、必要なIDを、提供元の現行説明と比べます。手作業で全角へ置き換えた、文章用の装飾が混ざった、別サイトのIDをコピーした場合などは、元の案内と照合してください。見た目が似ているだけで同じ入力とは扱いません。

WordPressのショートコードAPIの説明は、登録した短い記述を機能の出力へ置き換える仕組みを示しています。サイトごとの独自コードや製品の属性は、その提供元の仕様で確認します。

ショートコード用ブロックで一つ試す

WordPress公式のショートコードブロックでは、ブロックを追加し、利用可能なコードを入力する手順が説明されています。コードを文字として見せるためのブロックへ置いていないかも確認します。画面の名称や使えるブロックは版と権限で確認してください。

試験は承認された下書きや検証環境で行い、複製側からメールや外部連携が動かないかも確認します。公開中の原本を何度も書き換えて調査する必要はありません。

4．コードを登録する提供元が動いているか調べる

書式が正しそうでも、コードを提供するプラグインやテーマの機能が使えなければ、期待した内容にならない場合があります。更新、テーマの切り替え、機能の停止、移転の前後で変わったかを調べます。直前の変更は手がかりであり、原因が確定した証拠ではありません。

制作担当は、提供元の仕様と実際の登録状態を確認します。shortcode_existsの公式仕様は、指定名のショートコードが登録されているかを調べる関数です。ただし、登録されていることは、属性や参照データ、フォームの送信先まで正常という意味ではありません。

調査用のPHPを一般公開ページへ貼ったり、強い権限を全員へ与えたりする必要はありません。変更が必要なら、依存する箇所と影響を整理して担当者が試験します。提供機能の削除を予定する場合も、使用先を先に把握してください。

5．空白になる場合は、出力する内容と配置を調べる

文字列は消えるのに何も出ない場合は、コードが参照する対象の有無、公開範囲、属性、表示条件、出力後のHTMLとCSSを確認します。何も出ないから登録がない、と即断しません。ログやエラーを採取する場合は、必要な範囲を担当者と決め、個人情報や認証情報を公開しないようにします。

本文、独自の入力欄、ウィジェット、テーマのテンプレートでは処理が異なる場合があります。すべての文字列へ強制的にコード実行処理を追加するのではなく、使う場所と必要な機能を限定して調査します。

6．別の仕組みの不具合を切り分ける

ブロック編集時の「無効なコンテンツ」の警告なら、内容を保つブロック復旧の確認手順で、想定形式と保存内容の差を比べます。外部URLを貼っただけのカードや動画なら、埋め込みと通常リンクの違いから確認します。

本記事の対象は、ショートコードという記述と、それを提供・処理する仕組みの照合です。iframeの接続拒否、ログイン、メールの未着まで、同じ手順で直るとは説明しません。調査する層を分けると、どの担当へ渡すかも整理できます。

7．保存後の表示と、必要な実操作を検収する

修正は一つの対象から行います。保存して編集画面を開き直し、入力が残り、公開で必要な内容が出るかを確認してください。PCとスマートフォン、切り替わる幅で、画像、表、リンク、フォームが読めて使えるかを見ます。

フォームなら表示だけでなく、合意した試験方法で入力、エラー、完了、通知と受付を確認します。実際の注文や予約へ影響する送信は、許可した試験先と内容を用意して行います。ログイン済み管理者だけで使えたことを、一般の閲覧者にも使える証拠にしません。

同じコードの他の使用先、差分、変更日時、戻し方、残る課題を記録します。後続の編集があれば機械的に上書きせず、対象の版を合わせます。公開確認と検索順位や実相談の増減は別に扱います。

8．Acquaへはコードの提供元と困る操作を共有する

書式と入力先を比べて自社で直せる場合は、確認した方法を更新担当へ残します。登録状態、独自の出力、他の使用先まで調べる必要がある場合は、実装・保守の支援を検討できます。

企業の方はWeb制作・運用支援、制作会社の方はWordPress等の実装支援から対応内容をご確認ください。提供機能の調査、限定した修正、公開検収、引き継ぎの範囲を分けて相談します。対応可否や費用は個別に確認します。

相談窓口には、URL、コードの提供元、入力先、編集と公開の違い、直前の変更を分かる範囲で伝えられます。支援後に目指すのは、必要な内容と操作が公開で使え、担当者が提供元と更新・確認方法を引き継げる状態です。今回の点検方法は編集上の提案で、特定の顧客障害や復旧実績の報告ではありません。