2026年3月、WordPress コミュニティに小さくない衝撃が走りました。
6.9.2 → 6.9.3 → 6.9.4 と、わずか 48 時間の間に 3 回のマイナーアップデートが連続リリースされたのです。

「自動更新が続いて怖かった」「何が起きていたの？」
そんな声が世界中で上がりました。

この記事では、この異例の連続リリースの背景を、一般ユーザーにも分かりやすく整理して解説します。

第1章：6.9.2（3/10）— 大規模なセキュリティ修正が一気に投入された日

6.9.2 は、合計10件の重要な脆弱性を修正するセキュリティアップデートでした。

🔐 修正された主な脆弱性

• XSS（クロスサイトスクリプティング）
• 権限昇格の可能性
• PclZip のパストラバーサル
• Notes 機能の権限バイパス
• getID3 ライブラリの XXE（XML 外部実体参照）

いずれも放置すれば攻撃に悪用される可能性があるため、
WordPress チームは迅速にパッチを公開しました。

しかし、このスピードが後の混乱につながります。

第2章：6.9.3（3/10）— 6.9.2 適用後に一部サイトが“真っ白”に

6.9.2 を適用した直後、世界中のユーザーから次々と報告が上がりました。

❗ 典型的な症状

• サイトが真っ白になる（Fatal error）
• 管理画面にアクセスできない
• 特定テーマのテンプレート読み込みでエラー発生

原因は、
一部テーマの非標準テンプレート処理と WordPress コアの変更が衝突したこと。

WordPress.org は 6.9.2 を一時撤回し、
緊急修正版として 6.9.3 を数時間以内にリリースしました。

第3章：6.9.4（3/11）— セキュリティ修正の“未適用”が発覚し、再修正へ

6.9.3 でクラッシュ問題は解決しましたが、
WordPress セキュリティチームが調査を進める中で、
6.9.2 で修正したはずの脆弱性の一部が実は適用されていなかったことが判明。

🔍 未適用だった修正

• PclZip のパストラバーサル
• Notes 機能の権限バイパス
• getID3 の XXE

これらはセキュリティ上重要な修正であるため、
翌日 6.9.4 として完全版パッチがリリースされました。

まとめ：なぜこんな異常事態になったのか？

🟦 原因1：修正規模が大きすぎた

10件の脆弱性を一度に修正する大規模パッチだった。

🟥 原因2：テーマ側の非標準コードとの衝突

6.9.2 の変更が一部テーマと噛み合わず、サイトがクラッシュ。

🟨 原因3：セキュリティ修正の一部が未適用

内部 QA の見落としにより、修正が完全に反映されていなかった。

Cocoon ユーザー（あなたの読者）へのアドバイス

• Cocoon は標準準拠なので影響は比較的軽微
• 6.9.4 に更新しておけば安全性は確保される
• 今回の件は「WordPress の裏側」を知る良い機会
• ブログ運営者は自動更新のログを確認しておくと安心

「新着情報の表示といえばこれ」と長年愛されてきたWordPressプラグイン『What’s New Generator（以下WNG）』。しかし、開発停止から数年が経ち、公式ディレクトリからも非公開となった今、最新のWordPress環境で使い続けることには「いつエラーでサイトが止まるか分からない」という不安が常に付きまといます。

それでもなお、このプラグインが検索され続ける理由は、その「圧倒的なシンプルさ」にあります。本記事では、当サイトのアクセスデータから見える「WNG需要」を紐解きつつ、プラグインを一切使わずに、最新の標準機能だけで「あの使いやすい新着一覧」を完全に再現する方法を徹底解説します。

データが証明する「What’s New Generator」への根強い支持

　　当サイトのアクセス解析（Site Kit）を見ると、興味深い事実が浮かび上がります。最新のキーボードレビューやWindows 11のカスタマイズ記事と並んで、常に上位にランクインするのが「What’s New Generator」に関する検索クエリです。

Site Kitの検索クエリ

※画像には「what’s new generator 代替」などのキーワードが並んでいる。

Site KitのSite Kitの過去28日間のトップコンテンツ

そして、Site Kitの過去28日間のトップコンテンツの６位に！

2026年、使い続けるリスクと「賢い卒業」

長年愛用してきた道具を手放すのは惜しいものですが、以下のリスクを冷静に見極める必要があります。

標準機能への移行こそが正解：今のWordPress（ブロックエディタ）には、プラグインなしで同等の表示ができる「クエリループ」が備わっています。

PHP 8.x系^※での「沈黙のエラー」：画面は映っていても、裏側でエラーログが溜まり、サーバー負荷や突然のクラッシュを招く恐れがあります。

セキュリティの空白：更新が止まったプラグインは、脆弱性が見つかっても修正されません。

【実践】標準機能「クエリループ」で新着一覧を再現する

追加プラグインは不要です。以下のステップで土台を作ります。

ステップ1：ブロックの挿入

1. 編集画面で「/query」と入力し、**「クエリループ」**ブロックを挿入します。
2. 「空白から開始」を選び、最もシンプルな「タイトルと日付」等のパターンを選択します。

筆者からのアドバイス : 当ブログはテーマ『Cocoon』を使用しているため、本来は標準機能だけで右ペイン等に新着記事を掲載できます。しかし、固定ページや投稿本文の好きな場所に「What’s New Generator」のような極めてシンプルなリストを配置したい場合、この標準機能を使った方法が最も軽量で安全です。
※実際の操作画面キャプチャについては、後日さらに分かりやすく追記する予定です。

ステップ2：表示内容の整理（WNG風にする）

1. 右側のパネルで「テンプレートからクエリを継承」をオフにします。
2. 表示件数を「5件」などに設定します。
3. リスト表示（アウトライン）を使い、「ポストテンプレート」の中を以下の3つだけに整理し、「行（Row）」ブロックの中に横並びに配置します。
   1. 投稿日
   1. 投稿カテゴリー
   1. 投稿タイトル

ステップ3：【重要】安全のための「名前付け」

他のページのデザインを壊さないために、クエリループブロックの「高度な設定」＞「追加 CSS クラス」に wng-style と入力してください。

デザインを整える：こだわりのレスポンシブCSS

以下のコードを「外観」＞「カスタマイズ」＞「追加CSS」に貼り付けてください。PCではWNG風の1行、スマホでは読みやすさを優先したデザインに自動で切り替わります。

/* wng-style 専用：PC・スマホ両対応のデザイン */
/*  特定のクラス（wng-style）を使っているため、公開中の他のページには影響しません。*/
/* WordPressの標準的なクラス名（.wp-block-post-template など）をターゲットにすると、サイト内のすべての「クエリループ」ブロックのデザインが、今回設定した「一行リスト形式」に変わります。もし他の場所でクエリループを使っていたら： 例えば、トップページで「おしゃれなカード型の記事一覧」をクエリループで作っていた場合、それも強制的に「WNG風のシンプルな一行リスト」に書き換えられてしまいます。*/

/* 1. リスト全体の基本設定 */
.wng-style .wp-block-post {
    border-bottom: 1px dotted #ccc; /* 薄いグレーであの懐かしの点線 */
    padding: 12px 0;
    margin: 0;
    display: flex;
    gap: 15px;
    align-items: center;
    font-size: 0.95rem;
}

/* 2. 日付：幅を固定して縦のラインを揃える */
.wng-style .wp-block-post-date {
    color: #888; /* グレー */
    flex-shrink: 0;
    min-width: 100px;
    font-family: monospace; /* 数字のガタつきを防ぐこだわり */
}

/* 3. カテゴリ：シンプルなバッジデザイン */
.wng-style .wp-block-post-terms {
    background-color: #f0f0f0;　/* 白に近い薄いグレー */
    color: #444; /* 濃いグレー */
    padding: 2px 8px;
    font-size: 0.7rem;
    border-radius: 2px;
}

/* 4. タイトル：PCでは一行、長い場合は「...」で省略 */
.wng-style .wp-block-post-title {
    margin: 0;
    font-weight: normal;
    white-space: nowrap;
    overflow: hidden;
    text-overflow: ellipsis;
}

/* 【こだわり】スマホ表示（600px以下）の最適化 */
@media (max-width: 600px) {
    .wng-style .wp-block-post {
        display: block; /* 横並びを解除して2行構成に */
        padding: 10px 0;
    }

    .wng-style .wp-block-post-date,
    .wng-style .wp-block-post-terms {
        display: inline-block;
        margin-bottom: 5px;
        font-size: 0.8rem;
    }

    .wng-style .wp-block-post-title {
        display: block;
        white-space: normal; /* スマホではタイトルを折り返して全文読ませる */
        font-size: 1rem;
        line-height: 1.4;
    }
}
/*画面の狭いスマホで「日付・カテゴリ・タイトル」を無理に1行に詰め込むと、文字が重なったり、タイトルが数文字しか読めなかったりと、かえって不便になります。「PCではスッキリ1行、スマホでは読みやすさ優先の2行（または最適化）」という、今のWebデザインの標準に合わせたこだわりを盛り込んでいます。 */

 操作で迷わないための「3つのコツ」

• 「リスト表示」を活用せよ：画面左上の三本線アイコンから階層を確認すると、目的のブロックをすぐ選べます。
• 不要なものは消していい：デフォルトで入る「アイキャッチ画像」や「抜粋」は、WNG(What’s New Generator)風にするならDeleteキーで消してOKです。
• プレビューで確認：特定のクラス（wng-style）を使っているため、公開中の他のページには影響しません。安心して下書きプレビューで確認してください。

おわりに：道具をシンプルに保つことが、最高の運営術

10年前のPCに工夫して最新OSを入れるワクワク感と同じように、WordPressも「古いプラグイン」に頼るのではなく、標準機能を「知恵」で使いこなす。それこそが、サイトを長持ちさせ、読者にとっても快適な環境を作る秘訣です。

プラグインの更新停止に怯える日々は、今日で終わりにしましょう。

あわせて読みたい：

What's New Generator 代替 プラグイン

Site KitにWhat's New Generator 代替 検索・サーチコンソールにも表示された 24/11/24:検索需要が高い為、代替プラグインの最新を確認・更新しました。依然として代替プラグインの検索件数が多いので、記事を更新し...

イイネ.biz

2026.02.18

使っちゃいけないプラグイン 191本 [発見次第更新]使ってはいけないWordPress Plugin ➡️解除も！

サイト攻撃の約６割がプラグイン起因。セキュリティ問題で停止されたもの。３年以上メンテナンスされず導入注意なもの。フォーラムや他サイトで見かけた➡その数なんと191本を「使ってはいけないプラグイン」として上げます。 理由は、開発チームが解散し新たに脆弱性が見つかっても対応が困難と思われるから。wordpress.orgのサイトでも"このプラグインは WordPress の最新3回のメジャーリリースに対してテストされていません。

イイネ.biz

2026.02.05

※

WordPress 6.9 の必要要件

💡 第1章: 最も注目すべき新機能：生成AIの統合

WordPress 6.9 の最も重要なトピックは、コンテンツ作成プロセスに生成AI機能が初めて本格的に組み込まれたことです。

1.1 コアにおける AI アシスタント（仮称: AI Drafting）

コンテンツ作成のワークフローを劇的に加速させるための AI アシスタント機能が導入されます。

• 機能: ブロックエディター内で、選択したテキストや新しいブロックに対して、AIが以下の操作を提案・実行します。
  • 要約（Summarization）: 長文を短くまとめる。
  • トーンの変更（Tone Adjustment）: 形式的な文章をカジュアルに、またはその逆に変更する。
  • アイデアの拡張（Idea Expansion）: 見出しや短い段落から、本文のドラフトを生成する。
  • SEO 提案: 作成中のコンテンツに基づいて、より良いタイトルやメタディスクリプションを提案する。
• 目的: コンテンツの初期ドラフト作成にかかる時間を短縮し、より多くの時間を推敲と編集に費やせるようにすること。

🖼️ 1.2 画像生成と編集の統合

OpenAI の DALL-E や類似のモデルを活用し、ブロックエディター内から離れることなく画像を生成・編集できる機能が搭載されます。

• 機能: メディアライブラリや画像ブロックに「AIで生成」ボタンが追加され、プロンプトを入力するだけでブログ用のユニークな画像を生成できます。
• 編集: 既存の画像に対して「背景の削除」や「スタイルの変更」といった AI 編集機能が提供されます。

🏗️ 第2章: サイトエディターと開発者向けの改善

フルサイト編集（FSE）体験が成熟し、よりプロフェッショナルなサイト構築に対応するためのツールが追加されます。

📄 2.1 改善されたテンプレート編集フロー

• 簡素化されたナビゲーション: テンプレートとパーツの切り替えがより直感的になり、サイトエディター内での迷子を減らすためのパンくずリスト（Breadcrumbs）ナビゲーションが強化されました。
• カスタム CSS の追加: 特定のテンプレートやテンプレートパーツに対して、グローバルスタイルに影響を与えずにカスタム CSS を適用できるコントロールが追加され、より細かなデザイン調整が可能になりました。

🎨 2.2 スタイルとデザインツールの進化

• 強化されたタイポグラフィ制御: フォントファミリー、サイズ、行の高さだけでなく、文字間隔（Letter Spacing） や 単語間隔（Word Spacing） の制御が、より多くのブロックで利用可能になります。
• デザインツールの統一: ブロック固有のデザインパネル（パディング、マージンなど）が整理され、どのブロックでも一貫した操作感でデザイン設定ができるよう標準化されました。

🛠️ 第3章: パフォーマンス、セキュリティ、バグ対応

メジャーリリースとして、6.9は大規模な基盤の改善とメンテナンス作業も実施しています。

🚀 3.1 大幅なパフォーマンス向上

• ブロックレンダリングの最適化: ブロックの読み込みと表示ロジックが改善され、特にページ内のブロック数が多い場合のフロントエンドの表示速度が向上します。
• データベースクエリの効率化: 頻繁に実行されるデータベースクエリの一部が最適化され、バックエンド処理の負荷が軽減されます。
• 画像遅延読み込み（Lazy Loading）の調整: LCP（Largest Contentful Paint）に影響を与える画像を、より効果的に処理するための遅延読み込みのロジックが微調整されました。

🐞 3.2 バグ対応と安定性の確保

• Core のバグ修正: これまでのバージョンで報告された、REST API、データベース層、マルチサイト機能に関連する約 100以上のバグ が修正されました。
• エディターの安定性: サイトエディターやパターン機能において、予期せぬクラッシュや保存エラーを引き起こす問題が特定され、安定性が大幅に改善されています。
• アクセシビリティ改善: スクリーンリーダーやキーボードナビゲーションのユーザー体験を向上させるための、多数のアクセシビリティ修正が含まれています。

🎯 まとめ

🖥️ WordPress 6.9の推奨要件

WordPressを安定して安全に実行するために、ホスティングサービスが以下の要件を満たしていることが推奨されています。

💡 補足情報

• PHPとデータベース: 古いバージョンのPHPやデータベースでもWordPressは動作する可能性がありますが、セキュリティ上のリスクやパフォーマンスの低下、そして新しい機能が利用できないなどの問題が発生するため、上記の推奨バージョンを満たすことが強く推奨されます。
• プラグインの動作: 一部の新しいプラグインやテーマは、最低要件としてPHP 8.0以上、WordPress 6.8以上などを要求し始めているため、推奨要件を満たすことで互換性の問題も回避できます。

Gene Harris

ジーン・ハリス（Gene Harris、出生名：Eugene Haire）は、ソウル・ジャズとして知られる、ブルースやゴスペルの要素を取り入れた温かい音色が特徴のピアニストとして知られるアメリカのジャズ・ミュージシャンです。

頼みの綱として生成AI「Gemini」に助けを求め、共に原因究明に奔走するも、その道のりは決して平坦ではありませんでした。プログラミングの鉄則を疑い、目を凝らしても見つからないエラーの正体は、まさに「想定外」。Geminiとの対話を通して、AIの可能性と限界、そして最終的に問題解決へと導いた驚きの真相を、赤裸々にお伝えします。

衝撃

ローカルのPCの開発環境では、うまく機能して操作できていた。
本環境にそのまま、コピペしただけなのにプレビュー段階で全く機能しない。

なぜ、何が問題？

何も変更することなく、ローカルのPCで開発した内容を、HTML部分とScript部分を別々に、カスタムHTMLブロック２つに分け、１番目のHTMLブロックにはHTML部分をそのまま貼り付け、次のHTMLブロックには<script></script>記載した上で、間にScript文を貼り付けただけなのに。

公開目前！最後の難関：突如現れたエラーの影

ローカル環境では完璧に動作していた自慢のカラーピッカー。意気揚々と公開準備を進めるも、本環境でのプレビュー表示でまさかのトラブル発生。プレビュー表示でカラーパレットが真っ白になり、操作は一切受け付けないという事態に直面。

原因究明の開始

藁にもすがる思いで：AIの知恵を借りる

Geminiとの対話：エラー情報の収集と解析の始まり

Geminiからの最初の指示は、ブラウザの開発者ツールに表示されるConsoleエラーの提供。果たして、そこに解決の糸口は隠されているのか？

Geminiの回答

ご報告ありがとうございます。ローカル環境では問題がないのに、Webページに公開した途端に問題が発生するとのこと、それは非常によくあるケースで、原因もいくつか考えられます。
問題を解決するために、以下の手順で確認を進めてください。【重要な確認事項】
ブラウザの開発者ツール（デベロッパーツール）の確認:

　公開されているWebページを開き、ブラウザの開発者ツールを起動してください。（通常は右クリックして「検証」や「要素を調査」を選択するか、F12キーを押すと開きます）

　開発者ツールの「コンソール」タブを開き、赤い文字で表示されているエラーメッセージがないか確認してください。もしエラーメッセージがあれば、それが問題の原因を示している可能性が高いです。エラー内容を教えていただけると、さらに具体的なアドバイスができます。

• Chromeで確認したConsoleエラーをGeminiに報告するも、そのエラー行数は膨大^※ かつ止まることなく吐き出されている。一体、何が原因でこんなにもエラーが出ているのか？

（※.ChromeのConsoleエラーはStopすることなく大量に出力され続ける。最初の100行あまり、2画面スクロール分位をコピーして報告。Geminiにもその旨を伝える）

Chromeの悲鳴：大量のエラーメッセージに翻弄される

本環境でのエラー報告ありがとうございます。大量のコンソールエラーが発生しており、特に SyntaxError: Invalid or unexpected token と SyntaxError: Unexpected token '+' が出ていることは、JavaScriptファイル自体に何らかの問題があることを示唆しています。

これらのエラーは、JavaScriptの文法として正しくない文字が含まれている場合や、ファイルのエンコーディングが間違っている場合などに発生します。ローカル環境では問題がないのに、本環境で発生するということは、ファイルのアップロードまたは保存の過程で問題が発生した可能性が考えられます。

以下の点について確認してみてください。

1. JavaScriptファイルの再アップロード: colorPicker_Gemini-Script7.js を再度、Webサーバーにアップロードしてみてください。アップロードが中断されたり、不完全な状態でアップロードされた可能性があります。FTPクライアントなどを使用している場合は、転送モード（バイナリまたはテキスト）の設定が適切かどうかも確認してください。一般的にはJavaScriptファイルはテキストモードで転送することが推奨されます。
2. ファイルのエンコーディング: JavaScriptファイルのエンコーディングが、Webサーバーで想定されているエンコーディング（通常はUTF-8）と一致しているか確認してください。テキストエディタでファイルを開き、エンコーディングの設定を確認・変更できます。
3. ファイル内容の確認: もし可能であれば、本環境にアップロードされた colorPicker_Gemini-Script7.js の内容を直接確認してみてください。予期しない文字が混入していたり、途中でファイルが途切れていないかなどをチェックします。
4. 他のJavaScriptエラーの確認: total.js という別のファイルでもエラーが発生しているようです。もしこのファイルがカラーピッカーの動作に依存している場合、このエラーが影響を与えている可能性も考えられます。カラーピッカーの動作に必要なJavaScriptファイルが全て正常に読み込まれているか、開発者ツールの「ネットワーク」タブで確認してください。

まずは上記の点を確認し、JavaScriptファイルが正しく本環境にデプロイされているかどうかを確かめてください。SyntaxError が解消されれば、カラーピッカーが正常に動作する可能性が高いです。

　➡　Geminiによる解析は難航を極める。

承知いたしました。.js ファイルをアップロードしたのではなく、HTMLブロックに直接ペーストしているとのこと、了解いたしました。その場合、コードの誤りである可能性が高まります。

先ほどのエラーメッセージをもう一度確認すると、xn--ecka7j.biz/:2154 Uncaught SyntaxError: Unexpected token '+' というエラーが出ています。これは、2154行目に予期しない + 記号があることを示唆しています。

以下の手順で、HTMLブロックにペーストしたJavaScriptコードを確認してみてください。

1. 本環境のコードの確認:
   • 公開されているWebページの該当箇所（拡張HTMLブロック）のコードを直接確認してください。ブラウザの開発者ツールの「要素」タブで、<script> タグの中身を確認できます。
   • ローカル環境で正常に動作しているJavaScriptコードと、本環境にペーストしたコードを行ごとに注意深く比較してください。特に2154行目付近に、意図しない + 記号がないか確認してください。また、タイプミスや文字抜けなども見落とさないように確認してください。
2. コメントアウトの確認:
   • JavaScriptのコメントアウト (// や /* ... */) が正しく記述されているか確認してください。誤ったコメントアウトは、予期しないトークンエラーを引き起こすことがあります。
3. テンプレートリテラルの確認:
   • コピー機能の部分でバッククォート (`) を使用しているテンプレートリテラルがありますが、これが正しく記述されているか確認してください。特に、文字列内で変数を埋め込む ${} の部分に誤りがないか注意してください。
4. 他のJavaScriptコードとの競合:
   • もしページ内に他のJavaScriptコードが存在する場合、それらのコードと変数名や関数名が衝突している可能性もわずかに考えられます。ただし、今回のエラーメッセージはSyntaxErrorなので、まずはコード自体の文法エラーを疑うべきです。

エラーメッセージの行番号(:2154) は、コードの行数が非常に多いことを示唆しています。 ペーストしたJavaScriptコードだけでなく、そのHTMLブロック全体や、その前後のHTML要素なども含めて、意図しない + 記号がないか確認してみるのも良いかもしれません。

お手数ですが、上記の手順でコードの確認と修正を試してみてください。SyntaxError が解消されれば、他の問題も解決に向かう可能性があります。

その通りです。ブラウザの開発者ツールが示す行番号は、HTMLファイル全体の行数を基準にしています。したがって、2154行目というエラー表示は、ペーストしたJavaScriptコードだけでなく、そのJavaScriptコードが埋め込まれているHTMLブロックや、それ以前のHTML構造の行数も全て含んだ上での行番号となります。

エラー箇所を特定するには、以下の手順で確認してみてください。

1. 公開ページのHTMLソースコードを表示する:
   • ブラウザで公開ページを開き、右クリックして「ページのソースを表示」または同様のオプションを選択します。
2. <script> タグを探す:
   • 表示されたHTMLソースコードの中で、カラーピッカーのJavaScriptコードをペーストした <script> タグの位置を探します。
3. 行数を数える:
   • HTMLソースコードの最初から数えて、2154行目付近に何が記述されているかを確認してください。<script> タグの中であれば、ペーストしたJavaScriptコードのエラーの可能性がありますし、もし <script> タグの外であれば、HTML構造に問題があるかもしれません。
4. エラーの可能性のある箇所を特定する:
   • 2154行目付近のコードに、エラーメッセージで指摘されている + 記号がないか、または文法的に不自然な記述がないか確認してください。

この方法で、エラーが発生している正確な位置を特定できるはずです。もし特定できたら、その部分のコードを再度確認し、修正を試みてください。

ご指摘ありがとうございます。ソースコードの行数が合わないとのこと、承知いたしました。

その場合、エラーが発生している2154行目付近には、別のJavaScriptコードが存在するか、または何らかの理由でHTML構造の一部がJavaScriptとして誤認識されている可能性があります。

以下の手順で、2154行目付近のコードを確認してみてください。

1. 公開ページのHTMLソースコードを再度表示します。
2. ソースコードを2154行目付近までスクロールします。
3. その行に何が記述されているか確認します。
   • もし <script> タグで囲まれたJavaScriptコードであれば、その部分に + 記号が不適切に使われていないか、文法的な誤りがないかを確認してください。
   • もし HTML タグやその他のコンテンツであれば、それが JavaScript の文脈で解釈されようとしてエラーになっている可能性があります。例えば、閉じタグが不足していたり、コメントアウトが正しく行われていないなどの理由で、意図しない部分が <script> 要素として扱われることがあります。
4. 2154行目よりも少し前の行（例えば2100行目あたりから）も確認し、JavaScriptの<script>タグが適切に開始・終了しているかを確認してください。 もし、どこかの <script> タグが閉じられていない場合、それ以降のHTMLコードがJavaScriptとして解釈され、エラーを引き起こすことがあります。

エラーメッセージは Unexpected token '+' ですので、2154行目付近で + 記号がどのように使われているか、文脈と照らし合わせて確認することが重要です。

もし、ご自身で原因を特定するのが難しい場合は、その2154行目付近のコード（可能であれば、その数行前後のコードも含む）を共有していただければ、私も一緒に確認してみることができます。

奥の手：Webページ全体のソースコードを提供

ご提供ありがとうございます。2154行目は外部のJavaScriptライブラリのコードの一部であるようです。これは、ご自身の記述されたカラーピッカーのコード（742行目から1164行目）とは異なる場所でエラーが発生していることを意味します。

このような場合、考えられる原因はいくつかあります。

1. ご自身のカラーピッカーのコードの潜在的なエラー: カラーピッカーのコードに、直接的なSyntaxErrorではないものの、実行時に問題を引き起こし、その影響が他のJavaScriptコードの解析に及んでいる可能性があります。例えば、変数名や関数のスペルミス、予期しない値が渡されることによるエラーなどが考えられます。
2. 外部ライブラリの破損または不完全な読み込み: 何らかの原因で、この外部ライブラリのコードが完全に読み込まれていないか、破損している可能性があります。ただし、HTMLに直接記述しているとのことなので、この可能性は低いかもしれません。
3. HTML構造の誤り: カラーピッカーのJavaScriptコードが記述されている場所のHTML構造に誤りがあり、それが外部ライブラリの解析に影響を与えている可能性も考えられます。例えば、<script> タグの閉じ忘れなどです。

トラブルシューティングとして、以下の点について再度確認をお願いできますでしょうか。

• ご自身のカラーピッカーのJavaScriptコードをもう一度、注意深く見直してください。 特に、最近変更を加えた部分や、イベントリスナーの設定、関数呼び出しなどに誤りがないか確認してください。セミコロンの抜けなどもエラーの原因となることがあります。
• カラーピッカーのJavaScriptコードを囲んでいる<script>タグが正しく閉じられているか確認してください。 また、その<script>タグがHTMLの適切な場所に配置されているか（通常は</body>タグの直前が推奨されます）も確認してください。
• もし他にJavaScriptコードを記述している<script>タグがあれば、それらのコードにもエラーがないか確認してみてください。

エラーメッセージが特定の外部ライブラリの行数を示しているとはいえ、根本的な原因がご自身のコードにある可能性も考慮して、今一度コード全体を見直してみてください。

完全な手詰まり状態

新たな視点：Firefoxのエラー情報に光明が？

FirefoxのConsoleエラーLogで判ったこと

ソースコード解析の結果：Geminiもお手上げ？

提供したソースコードに対し、Geminiは、ChromeでのConsoleエラーの「#」に関連する不審な点を見つけられなかったと回答。早くも暗雲が立ち込める。

ご提供いただいたHTMLソースコードを確認しましたが、Firefoxのエラーメッセージ UncaughtSyntaxError: '#' not followed by identifier xn--ecka7j.biz:818:30 が示す818行目付近には、直接的に問題となる # は見当たりませんでした。

ただし、Firefoxのエラーメッセージは、Chromeとは異なる場合があります。Chromeで表示されているエラー Uncaught SyntaxError: Invalid or unexpected token が依然として気になります。

つきましては、以下の点について、再度HTMLソースコード全体をご確認いただけますでしょうか。

1. Firefoxのエラー箇所（818行目付近）の確認:
   • その行に直接 # がない場合でも、その行のコードがJavaScriptの文脈で解釈された結果、そのようなエラーが出ている可能性があります。周囲のコード（特にJavaScript関連のコード）に問題がないか確認してください。
2. Chromeのエラー箇所（HTMLの先頭）の確認:
   • HTMLファイルの先頭から、特に <script> タグが始まるまでの間に、意図しない文字（不可視文字なども含む）や文法的に正しくない記述がないか、もう一度注意深く確認してください。
   • 稀に、サーバー側の処理や、コピー＆ペーストの際に予期しない文字がHTMLの先頭に混入することがあります。
3. JavaScriptコードの全体的な確認:
   • コメントアウト以外の不要な文字や記号が混入していないか、念のためJavaScriptコード全体を再確認してください。

もし、これらの確認をしても問題が特定できない場合は、大変お手数ですが、可能であれば、公開されているWebページのURLを共有していただけますでしょうか？実際にWebページを拝見することで、より具体的な原因を特定できるかもしれません。

Firefoxによる深掘り：Scriptエラーの発見と詳細調査

GeminiはFirefoxのエラーからScriptエラーを発見し、発生位置を特定。問題のコードの再確認を指示される。

コードを拝見しました。

まず、122行目の条件式で、JavaScriptの論理AND演算子である && が、HTMLエンティティの && と記述されています。これはJavaScriptとしては解釈されず、意図しない動作を引き起こす可能性がありますので、&& に修正してください。

何故か？117 Lineを122行目と言ってくるが、、、、

コードは正常、しかし現実は…：繰り返される問題

問題箇所とされるコードは正常にしか見えず、編集画面でも問題なし。念のため、Scriptを再度上書き更新するも状況は変わらず。エラー解決への道は依然として見えない。

展開されたSourceのの文字化け部分（819 Line）

if (r >= 0 && r <= 255 &#038;&#038; g >= 0 && g <= 255 &#038;&#038; b >= 0 && b <= 255) { 

そう、余計な文字：#038;　が、&&の間に数か所に挟まっている。
（でも全部の＆＆の間が文字化けしている訳ではない。･･･これも不思議！）(ここがRGBの数値の範囲チェックの部分･･･➡ここのif文が機能しないための不具合。Firefoxのconsoleエラーが示す’#‘もここにある。)

そして、実際のコーディングでは、以下の様に問題なく（文字化けの「#038;」もない）（　colorPicker_Gemini-Script7.jsの　117 Line）

if (r >= 0 && r <= 255 && g >= 0 && g <= 255 && b >= 0 && b <= 255) {

元々の「colorPicker_Gemini-Script7.js」

であるし、改めて、編集画面で見てみても同じ

でも、現実は不具合発生だし、Firefoxのconsoleエラーはここを指している
（よく見てみるとChromeのConsoleエラーとSourceコードのGemini解析で指し示した「#」は、#038;の先頭にある）

プレビュー画面のSourceの該当箇所付近は、下の画像キャプチャ通り
SourceをSublime Textに貼り付け、Check250525.htmlで保存した後、VS Codeで開いて「if (r >= 0」で検索 ➡ Firefoxのエラー箇所（818行目付近）で合致する819 Line（VS Codeは文字化け部分を~~~~ ~~~~で示してくれている。こんなCode無いぞ!!!と）➡ 　該当箇所近辺をキャプチャ

環境要因の可能性：GeminiからのURL開示要求

Geminiは、ソースコードと実行環境の間に生じる不整合、特に文字化けの可能性を指摘し、実際のWebページのURLの開示を求める。

原因がまた一つ特定できましたね！&& がまだ残っていたとは、驚きです。

Localで修正してアップロードしたのに、本環境で文字化けが戻ってしまう原因としては、以下の可能性が考えられます。

1. キャッシュ: ブラウザのキャッシュだけでなく、WebサーバーやCDN（コンテンツ配信ネットワーク）のキャッシュが古いバージョンのファイルを配信している可能性があります。スーパーリロード（Ctrl+Shift+R または Cmd+Shift+R）を試すだけでなく、もしCDNを利用している場合は、CDNのキャッシュクリアも試してみてください。
2. 保存またはアップロードの失敗: 編集したHTMLブロックが正しく保存または公開されていない可能性があります。Webサイトの編集画面で、変更を保存し、公開する手順を確実に行ってください。
3. 複数の場所でコードを編集している: もし、複数の場所で同じコードを編集している場合、誤って古いバージョンのコードを上書きしてしまっている可能性があります。
4. プラットフォームの自動変換: ご利用のWebサイトプラットフォームによっては、特定の文字や記号を自動的に変換する機能があるかもしれません。もしそういった機能があれば、設定を確認してみてください。

まずは、Webサイトの編集画面で、該当のHTMLブロックの内容が最新の修正済みコードになっていることを確認してください。その後、キャッシュクリアを徹底的に行ってみてください。

もしそれでも問題が解決しない場合は、ご利用のWebサイトプラットフォーム名などを教えていただければ、何か情報が見つかるかもしれません。

非公開とプレビューの壁：もどかしい状況

問題解決のためURLを開示したい気持ちはあるものの、ページは未公開。下書きプレビューでの状況を伝え、一時公開も検討することを伝える。

下書き保存とプレビュー表示で確認しても正しく動作しないとのこと、承知いたしました。編集画面でコードが正しく表示されているにも関わらず問題が解決しない場合、以下の可能性を試してみてください。

1. プレビュー画面のハードリロード: プレビュー画面が古いキャッシュを読み込んでいる可能性があります。プレビュー表示の状態で、強制的に再読み込み（ハードリロード）を試してみてください。通常、Ctrl+Shift+R（Windows/Linux）、Cmd+Shift+R（Mac）で行えます。
2. プレビュー画面の開発者ツール（コンソール）の確認: プレビュー表示でも、ブラウザの開発者ツールを開いて（通常はF12キー）、コンソールにエラーメッセージが表示されていないか確認してください。表示がおかしくても、JavaScriptのエラーが出ている場合があります。
3. プラットフォームのプレビュー機能の特性: ご利用のWebサイトプラットフォームのプレビュー機能が、公開時と異なる動作をする場合があります。もし可能であれば、プラットフォームのヘルプなどを確認し、プレビューの制限事項などを調べてみてください。

上記を試しても解決しない場合は、一旦「工事中」などの表示をして公開し、URLを共有していただく方が、私も実際のWebページの状態を確認できるため、より具体的なアドバイスができるかもしれません。もし公開に抵抗がなければ、その方法もご検討ください。

承知いたしました。公開後、URLを共有いただければ、すぐに確認させていただきます。引き続きサポートさせていただきますので、よろしくお願いいたします。

Geminiの期待：公開後のURL分析に託す

承知いたしました。URLをありがとうございます。

早速、拝見して状況を確認いたします。少々お時間をください。

ページを「工事中」として公開し、URLをGeminiに託す。AIによる分析に、一縷の望みをかける。

AIも時間が必要：分析結果を待つ焦燥感

Geminiから分析に時間を要する旨の連絡。焦りを感じながらも、AIの判断を待つ。

Geminiの回答を待つ間に

まさかの自己解決：閃きが生んだ解決策

Geminiからの返信を待つ間に、何気なくScriptの記述場所を変更してみたところ、嘘のようにエラーが解消！信じられない結末を迎える。

Geminiに報告：解決したことと変更点を

解決のご報告ありがとうございます！テーマの機能であるカスタムJavaScript欄に移動させることで解決されたとのこと、素晴らしいですね。

当初、HTMLブロックに直接記述されていたことが原因だったのですね。テーマの機能を利用することで、JavaScriptの実行環境が適切になり、問題が解消されたと考えられます。

カラーピッカーが無事に動作するようになったとのこと、大変嬉しく思います。他に何かお手伝いできることがございましたら、お気軽にお知らせください。

Geminiの誤解：AIにも得意不得意がある？

真実の共有：依然として残る謎

Geminiの誤解を訂正し、自己解決に至った経緯と、根本的な原因が依然として不明であることを伝える。

Geminiの反省と今後の課題：文字化けという難題

Geminiは自身の誤解を謝罪し、文字化けという問題の複雑さについて言及する。

ご指摘ありがとうございます。私の認識が誤っており、申し訳ございません。「HTMLブロックに直接記述されていたことが原因」ではなく、文字化けが根本的な原因だったのですね。

文字化けの原因は特定できていないとのこと、承知いたしました。文字化けは、ファイルの保存形式、Webページのエンコーディング設定、サーバー側の設定など、様々な要因で発生するため、原因特定が難しい場合がありますね。

今回のケースでは、テーマのカスタムJavaScript欄に移動したことで、結果的に文字化けの問題も解消された、または影響を受けなくなった、と理解いたしました。

引き続き、何かご不明な点やお困りのことがございましたら、お気軽にお知らせください。

まとめ

Webサイト公開直前、予期せぬConsoleエラーに見舞われた顛末記。生成AI「Gemini」との対話を通じて問題解決を試みるも、最終的な原因はコードの一部で発生した不可解な文字化けだった。AIの力を借りながらも、人の目による確認と環境に合わせた調整の重要性を痛感した記録。

Color Palette Explorer: あなただけの特別な色を作ろう・見つけよう！

洗練されたカラーピッカー - Webデザイン、イラスト制作に。RGBスライダー、カラーパレットで直感的に色を見つけ、HEX/RGBコード、和色名も表示。選択した色はHTMLテーブル形式で保存。Webサイトに最適な色を簡単選択。色の表現が豊かに。

イイネ.biz

2026.04.09

　このリリースは、WordPress 6.7で導入されたバグに特化しており、安定性を向上させるための高い優先度の修正が含まれています。
16のバグ修正: WordPressコアとブロックエディターのバグ修正が含まれています。

トピック

• 画像サイズの問題: 画像が予想よりも小さく表示される問題を修正。　
  ・・　sizes=auto が原因で、画像が適切なサイズより小さく表示される (#62413)
• 翻訳の適用: 翻訳が正しく適用されない問題を修正。　
  ・・　翻訳が正しく適用されない (#62337)
• パターンのカテゴリ: カテゴリがないパターンがエディターでのブラウズ中に壊れる問題を修正。　
  ・・　カテゴリなしのパターンが、未分類のパターンをブラウズする際にエディタをクラッシュさせる (GB-66944/GB-66888)
• ズーム機能の問題: ズームイン/ズームアウトボタンの問題を修正。
  ・・　ズームインが選択されたアイテムに基づいて画面の正しい位置にフォーカスしない（これに関するいくつかのPR問題）
  ・・　プラグインがツールバーアイテムを登録するとズームアウトボタンが表示されなくなる (GB-66884)

修正一覧

Table Top

注釈

　HEIC

　HEIF

　I18N

　
　記事の保存はデータベースへの書き込みを伴います。データベースが肥大化したり、インデックスが適切に構築されていない場合、クエリの実行時間が長くなり、保存に時間がかかることがあります。

サーバーのphpメモリ上限とphp Postサイズ上限を、512Mから1,024Mに増やす変更しても改善されなかった。

今回、追記編集しようとした記事は、

５年以上前のパソコンでもWindows11は動くのか？ Let's note sz6 Core i5-7200U 21H2 ➡ 25H2

あなたはWindows11で新しいパソコン買いますか？ここでは5年前(執筆時）Intel 7世代CPU:sz6:2016年10月モデルにWin11インサイダープレビューから動作検証、以降順次・最新版へアップデートし、経過チェックし詳細にLog記録いくもので最新は23H2･･･

イイネ.biz

2026.02.19

　「５年前のパソコンでもWindows11は動くのか？ Let’s note sz6 Core i5-7200U」は、2021/07/09に初投稿したもので、現在の文字数が31,372。Window 11の更新(KBメンテでBuild Noが上がる)都度、50数回に渡り追記・編集してきたもので、細かな修正も含めると60個程度のリビジョンが溜まっていた。

　「使っちゃいけないプラグイン 153本 [発見次第更新]使ってはいけないWordPress Plugin ➡️解除も！ 」は、2021/02/19に初投稿したもので、現在61,316文字。Pluginの発見都度、2022年に23回、2023年に35回、2024年は既に26回、追記・編集してきたもの。こちらなんと90近いリビジョンが溜まっていた。

使っちゃいけないプラグイン 191本 [発見次第更新]使ってはいけないWordPress Plugin ➡️解除も！

サイト攻撃の約６割がプラグイン起因。セキュリティ問題で停止されたもの。３年以上メンテナンスされず導入注意なもの。フォーラムや他サイトで見かけた➡その数なんと191本を「使ってはいけないプラグイン」として上げます。 理由は、開発チームが解散し新たに脆弱性が見つかっても対応が困難と思われるから。wordpress.orgのサイトでも"このプラグインは WordPress の最新3回のメジャーリリースに対してテストされていません。

イイネ.biz

2026.02.05

「WordPress 脆弱性とバージョン推移　」では、2019/08/28の初投稿以来、WordPressの新バージョンが発表・公開される都度、追記・編集してきた。現在の文字数は、12,683

WordPress 脆弱性とバージョン推移 v.6.9.1

WordPress 6.9.1 あなたのホームページがワードプレスで作られていて 何も対策をしていないと改ざんされたり・危険です。ホームページに訪れてあなたのお客さんになってくれるかも知れない人たちに不安を抱かれてしまいます。（あなたのホームページが何で作られているか？な人はお問い合わせください） WordPressは、積極的に保守されていますか？ WordPress.orgでは、「積極的に保守されている5.n系統の最新版以外の以下のバージョンは、安全に使用することはできません。」と公式に表明しています。以下に、WordPressの、脆弱性とバージョンの推移をお知らせします。

イイネ.biz

2026.02.05

これら以外にもリライトを続けているものもあるが、これらは今後もリライトを続けていくことになるので、この課題は解決しなくてはならない。

課題整理と問題解決に向けて

　問題は、リライトを続けることでリビジョンNoが上がりWordPressや多くのCMSが管理する同じ記事に関連する古いリビジョンが溜まっていくことになり、データベースへの影響（パフォーマンスやデータベース領域の像祭）が進む。

　今回の事象でそうも行かないこと、今後も「保存」で待たされることになる・・・ということに対処しなければという思いに至った。

生成AI GEMINIに聞く

GEMINIに質問した内容は以下。

回答は３種類

UpdraftPlus

普段のバックアップは、ホスティングサービス任せなのでバックアップの為のプラグインを利用することがなかったが、今回フルバックアップ（WordPress全体のバックアップ）ということで利用した。

バックアップお薦めプラグインUpdraftPlus

バックアッププラグインとしてのUpdraftPlusの優位性（データ復旧がワンタッチで簡単に行えること、など）UpdraftPlusのインストールから有効化＆設定、実際のバックアップ操作および、バックアップの実態までの紹介。バックアップ・リストアに特化されていて（操作が簡単な）プラグインUpdraftPlusのご紹介あなたのWordPresサイトの運営の必要なこと

イイネ.biz

2023.10.13

 WP-Optimize

GEMINIが提示したPluginのまとめ

　Revision control

　Written：2024/10/16 ; Revision control plugin presented by GEMINI

_	#	Plugin 名	WordPress.org Install WP ver.	主な機能	特徴	GEMINI提示 ３回
	1	WP-Optimize	1,000,000+ WP 6.6.2	◉ 不要なリビジョンの削除 ◉ 一時的なデータの削除 ◉ スパムコメントの削除 ◉ オプティマイズスケジュール設定 ◉ データベースの分析 ◉ データベーステーブルの最適化 ◉ スケジュールによる自動最適化 ◉ キャッシュのクリア	◉ シンプルな操作性 ◉ 高いパフォーマンス ◉ 多機能	1位 1位 1位
	2	Optimize Database after Deleting Revisions	80,000+ WP 6.6.2	◉ リビジョン削除後の自動最適化 ◉ 手動による最適化も可能 ◉ カスタム投稿タイプのリビジョン管理 ◉ 添付ファイルのリビジョン管理 ◉ 自動スケジュールによる最適化	◉ 特定の機能に特化しているため、シンプルで使いやすい ◉ リビジョン削除とデータベース最適化をワンストップで実行できる	２位 ４位 ２位
	3	WP-Sweep	100,000+ WP 6.6.2	◉ トランジェント、自動保存、投稿メタ、コメントメタなどの削除 ◉ カスタム投稿タイプやタクソノミーの削除 ◉ スケジュールによる自動クリーンアップ	◉データベースのクリーンアップを細かく設定できる	３位
	3	WP -DBManager	80,000+ WP 6.3.5	◉データベースのバックアップ ◉データベースの修復 ◉データベースの最適化 ◉テーブルの修復 ◉データベースのエクスポート/インポート ◉SQLクエリの実行	◉多機能 ◉高度な設定が可能 ◉データベース管理を包括的に行える	３位
	4	Advanced Database Cleaner	100,000+ WP 6.6.2	◉カスタムSQLクエリによるクリーンアップ ◉バックアップの作成 ◉詳細なログ	◉高度なデータベースクリーンアップ機能を提供する	４位
	5	UpdraftPlus – Backup /Restore	3,000,000+ WP 6.6.2	◉WordPress全体のバックアップ ◉データベースのバックアップ ◉データベースの最適化 ◉ファイルのバックアップ ◉自動スケジュールによるバックアップ ◉クラウドストレージへのバックアップ ◉スケジュール設定による自動バックアップ ◉復元機能	◉バックアップと最適化を同時に実行できる ◉クラウドストレージとの連携が可能 ◉多様なバックアップオプション	5位 ４位 ※ Revsion管理用として提示されたが、 BackUpプラグイン
	5	Clean Up – WordPress	NotFound	◉データベースのクリーンアップ ◉不要なショートコードの削除 ◉CSS/JavaScriptの最適化 ◉不要なデータの削除（不要な投稿、コメント、タグ、カテゴリーの削除） ◉トランザクションテーブルの最適化 ◉自動保存データの削除 ◉カスタムテーブルの管理 ◉データベースの分析 ◉トランジェントの削除 ◉オプションの削除	◉不要なデータを細かく指定して削除できる ◉データベースを軽量化できる	5位 2位 5位 ※ WordPress.orgに 存在せず

症状は、記事の更新で、ディスクリプション部分が更新できません。タイトルや他のカスタムHTMLブロックに入れたテーブルなどは更新できています。

この記事では、500Internal Server Errorに至る前兆、エラー原因の究明と対策方法についてお伝えしたいと思います。

更新エラー

description

タイトルや記事部分の編集を終えたので、メタディスクリプション部分の内容を編集して更新します。

• 編集前のディスクリプションは322文字でプラグインの数は146本でした。
• 今回、プラグインの数は153本に増え、ディスクリプション内の文書も編集して文字数は222文字になりました。
• ここで「更新」ボタンを押したのですが、ディスクリプションの内容が元に戻って（ロールバックして）います。

• ページの最上部までスクロールしてみると、「更新に失敗しました。」となっています。
  同時編集したタイトル部分の更新（153本）は更新され反映されています。
• また、編集画面から通常の表示に戻ると、同時編集した記事部分の追加及び編集部分は更新され反映されています。

カスタムcss

さらに、カスタムcss部分を外部Link化して、該当カスタムcssを無効化（ブランク又はコメント化）した後、「更新」ボタンを押しても結果ロールバックされてしまう。

カスタムcss内の定義も、「更新」したのですが、ロールバックしてしまいます。

HTML Check

Nu Html Checker         で検査してみたのですが、エラーになるような致命的なHTMLミスはありませんでした。

Error前触れ？

Cocoonフォーラム

　Cocoonフォーラムの「Cocoonテーマに関する質問 」に相談しました。

フォーラム投稿

私

Title: 記事の更新で、ディスクリプション部分が更新できません。タイトルや他のカスタムHTMLブロックに入れたテーブルなどは更新できています。

本文：お世話様です。

該当記事： https://xn--ecka7j.biz/security/1242/ で、

「更新」ボタンを押しても一部が更新されないため、

ページの最上部までスクロールしてみると、「更新に失敗しました。」となっています。

（但し、同時編集したタイトルや記事部分の追加及び編集部分は更新され反映されています）

ただ、24/04/25時点までは、ディスクリプション部分の更新が出来ていました（タイトル上の本数と同じ146本）。

その後、何度か同じ記事を更新していますがその時はディスクリプション部分の変更は行わなかったため分かりません。

更に24/07/15にディスクリプション部分の変更(147本)を行った時から24/08/01(153本)までは更新されていません。

（7/15、7/19、7/29、8/1に同記事の編集を行っています。）

•ディスクリプション部分の画像（更新前：322文字➡️編集：222文字「更新」ボタン➡️結果：322文字に戻る）と、「更新に失敗しました。」の画像を添付します。

HTML Checkerで確認すると、CSS部分とHTML部分にいくつかエラーがありますが、これが関係してるとも思えませんが、念の為。

環境情報をつけて

mk2

以下のような場合、更新できますでしょうか

•          ディスクリプション部分を空にする

•          ディスクリプションを、10文字くらいの短い文章にする

上記で更新できた場合は、ディスクリプションに入力した文章に、何か問題があるのかと思われます。

例えば、何か不正な文字などは入っていたり。

（こちらからは入力したものが見えませんので、分からないんですよね）

上記のようなケースが、更新できないとすると、別の原因だと思います

追伸です。

カスタムcss部分も同様に更新できません。

カスタムcss部分を修正して外部css化した後、カスタムcss部分を削除し更新しようとしたのですが、同様にエラーとなり更新できませんでした。

カスタムcss部分を全削除しても、一行だけコメント行にして更新しようとしても、同様にエラーとなり更新できません。

（画像添付）

ありがとうございます。

全削除しても1文字だけにしてもエラーとなり更新できませんでした。

その下の、カスタムcss部分も修正したり、外部css化して全削除しても１行だけコメント行

/*    */ に、しようとしてもエラーとなり更新できませんでした。

エラーとなった場合でも、表示上はブランクになっています。

一度更新を閉じて、再度更新しようとするとものと状態に戻った状態で表示されます。

まさかと思いますが、Cocoon設定を変更して保存できますか？

まさに更新ができない状態のようですね。

•          デベロッパーツールのConsole部分にエラーは出ていないのか

•          エラーログに、何か落ちていないのか

•          親テーマにすると更新できるのか

 上記のようなことはご確認いただいていますでしょうか

@mk2_mk2 さん

カスタムcss削除＆更新でデベロッパーツールで 500サーバーエラーとなっています。

 api-fetch.min.js?ver…er=20240522121129:2

POST  https://xn--ecka7j.biz/jn-json/wp/v2/posts/1242?_locale=user  500 (Internal Server Error)

@chu-ya さん

Cocoon設定を変更して保存でデベロッパーツールにエラー表示があります。

 Uncaught

TypeError:Cannot read properties of undefined (reading ‘run’)

m=kernel_loader,loader_js_executable:482 Uncaught

TypeError: Cannot read properties of undefined (reading ‘run’)

at m=kernel_loader,load…executable:482:3959

about:blank:1 Denying load of chrome-extension://gaiceihehajjahakcglkhmdbbdclbnlf/content.css. Resources must be listed in the web_accessible_resources manifest key in order to be loaded by pages outside the extension.

about:blank:1 Denying load of chrome-extension://gaiceihehajjahakcglkhmdbbdclbnlf/content.css. Resources must be listed in the web_accessible_resources manifest key in order to be loaded by pages outside the extension.

about:blank:1 Denying load of chrome-extension://gaiceihehajjahakcglkhmdbbdclbnlf/content.css. Resources must be listed in the web_accessible_resources manifest key in order to be loaded by pages outside the extension.

about:blank:1 Denying load of chrome-extension://gaiceihehajjahakcglkhmdbbdclbnlf/content.css. Resources must be listed in the web_accessible_resources manifest key in order to be loaded by pages outside the extension.

content.js:1

GET chrome-extension://invalid/ net::ERR_FAILED

•          デベロッパーツールのConsole部分にエラーは出ていないのか

•          エラーログに、何か落ちていないのか

•          親テーマにすると更新できるのか

上記の2番目・3番目の確認結果は、どういう状態なのでしょうか。

「500 Internal Server Error」（サーバー内部エラー）ですから、確実に何らかのエラーが発生しています。

その原因を探っていく必要があると思います。

詳細は、エラーログなどを確認しないと、何が起きているかは分からないと思います。

wp-postmetaが更新されないのは、何らかのエラーが原因で、ロールバックされている可能性があると思います。

POST   https://xn--ecka7j.biz/jn-json/wp/v2/posts/1242?_locale=user   500 (Internal Server Error)

以下と同じ現象と思われます。

https://colorful.velvet.jp/webdesign/wordpress_update_error

colorful.velvet.jp

エラーログ取得

フォーラム再開

@mk2_mk2  さん

ありがとうございます。

エラーログの内容をGEMINIに聞いてみました。

もしかして、メモリ不足エラー なのかも、と、いうのはこの記事60,000文字を超えていまして。･･･

サイトヘルスで確認：

PHP メモリ上限                         200M

PHPメモリ制限 (管理画面のみ)        256M

メモリ制限を変更してリトライしたいと思います。

GEMINIエラーログの解説

このエラーログは、WordPressサイトで発生した問題を示しています。

メモリ不足エラー

最初のエラーログは、PHPのメモリ不足エラーです。

•          内容: Allowed memory size of 209715200 bytes exhausted (tried to allocate 131072 bytes) in /home/a-itc/xn--ecka7j.biz/public_html/wp-includes/class-wpdb.php on line 2320

•          日本語訳: 使用可能なメモリ容量 (209,715,200 バイト) を超えてしまい、メモリ割り当て (131,072 バイト) に失敗しました。 (ファイル: /home/a-itc/xn--ecka7j.biz/public_html/wp-includes/class-wpdb.php, 行: 2320)

•          原因: 実行中のスクリプト (おそらくWordPress) が、割り当てられたメモリ容量を超えるほど多くのメモリを使用しようとしたためです。

解決方法

メモリ不足エラー

•          WordPressのプラグインやテーマを見直す: メモリを大量に消費する可能性のあるプラグインやテーマがないか確認する。不要なものは無効化するか削除する。

•          PHPのメモリ制限を増やす (サーバー管理者が必要): サーバーの管理者と相談し、PHPのメモリ制限値を一時的に上げることで、エラーを回避できる場合があります。ただし、根本的な解決ではなく、メモリリークなどの問題の可能性があるので注意が必要です。

補足:

•          エラーログには、エラーが発生した関数の情報や、エラーが発生したコードの場所 (行番号) が含まれています。必要に応じて、これらの情報も参考にしてください。

以上の解決方法を試しても問題が解決しない場合は、WordPressのフォーラムや、サーバー管理者に相談することをおすすめします。

私には、エラーログ全部は見えませんので、言えることだけ。

投稿者::

内容: Allowed memory size of 209715200 bytes exhausted (tried to allocate 131072 bytes) in /home/a-itc/xn--ecka7j.biz/public_html/wp-includes/class-wpdb.php on line 2320

WordPressが使用できるメモリの最大量が209,715,200バイト（約200MB）で、そのメモリのすべてを使い果たしたということだと思います。

そして、追加で131,072バイト（約128KB）のメモリを確保しようとしたが、既にメモリの上限に達していたため、確保できなかったのかな・・・と。

まずは、メモリ容量を増やしてみることだと思います。

エックスサーバーであれば、比較的簡単にphp.iniを修正できたと思います。

php.ini設定について

php.ini設定について | レンタルサーバーならエックスサーバー

レンタルサーバー「エックスサーバー」のご利用マニュアル｜PHPプログラムの設定ファイルである「php.ini」をサーバーパネル上で簡単に編集できる「php.ini設定」機能に関するご案内です。

www.xserver.ne.jp

以下の値がどうなっているのか、確認後に増やす感じなのかなと。

•          memory_limit

•          post_max_size

「memory_limit >= post_max_size」である必要があったと思います。

ちなみに、私もWordPress 6.5.5を使っていますが、特にこの問題は起きていません。

（メモリに関しては十分確保していると思いますし）

@mk2_mk2 さん

お陰様で、php.iniの変更も終わり

記事の更新（ディスクリプションの更新とカスタムcss記述の削除）

も終わり、正常（CSSのエラーもなくなり）にできました。

サーバーパネル ＞ 設定対象ドメイン：イイネ.biz　＞ PHP　＞ php.ini設定 ＞

•          memory_limit　：　200M　➡️　256M

•          post_max_size　：　30M　➡️　128M

サイトヘルスでの確認も

PHP メモリ上限              256M

PHP POST サイズ上限            128M

となりました。

エラーログでは、200MBを超えていますし。
どちらも、512Mくらいにしても良い気がしますよ。

現状で上手くいっていますから、そんなに心配ないのかもしれませんけれど。
今後、もっと使用量が増える可能性もあるかもしれませんので、余裕はあった方が良いと思います。

了解です共に512MBまでに変更しました。

Php.ini

memory_limit　      512M　

post_max_size　     512M　

サイトヘルスで確認

PHP メモリ上限          512M

PHP POST サイズ上限  512M

500 Internal Server Error

このマイナーリリースには、
コアの12件のバグフィックスと
ブロックエディターの9件のバグフィックスが含まれます。

Core

I18N ※: WordPressのI18Nは、国際化（Internationalization）の略称

trunk ※: WordPressコアの開発ブランチ（trunk ブランチは、最も新しい開発コードが格納されているブランチ）

Block editor

XSS

XSS：cross site scripting

ウェブアプリケーションの中には、検索のキーワードの表示画面や個人情報登録時の確認画面、掲示板、ウェブのログ統計画面等、利用者からの入力内容やHTTPヘッダの情報を処理し、ウェブページとして出力するものがあります。
ここで、ウェブページへの出力処理に問題がある場合、そのウェブページにスクリプト等を埋め込まれてしまいます。
この問題をXSS「クロスサイト・スクリプティングの脆弱性」と呼び、この問題を悪用した攻撃手法を、「クロスサイト・スクリプティング攻撃」と呼びます。
クロスサイト・スクリプティング攻撃の影響は、ウェブサイト自体に対してではなく、そのウェブサイトのページを閲覧している利用者に及びます

出典：IPA 独立行政法人 情報処理推進機構

SQLi

SQLインジェクション攻撃により、発生しうる脅威は次のとおりです。

出典：IPA 独立行政法人 情報処理推進機構

CSRF

WordPress 6.0.3

Security Update

WordPress 5.8.3 セキュリティ アップデート

対策がされた内容

1. XSSの問題（投稿のスラッグを介して）
2. オブジェクトインジェクションの問題（一部のマルチサイトインストールで）
3. WP_QueryのSQLインジェクションの脆弱性
4. WP_Meta_QueryのSQLインジェクションの脆弱性
   （WP_Meta_Queryは、バージョン4.1から5.8にのみ関連）

改訂されたファイルのリスト

対応バージョン（22/01/06現在）

XSSの問題

ウェブアプリケーションの中には、検索のキーワードの表示画面や個人情報登録時の確認画面、掲示板、ウェブのログ統計画面等、利用者からの入力内容やHTTPヘッダの情報を処理し、ウェブページとして出力するものがあります。
ここで、ウェブページへの出力処理に問題がある場合、そのウェブページにスクリプト等を埋め込まれてしまいます。
この問題を「クロスサイト・スクリプティングの脆弱性」と呼び、この問題を悪用した攻撃手法を、「クロスサイト・スクリプティング攻撃」と呼びます。
クロスサイト・スクリプティング攻撃の影響は、ウェブサイト自体に対してではなく、そのウェブサイトのページを閲覧している利用者に及びます。

出典：IPA 独立行政法人 情報処理推進機構

SQLインジェクションの脆弱性

オブジェクトインジェクション

追記 22/01/18

5.8、5.7、5.6、5.5、5.4、5.3、5.2までのブランチ以降にメンテされた情報