あんまりない状況だと思うけど。
シチュエーション
WordPressで作ったWEBサイトがある。これにはカスタム投稿を導入している。
カスタム投稿を作るにあたり、functions.phpにコードを追加する方法(=非プラグイン)を取っている。
WEBサイトを全面的にリニューアルすることになり、テーマの切り替えで対応する流れになった。
カスタム投稿の設定はfunctions.phpで行っているわけで、だからテーマを切り替えたらカスタム投稿がなくなってしまう。
従来のテーマと同様の記述を新テーマで書いてもいいんだけど、プラグインで対応したほうがテーマに縛られないから楽じゃない?という状況。
結論
コードに記述して設定したカスタム投稿は、プラグインのカスタム投稿と親和性がある。
詳しく言えば、functions.phpに記述して設定したカスタム投稿は、その記述のないテーマに切り替えたら非表示になる。だけどデータベースにはカスタム投稿の情報が残ってる。記述と同様の内容でプラグインによってカスタム投稿を作れば、投稿情報はサルベージされる。なので、プラグイン→自作っていう逆のパターンでも通用する。
具体例
投稿タイプ「sample」でカスタム投稿を自作した。
add_action('init', 'create_post_type');
function create_post_type()
{
//投稿時に使用できる投稿用のパーツを指定
$supports = array(
'title', //タイトルフォーム
'editor', //エディター(内容の編集)
'thumbnail', //アイキャッチ画像
'author', //投稿者
'excerpt', //抜粋
'revisions', //リビジョンを保存
);
register_post_type(
'sample', // 投稿タイプ名
[
'labels' => [
'name' => 'サンプル投稿', // 管理画面上で表示する投稿タイプ名
'add_new' => '新規追加', // 新規追加のラベル
// 'add_new_item' => 'サンプル投稿新規登録', // 編集画面ラベル(新規登録時)
// 'edit_item' => 'サンプル投稿編集', //編集画面ラベル(既存投稿編集時)
// 'menu_name' => 'サンプル投稿', //管理画面メニュー(親ラベル)
// 'all_items' => 'サンプル投稿', //管理画面メニュー(一覧ラベル)
// 'search_items' => 'サンプル投稿を検索' , //検索フォームボタンラベル
// 'singular_name' => 'サンプル投稿識別名', // カスタム投稿の識別名
],
'public' => true, // カスタム投稿タイプの表示(trueにする)
'has_archive' => true, // カスタム投稿一覧(true:表示/false:非表示)
'menu_position' => 5, // 管理画面上での表示位置
'show_in_rest' => false, // true:「Gutenberg」/ false:「ClassicEditor」
'supports' => $supports
]
);
}
引用:https://wordpress-template-media.com/custompost/
管理画面左メニューにカスタム投稿が追加されるので、記事を投稿する。
テーマを切り替える。切り替え先のテーマにこの記述はないので、カスタム投稿はメニューから消える。
Custom Post Type UIをインストールする。
以下の内容を含む形で投稿タイプを追加する。
- 投稿タイプスラッグを「sample」にする
その他、投稿パーツやらアーカイブやら、記述と同内容に設定する。
管理画面左メニューにカスタム投稿が追加され、投稿一覧を見ると投稿した記事が表示される。
つまり
CPT UIでいう「投稿タイプスラッグ」が同じ内容になっていれば大丈夫ということ。
タクソノミーも一緒
タクソノミーに関しても、スラッグが同値であればサルベージできる。
移行時の注意点
最低限、スラッグが一緒であればサルベージできる。これは最低限。
前項で軽く触れてる通り、カスタム投稿は色々と設定ができるので、同環境を作るにはそこも合わせる必要がある。なので、自作→プラグイン、プラグイン→自作のどちらにせよ、旧環境の内容が把握できる状態で、照合しながら構築しなければ移行すべきでないというか、どっかに齟齬が出てくる。リスクが発生する(記事のアーカイブとか、タクソノミーの親子化とか)。
どっちで組むべきか
どちらにせよ作って終わりなので、普通に考えるとどっちでもいい。ただし、リニューアルとかの大幅な工事になったときを考えたらどうか。
自作する場合はphpの書式さえ守れば汎用性は高いので、例えば関数化して複数のカスタム投稿の量産ができる。で、個別に一部設定を変えることも普通に考えられる。分かってる人間だったらそんなに手間はない。
ネックはやっぱり引き継ぎで、何がどうしてこうなってるのかがわからないと手の打ちようがないというか、解読しなきゃで面倒くさいというか。
プラグインの方が楽なんですよ。でも、サービスが終わったらとかアップデートでバグったらとか、そういうのがある。メジャーどころならまず無いけど。あと、プラグインに傾倒すると処理が重くなる可能性もある。
どっちがいいんですか。
コメント