前の記事「下書き保存で止めたら、公開後の工程が混ざらなくなった」で、下書き保存のあとにも公開後の工程が残っていた話を書いた。
公開されたあと、DB、目次、series、内部リンクを別々に進めた。
工程を分けたから、どこまで終わったかを追えた。
その中で、ひとつ気になった記録がある。
`articles.db`への登録だ。
公開した記事は、WordPressにはある。
URLもある。
それでも、DBにいないうちは、編集部の記録としてはまだ見つけにくかった。
この記事で見ているのは、articles.db という台帳を作った話ではない。台帳はもうある。そのうえで、公開された1本の記事を、あとから探せる記録として台帳へ入れた話である。
公開しただけでは、記事の居場所がまだ決まっていなかった
公開すると、読者は記事を読める。
それで記事は完成したように見える。
実際、WordPressの投稿一覧にも出てくる。
でも、編集部があとから記事を探すときに見る場所は、WordPressだけではなかった。
どのタイトルか。
どのURLか。
いつ公開したか。
どのカテゴリか。
どの投稿IDか。
公開済みの記事を、こうした記録と一緒に見直す場面がある。
公開は、読者に見える状態だ。
管理は、その記事をあとから見つけられる状態だ。
この二つは、同じではなかった。
目次と内部リンクの記事では、wp_post_id：101だけが先に残っていた
以前の記事「目次と内部リンクで、ブログを記事の集まりからサイトに変える」では、先にWordPressへ下書きを保存した。
その時点で、`wp_post_id`は101だった。
編集画面を開ける状態になった。
ただ、`articles.db`にはまだ記録がなかった。
WordPressには記事がある。
けれど、管理台帳にはまだいない。
公開後に登録すると、`blog_articles`のIDは12になった。
件数は11件から12件へ増えた。
たった1件の追加だ。
それでも、101という投稿IDだけで残っていた記事に、管理記録の中の居場所ができた。
articles.dbへ登録すると、記事を一覧で追えるようになった
articles.dbに残したのは、本文そのものではない。
タイトル。
URL。
公開日。
カテゴリ。
`wp_post_id`。
`wp_status`。
記事をあとから照合するときに必要になる情報だった。
WordPressを開けば、もちろん記事は見つかる。
でも、公開済みの記事を一覧で見て、URLや投稿ID、状態を確かめたいときは、DBの記録がある方が早い。
記事が公開されたことと、記事を管理できることは別だった。
DB登録は、記事をもう一度書き直す作業ではない。
公開済みの記事を、編集部が探せる一覧へ残す作業だった。
DB登録を起点に、目次・series・内部リンクの判断が始まった
DBへ登録したからといって、目次や内部リンクが自動で増えるわけではない。
series番号も、DBには入れていない。
S2の何本目かは、`series_s2.md`で管理している。
それでも、DBの記録があると、公開済みの記事を同じ情報で照合できる。
このURLの記事は、どの投稿IDか。
公開状態はどうなっているか。
一覧に二重で入っていないか。
その確認をしたうえで、目次に載せるかを判断する。
seriesの行を公開済みに変える。
必要な記事だけに内部リンクを置く。
DB登録は、それらを一気に終わらせる工程ではなかった。
次の判断で、同じ記事を見失わないための記録だった。
前の記事で分けた公開後工程に、管理の記録を置いた
前の記事では、公開後の作業を一度に混ぜなかった。
その記事の投稿IDは171だった。
公開後に`blog_articles`へ登録し、IDは21になった。
件数は20件から21件へ増えた。
そのあとで、目次へ1行を足した。
`series_s2.md`の該当行を更新した。
本文の2か所だけに内部リンクを施工した。
DB登録は、公開後工程の先頭に置かれた記録だった。
誰が担当するかを分けた話は、前の記事で書いた。
今回は、その公開済み記事をどの記録へ残したかを見ている。
記事が進んだことを知るためではない。
あとから、その記事を確かめるためだ。
公開した記事を、あとから探せる形で残した
公開すると、記事は読者に届く。
でも、編集部の中では、それだけで終わらなかった。
記事がどこにあるか。
どのURLか。
どの投稿IDか。
公開済みか。
あとから確かめるための記録を、`articles.db`に残した。
記事を公開するだけではなく、あとから探せる形で残した。
コメント