ワードプレスの個別投稿にjavascriptを入れるならカスタムCSSとJSを使うのが正解

ワードプレスの記事内で、ちょっとした動きを加えたいと思ったことはありませんか？
たとえば、ボタンを押すと色が変わるスクリプトや、
シンプルなカウントダウンなどを記事単位で動かしたいとき。
そんなときに便利なのが「カスタムHTML」ブロックですが、
実際にそこへ javascript を直接書いてもうまく動かないことがあります。

私の環境ではテーマに Cocoon を使用しており、
ブロックエディタとの相性や読み込みの順番によって、
スクリプトが反映されないケースがいくつかありました。
調べてみると、ネット上の記事の多くは
「functions.phpに追記して全体に反映させる」方法ばかりで、
個別投稿限定で動かしたい場合の情報は意外と少ないのが現状です。

その後、プラグイン「Scripts n Styles」も試しましたが、
ページが重くなり、思うような結果は得られませんでした。
最終的にたどり着いたのが、カスタムCSS・カスタムjavascript・カスタムHTMLを分けて使う方法です。
このやり方なら、Cocoon環境でも軽く安定して動作し、
記事ごとに好きな機能を組み込むことができました。

前提とよくある原因｜Cocoon環境でjavascriptが動かない背景
個別投稿でjavascriptを安定して動かすなら、CSS・JS・HTMLを分けるのがコツ
実践例｜カスタムCSS・カスタムjavascript・HTMLの分け方
まとめ

前提とよくある原因｜Cocoon環境でjavascriptが動かない背景

ワードプレスの記事にカスタムHTMLブロックでjavascriptを入れてみても、
なぜか動いたり動かなかったりすることがあります。
私も最初は原因が分からず、同じコードを複数のページで試して検証しました。
その中で分かったのは、「コードそのものよりも、読み込みの仕組みや出力の処理が影響している」ということです。

まず、投稿エディタで入力した内容は、そのままHTMLとして出力されるわけではなく、
WordPress側で一度整形されてからページに反映されます。
その過程で<script>タグが自動的に除外されたり、
安全対策として無効化されたりすることがありました。
つまり、コードが正しくても「WordPressが保護的にブロックしている」ケースがあるわけです。

また、スクリプトの読み込みタイミングも大きく関係します。
DOMの生成より前に動作するコードはエラー扱いとなり、
実行されないまま終わることがあります。
Cocoonは高速化設定や遅延読み込みなどが多く組み込まれているため、
処理順のズレによって意図しない挙動になることがありました。

もう一つ気づいたのは、ブロックエディタ特有の整形処理です。
エディタが改行やpタグを自動で挿入することで、
スクリプトが分断され、構文エラーになることもあります。
これはテーマによらず、WordPress全体の仕組みとして起こりやすい部分です。

こうした点を踏まえると、「Cocoonだから動かない」というより、
WordPressのセキュリティ設計やエディタ構造が影響していると考えた方が自然です。
仕組みを理解したうえでコードの書き方や配置を工夫すれば、
記事単位でも十分にjavascriptを動かすことができます。

個別投稿でjavascriptを安定して動かすなら、CSS・JS・HTMLを分けるのがコツ

ワードプレスの記事でjavascriptを動かすとき、最も多いトラブルのひとつが「すべてのコードをカスタムHTMLブロックに詰め込む」方法です。
見た目はシンプルに見えますが、このやり方はWordPressの自動整形処理や安全制限の影響を受けやすく、
結果としてスクリプトが正しく実行されないことがよくあります。

私自身、最初はHTML・CSS・JSを1つのブロックにまとめていましたが、
構文が途中で分断されたり、pタグやbrタグが勝手に挿入されてスクリプトが壊れたりする現象が多発しました。
WordPressのエディタは「安全なHTMLを維持する」ために内部的にタグを補完するため、
スクリプトがその処理に巻き込まれてしまうのです。

そこで有効だったのが、コードの役割ごとに分けて書く構成です。

カスタムHTMLブロック：呼び出し部分（ボタンやdivなど構造だけ）
カスタムCSS欄：見た目や配置を指定（色・フォント・余白など）
カスタムjavascript欄：動作の指示（クリック時の動きなど）

このように分けることで、HTMLは構造、CSSはデザイン、JSは動作を担当し、
それぞれの処理が独立するためエディタの整形による影響をほぼ受けなくなります。

特にCocoonには投稿ごとにカスタムCSS・カスタムJavaScriptの欄が用意されており、
これを使うことでテーマ全体を変更せず、記事単位で動作を制御できます。
この仕組みを活用すれば、functions.phpを触る必要もなく、
安全にスクリプトを実行できるようになります。

この方法は後からメンテナンスしやすいのも大きな利点です。
CSSとJSを個別の記事に分離しておくことで、
同じ処理を別の記事に使いたいときもコピー＆ペーストで再利用できます。
さらに、構造が明確になるため、後でコードを見返したときも修正箇所を迷いません。

実際に試してみると、Cocoon環境でもブロックに直接スクリプトを書くよりも安定して動作し、
読み込みエラーも大幅に減りました。
また、HTML部分が最小限の構造だけになるため、
ブロックエディタ上でも表示崩れが起こりにくくなります。

実践例｜カスタムCSS・カスタムjavascript・HTMLの分け方

私が最終的に採用した方法は、1つの記事内で3つの役割を明確に分ける構成です。
それぞれのファイルや欄がどんな役割を持っているかを理解しておくと、
トラブル時の原因を切り分けるのも非常に楽になります。

まず、HTML部分は「構造」だけを担う部分です。
Cocoonではブロックエディタの「カスタムHTML」を使いますが、
ここには装飾やスクリプトは入れず、最低限のタグだけを記述します。

例として、クリックで文字色が変わる簡単なデモを作る場合、
HTMLは以下のようにシンプルにします。

<div id="sample-box">クリックして色を変える</div>

あとは、見た目をCSS、動作をJSで制御します。

次に、カスタムCSS欄に以下のように記述します。

#sample-box {
  padding: 20px;
  background: #f0f0f0;
  text-align: center;
  transition: color 0.3s;
}

次に、同じ投稿画面の下部にある「カスタムJavaScript」欄に次のコードを入れます。

document.addEventListener('DOMContentLoaded', () => {
  const box = document.getElementById('sample-box');
  box.addEventListener('click', () => {
    box.style.color = box.style.color === 'red' ? 'black' : 'red';
  });
});

このように DOMContentLoaded（ページの読み込み完了）を待ってから動作させるのがポイントです。
これを入れないと、HTML要素が生成される前にスクリプトが動き出してしまい、
「要素が見つからない」エラーになることがありました。

この構成であれば、今のところ再現性高くスクリプトを組み込むことができています。