このページは…
ワードプレス管理画面で発生する「無効な投稿形式」というエラーについてのページです。
エラー発生から解決するまでの一部始終について書いてあります。
調べたことや試したこと、それぞれの結果、更に類似のエラー例や、付随して判明した問題点とその解決法などが、主な内容です。
目を通しておく事で、解決もしくは参考にすることができます。
どんなエラーかについては、下記の動画にてご確認いただけます。
結論
僕の場合はカスタマイズが原因でした。function.phpから原因と見られる記述を削除したことで、エラーを解決することができました。
以下、エラーの発生から解決までの一部始終について書いていきます――
おすすめな人
- WordPressの管理画面で「無効な投稿形式」というエラーが出てきて困っている
本題
今回のエラー対応に関しては、以下の段階に分けられる。
- 発端(記事を一括編集しようとすると…)
- 検証(相談したり環境構築したり)
- 解決(知識がなくても一応できた!)
それぞれについて書いていく。
発端(記事を一括編集しようとすると…)
WordPress管理画面にて、以下の手順で操作を行うとエラーが発生
※冒頭の動画でも確認可能
エラー発生の手順
- 「投稿一覧」
- 「(条件を指定して)絞り込み検索」
- 「(チェックを入れて)編集」
- 「適用」
- 「エラーメッセージ“無効な投稿形式。”」
エラーによる問題
- 記事の一括編集ができない。
- 現段階では記事数が少ないため、それほど大きな問題ではない。
- しかし、今後ブログの記事を増やしていくにあたり、一括編集を行う場面も増えてくると予想されるため、解決したい。
検証(相談したり環境構築したり)
まず、前提となる環境情報を確認
環境情報
サイト名:Hey,Siri!「ニート 生き方 どうすれば」を教えて!
サイトURL:https://neetneed.net
ホームURL:https://neetneed.net
コンテンツURL:/wp-content
インクルードURL:/wp-includes/
テンプレートURL:/wp-content/themes/cocoon-master
スタイルシートURL:/wp-content/themes/cocoon-child-master
使用スキンURL:/wp-content/themes/cocoon-master/skins/skin-mixblue/style.css
Wordpressバージョン:5.0.2
PHPバージョン:7.2.11
ブラウザ:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
サーバーソフト:LiteSpeed
サーバープロトコル:HTTP/1.1
エンコーディング:gzip, deflate, br
言語:ja,en-US;q=0.9,en;q=0.8
テーマ名:Cocoon
バージョン:1.4.8
カテゴリ数:18
タグ数:15
ユーザー数:1
子テーマ名:Cocoon Child
バージョン:0.0.5
利用中のプラグイン:
Akismet Anti-Spam 4.1
BackWPup 3.6.6
Broken Link Checker 1.11.5
Classic Editor 1.3
Compress JPEG & PNG images 3.1.0
Contact Form 7 5.1.1
Edit Author Slug 1.6.0
Google XML Sitemaps 4.1.0
Limit Login Attempts Reloaded 2.7.1
LiteSpeed Cache 2.8.1
PS Auto Sitemap 1.1.9
WP Multibyte Patch 2.8.2
エラーについて検索
ググっても中々情報が出てこないので、メタ検索エンジンを使って調べる。
メタ検索エンジンについてはこちら

※簡単に説明すると、Googleだけでなく、Yahoo!やTwitterなどを含めた、複数の検索エンジンやSNSで一括検索が行えるというもの。つまり、幅広い情報を効率よく集めることができる。
今回使用したメタ検索エンジンはこちら
集まった情報・類似の例
今回のエラーに近いケースについての情報を見つけることができた。
「無効な投稿形式」というエラーに悩まされている方は、以下のページも参考になるかと思われる。
わかったこと・試したこと
- 「無効な投稿形式」≒「無効な投稿タイプ」
- 類似の例はあったが、同一の例は見当たらない
- 「nginx」や「カスタム投稿タイプ」「registerposttype」などがキーワードのように思える。
- しかし、CPanelのファイルマネージャーや、管理画面「テーマの編集」で検索してみても、それらのキーワードに関する記述は見当たらない。
- そもそも、「nginx」や「カスタム投稿タイプ」が何かが分からない。
- そこから調べていくと非常に労力がかかる上、理解できたところで解決するかも定かではない。
内容を踏まえての結論:類似の例や解決法を調べたはいいが、自分の場合に応用することができない
結論を踏まえての方針:フォーラムや質問サイトで知恵を借りる方向で進める
ということで、以下のページにて相談・質問を行う
フォーラムで相談した結果
このブログでは、cocoonという無料のWordPressテーマを利用している。
製作者であるわいひらさんは、テーマに関するフォーラムを設けており、そこでテーマのカスタマイズや不具合、ブログの相談などを受け付けている。
ブログを運営するにあたり、そのフォーラムには僕も何度もお世話になっており、今回のエラーに関する相談を投稿することにした。
※わいひらさんについて、詳しくは下記にて

以下、フォーラムでの検証を経て得た情報について
フォーラムでの検証内容
- WordPressの更新
- わいひらさんの環境では再現できない
- テーマによるものではないと考えられる
- サーバーのキャッシュ機能を確認
- Gutenbergエディターの設定を確認
- ブラウザキャッシュを削除
- CDNの確認
- PHPのバージョンを確認
- 全てのプラグインをオフ
- デバッグモードの有効化
- テーマの切り替え
WordPressの更新
- 最初に行った内容
- テーマ、プラグイン、翻訳など全てを最新版に更新
- 変化無し
結果:更新やアップデートは関係ない
わいひらさんの環境では再現できない
つまり、僕の環境に問題がある可能性が高い。
使用しているテーマ(cocoon)によるエラーではないと考えられる
となると、原因は以下に絞られる
- プラグイン
- カスタマイズ
- その他、僕が独自に操作したもの
サーバーのキャッシュ機能を確認
サーバーのキャッシュ機能が有効になっていると、動作確認が正常に行えない場合があるらしい。
というわけで、利用中のカラフルボックスでも調べてみる。
※サーバーのキャッシュ機能とは、例えばエックスサーバーのmod_pagespeedなどが該当する
経緯
- カラフルボックスのキャッシュ機能について調べたところ、こちらのページに行き着く
PHPのキャッシュ(OPcache)を無効にする方法 – ColorfulBox(カラフルボックス) サポートサイト
- ページの内容を見て、今回のエラーに何かしら関係はないだろうかと考え、実践を試みる
- しかし、.htaccessファイルが複数あり、どのファイルを編集すればいいのかが分からなかったため、サポートにて問い合わせる
- すごく丁寧な回答を貰う。.htaccessファイルについて理解を深める
- その時学んだ内容についてはこちら

- その後、わいひらさんから「カラフルボックスにはキャッシュ機能は無い」との指摘をいただいたため、作業を一時中断する
結果:不明。検証する前に解決してしまった。
Gutenbergエディターの設定を確認
Classic Editor プラグインを有効にしている場合、cocoon設定の「Gutenbergエディターを有効にする」にチェックマークが入っている必要があるらしい
結果:問題無し。チェック済みだった。
ブラウザキャッシュを削除
利用しているブラウザはGoogle Chrome
Chromeのキャッシュを削除してみる
手順
- メニューバー内の「Chrome」やブラウザのツールバー内の「その他のツール」から「閲覧履歴を消去」を選択
- 削除したい情報にチェックマークを入れる
- 削除する情報の期間に「すべて」を選択
- 「閲覧履歴データを消去する」をクリック
結果:変化無し
補足:「CSSが反映されない」などの不具合であればこちらの方法で解決する場合がある。
今回行った「サーバーのキャッシュ機能を確認」「CDNの確認」「全てのプラグインをオフ」などの対処も、CSSの不具合への対処方法として紹介されている。
その他、「CSSが反映されない」系のトラブルシューティングはこちら

CDNの確認
CDNが何なのかはわからないが、とにかく確認してみる
とりあえず、利用しているかいないかだけ確認する
利用していなければ、今回の件とは関係ないと思われる
手順
- 下記のページを開く
- ドメイン(neetneed.net/)を入力して「チェック!」
- 「Name Server」「CDN」「CloudFlare」など、関連性の高いキーワードでページ内検索
- それらしい記述を探す。
結果:それらしい記述は見当たらなかったため、「CDNは利用していない」と判断する。
CDNやWhois情報が何なのかはわからないが、今回の件への関連性は低いと判断
PHPのバージョンを確認
- 今回のエラーには関係なかったが、別の問題点が発覚
- フォーラムへの相談にあたり、環境情報を提供すると、「PHPのバージョンが推奨環境を満たしていない」との指摘を受ける
- どうやら、cocoonインストール時に行った設定が正しく反映されていなかった模様
- cocoonの推奨バージョンは7.0 以上、WordPressの場合は7.2 以上
- また、PHPの7.0 以下は、セキュリティサポートが年内に終わるとのことで、別途対処する必要が発生
- カラフルボックスに問い合わせで解決
- その他詳細・解決法はこちらのページにてhttps://neetneed.net/colorfulbox-php-change/
結果:解決できたが、今回のエラーとは無関係
全てのプラグインをオフ
全てのプラグインを無効にすることで、エラーに何か変化がないか調べる。
手順
- ワードプレス管理画面
- プラグイン→インストール済みプラグイン
- (全てのプラグインを選択した状態で)「一括操作」から「停止」→「適用」
結果:変化無し、プラグインは関係ないことが判明
となると、カスタマイズが原因の可能性が濃くなった
デバッグモードの有効化
WordPressにはデバッグモードというものがあり、その状態では更に詳しくエラーを調べることができるそうだ。
というわけでデバッグモードの有効化を行い、エラーについて検証してみる
手順
- CPanelのファイルマネージャー画面を開く
- ファイルマネージャーで「wp-config.php」を検索
- 「wp-config.php」を開く
- ファイル内84行目の記述を、以下のように編集する
define('WP_DEBUG', true);
補足
- 上記の記述を「true」とすることで、デバッグモードが有効になる
- デバッグモードを無効にしたい場合は、下記のように編集する
define('WP_DEBUG', false);
- デバッグモード有効化中は、エラーや警告をブラウザ上で視認することができるため、初心者でもエラーについて調べやすくなる
結果
デバッグモードを有効化して、改めてエラーを再現してみると、下記のエラーメッセージを確認することができた。
Notice: Array to string conversion in /home/xxxxxxx/public_html/neetneed.net/wp-admin/edit.php on line 266
この「edit.php on line 266」という部分に注目し、「edit.phpの266行目」を確認してみたところ、以下の記述が見受けられた
add_screen_option( 'per_page', array( 'default' => 20, 'option' => 'edit_' . $post_type . '_per_page' ) );
しかし、残念ながら肝心の内容が理解できないため、これだけでは解決には至らなかった。
というわけで、今度はエラーメッセージの「Notice: Array to string conversion」という部分に注目してみた
すると、下記のような情報を見つけた。
Notice: Array to string conversionとは
- PHPのエラーの一つで、「配列を文字列に変換することができない」というエラーらしい
- 基本的にエラーではなく通知のようなもので、重大なエラーが発生するものではないとのこと
- 参考にしたページはこちら
【PHP】Notice: Array to string conversion 警告メッセージの対処方法(複数) | MaryCore
結果:エラーに関して新たな情報が手に入ったが、PHPに関する知識がないため、具体的な対処法までは調べることができなかった。
テーマの切り替え
フォーラムにて相談する中で、わいひらさんからテーマ切り替えでの検証を提案されたが、調べてみるとテーマ切り替えに伴う作業で少し不安な点があった為、保留。(一部の設定が初期化されるらしく、可能な限りバックアップを使用する場面は避けたいと考えた為)
※テーマ切り替えに関して、調べたページはこちら
WordPress:テーマを変更する時は注意!メリットとデメリット
WordPressでテーマ変更時の注意点と事前にやることをリストアップ|きにぶろぐ\.com
代わりにテスト環境を構築して、そこで安全に検証することにした。
結果から先に伝えると、この「テスト環境の構築」でエラーを解決することができた。
その前に一応、質問サイトでの検証結果についても触れておく。
teratailで質問した結果
「フォーラムに書いた内容を改めて書き直すのもな〜」と思い、「詳細はこちらのページに書いてあります。」とフォーラムへのリンクを貼って質問を投稿したら、
複数のユーザーから「やってほしいことだけを記載した丸投げの質問」という意見がありました
ということで低評価を受けた。
回答・意見は一切無し。
自己解決したことを報告したら、更に低評価を受けた。
結果:成果なし
というわけで解決編に移る。
解決(知識がなくても一応できた!)
テスト環境にて検証
テスト環境の構築方法についてはこちら

テスト環境にてカスタマイズを一つずつ再現していった結果、原因とみられる記述が判明
行った手順は、以下の通り
2.テスト環境のfunction.phpにて、本番サイトで行ったカスタマイズを一つずつ再現し、エラーとの関連性を調べる
3.「無効な投稿形式」エラーが発生した段階で、原因となるカスタマイズを特定
4.本番サイトのfunction.phpから、原因とみられるカスタマイズを削除
上記の検証について、別の形で説明すると、以下のようになる
テスト環境+カスタマイズ1→エラー発生せず
テスト環境+カスタマイズ2→エラー発生せず
テスト環境+カスタマイズ3……
・
・
・
……テスト環境+カスタマイズx→エラー発生
→カスタマイズxが原因の可能性が高い!
というわけで、上記の手順で原因とみられるカスタマイズを特定することができた。
今回、原因とみられるカスタマイズは、以下の記述だった。
// カテゴリーアーカイブに固定ページを含める
function add_page_to_category_archive( $query ) {
if ( $query->is_category== true && $query->is_main_query() ) {
$query->set('post_type', array( 'post', 'page' ));
}
}
add_action( 'pre_get_posts', 'add_page_to_category_archive' );
テスト環境では、上記のコードの有無によってエラー発生が変化した。
上記のコードがあった時にエラーが発生し、上記のコードを削除すると、エラーは発生しなくなった。
念のため他のカスタマイズについても検証を行ったが、上記のコード以外はエラー発生に変化は生じなかった。
というわけで、本番環境(このサイト)にて、上記のコードをfunction.phpから削除した。
しかし、それだけではエラーは解決しなかった。
というわけで、今度は上記のコードについて調べてみた。
原因とみられる記述について
上記のコードは、このサイトに対して行ったカスタマイズの一部だ。
そのカスタマイズは、こちらのサイトを参考に行った。

原因とみられる記述は、上記のサイトの「固定ページにカテゴリーやタグを紐づけ設定」という部分の一部だ。
この「固定ページにカテゴリーやタグを紐づけ設定」という部分には、2つのカスタマイズが紹介されており、僕は2つとも採用した。
2つとは、原因とみられる記述を含んでいる「カテゴリーを紐づけ」というカスタマイズと、「タグを紐付け」というカスタマイズである。
「タグを紐付け」というカスタマイズのコードは、以下の通りだ。
//固定ページにタグを設定
function add_tag_to_page() {
register_taxonomy_for_object_type('post_tag', 'page'); }
add_action('init', 'add_tag_to_page');
//タグアーカイブに固定ページを含める(refineProではNG)
function add_page_to_tag_archive( $obj ) {
if ( is_tag() ) {
$obj->query_vars['post_type'] = array( 'post', 'page' );
}
}
add_action( 'pre_get_posts', 'add_page_to_tag_archive' );
上記のコードのうち、「//タグアーカイブに固定ページを含める」という部分には、原因とみられる記述と似ている部分が多い。
そこで「こっちの記述もエラーと関係があるのでは?」と考えたため、本番サイトから「//タグアーカイブに固定ページを含める」に該当するカスタマイズも削除してみた。
すると無事エラーは解決した。記事の一括編集を問題なく行えるようになった。
テスト環境では「// カテゴリーアーカイブに固定ページを含める」の方でエラー発生が分岐したが、本番環境では「//タグアーカイブに固定ページを含める」で分岐することがわかった。
厳密にいうと、以下のようになる。
「// カテゴリーアーカイブに固定ページを含める」をカスタマイズした状態で、投稿一覧で任意のカテゴリーを絞り込み検索→エラー
「//タグアーカイブに固定ページを含める」をカスタマイズした状態で、投稿一覧で任意のタグを絞り込み検索→エラー
理由は不明
まとめ
――以上が今回の一部始終になります。
まとめると、以下のようになります。
- テスト環境は作った方がいい
今回のようにエラーの検証だったり、カスタマイズ前の検討や、様々な実験に使うことで、トラブルを防ぐことができる。
- 一つ一つ検証するのが大事
面倒でもやるしかない。
知識のある人なら、Automatorやimacrosなどで自動化できるかも?
- 相談する時は詳しく説明する
フォーラムや質問サイトを利用する時は、環境情報や現時点で把握できていることについて、可能な限り説明する。
エラーやトラブルが発生した時には、上記の3点が重要になってくると思われる。
(バックアップは前提・最後の手段として)
しかし…
今回は運よく解決できたとはいえ、結局最後は勘に頼ってしまった。
そのため、詳細な原因の特定には至らなかった。
「原因とみられる記述」を絞り込むことはできたが、「その記述の中の、どの部分が問題なのか?」を特定することができなかった。
やはりPHPの知識がないのに、手当たり次第にカスタマイズを採用するのはリスクが伴うらしい。
しかし、PHPに関しては「HTMLが静で、PHPが動」程度の漠然とした認識しか持ち合わせていない。
また、1から勉強するにしても、正直かなり気が重い。
ブログにワードプレスにマーケティングにアフィリエイトに転売にネットビジネスにライティングにSEOに……と、ただでさえ勉強科目がキャパオーバー気味なのに、これ以上増やしたら確実にクラッシュする。
それに、PHPについて学ぶには、まずHTMLについて学ぶ必要があるとのことだ。そう考えると、時間的にも体力的にも今は無理なように思える。
でも、今のうちにPHPについて学ばないと、また今回のようなエラーに見舞われることになるだろう。
ではどうすればいいか?
というわけで、次回のページはこちら


次のページ

要約
PHP学習サイトをまとめました。
ゲーム形式で学べるサイトや、スマホで隙間時間を活用しつつ学べるサイトなどがあります。
意味
目を通しておく事で、PHP学習に対するハードルが下がると思います。
自由なコメント