![Blog Admin](https://pxa.xsrv.jp/test103/wp-content/uploads/2018/11/icon001.png)
このサイトではないのですが。
WordPressでカスタム投稿タイプを設定しました。手動です。
正しく設定したはずなのに、投稿ページが404になりハマりました。
解決できたので記録です。
![WordPress](https://pxa.xsrv.jp/test103/wp-content/uploads/2023/08/wordpress-004-300x169.jpg)
WordPress
「flush」は怖かったので
WordPressもPHPも、あまり詳しい知識がありません。
ただ、他のプログラミングの経験はあるので、なんとなくで騙し騙し8年ほどやってきました。
今回も騙し感がありますが、解決したので問題なしです!
プログラミングの嗅覚はよいほうだと思っています!!
既存の更新なら任せてくださいw
うまくいきましたし、備忘録を残しておきます。
カスタム投稿タイプで404
![ERROR](https://pxa.xsrv.jp/test103/wp-content/uploads/2019/12/error-002-300x169.png)
functions.php
に手書きでコード追加し、カスタム投稿タイプを設定しました。
ゼロベースのスタートではなく、既存のカスタム投稿タイプの設定用コードをコピーして、名前などを修正しました。つまり、すでに実績のある設定の名前を変えただけです!
そのはずだったのですが、問題が発生して悩むことになりました。
一部のページで404が返ってしまい、作業が滞ってしまったのです。。
まずは発生した事象と調査状況の確認です。
実際とは異なりますが、事例として、スラッグは「xxx」とします。
カスタム投稿タイプ「xxx」の設定です。
page、single、sidebarも作成
![ノイズ](https://pxa.xsrv.jp/test103/wp-content/uploads/2019/12/error-004-300x169.jpg)
発生事象の確認です。
以下の状態でした。
page-xxx.php
: 表示されるsingle-xxx.php
: 404sidebar-xxx.php
: 表示される
page-xxxでsidebar-xxxを呼んでいるので、いっしょに確認できていました。
single-xxxは、新規投稿でプレビューすると正しく呼び出されているようなのですが、公開URLをたたくと404に遷移する状態でした。
ひたすら設定を確認するが、正しい
![ノイズ](https://pxa.xsrv.jp/test103/wp-content/uploads/2019/12/error-003-300x169.jpg)
調査状況の確認です。
既存の設定を踏襲しているだけです。
しかも、新規投稿じのプレビューでは表示確認までできていたので、コードに間違いがあるとは考えにくいのです。
とはいっても、万が一やらかしている可能性もあります。
念のため調査しておきました。
問題はなかったわけですが。。
function.php
のコード比較
カスタム投稿タイプを設定する部分をテキストエディターにコピーして、コードを比較しました。
Diffをとって、変更部分をじっくり確認です。
違っていたのはスラッグのところとラベル名称だけで、他は同じものでした。
つまり問題なしです。
single-xxx.php
のコード比較
既存のファイルと今回作成したファイルをDiffしました。
変更部分と削除部分を目で見て、問題ないことが確認できました。
そもそも、今回のsingle-xxx.php
ファイルは既存のファイルのDuplicateです。
編集したのは、既存のファイルから不要な部分を削除して、 サイドバーの呼び出し部分などの名称を変更しただけです。
メインコンテンツは投稿で書き込む想定ですから。
DB上のURL構造不備を疑う
同じような症状が発生しているのかと、ダメモトでググってみたところ、いくつかそれらしいものがヒットしました。
そうして分かってきたことは、WordPressのリライトルールなるものがあり、場合によってはカスタム投稿タイプの設定時にうまくDBに反映されないことがあるということでした。
既知の問題に悩まされていたのですね。
経験不足を痛感させられました。
そして紹介されていた解決策があります。
「flush_rules
」とか「flush_rewrite_rules
」とかいったことです。
WordPressのDBの登録状態をリセットするようなことなのだと思います。
![Blog Admin](https://pxa.xsrv.jp/test103/wp-content/uploads/2018/11/icon001.png)
「flush」って怖くないですか?
しかもfunctions.php
に書いて実行させるとか。。
ちょっと恐ろしいので、さらに調査です。
設定から更新できる!
![Google 検索](https://pxa.xsrv.jp/test103/wp-content/uploads/2021/01/chromebook-sample-002-300x169.jpg)
もう少し調べてみると、リライトルールの正しい更新方法のようなものが見えてきました。
コードを書くのは最終手段として、まずは画面(GUI)からやれることをやってみたいのですよ。
そこで分かったことは以下です。
- flushは処理の負荷が大きい
- 強制実行するとタイミングによっては不備の原因になりかねない
- 設定から同等のことが可能
設定 → パーマリンク → 変更を保存(何も変更していなくてもよい)
![WordPress](https://pxa.xsrv.jp/test103/wp-content/uploads/2019/01/wordpress-001-300x169.jpg)
「変更を保存」ボタン押下で、リライトルールの更新がスケジュールされるようです。
サーバーリソースに余裕があるタイミングなら、他の処理との兼ね合いも考慮された状態で、早いタイミングで実行されることでしょう。
夜間に実施し、結果、すぐに問題は解決しました。
ほっとしました。
インターネットの集合知に感謝です。
Copilotに聞いてみればよかったと反省しつつ、細かい調査はまだ人力のほうが確実かもしれないと感じました。。ファクトチェックとコストが同じような気がするのですよ。。
ご意見やご感想などお聞かせください! コメント機能です。