WordPress制作、カスタマイズ、Webシステム開発とSEO対策

外部から記事を登録したら予約投稿が作動しないので、WordPressの予約投稿のメカニズムを探ってみた

WordPressの「投稿」画面を使わないで、別のシステムから直接SQL文を発行して記事をぶっこむ仕様のWebアプリを製作中。

本題の前に、WordPressの主な記事ステータスについてご説明します。

WordPressの記事ステータス

記事ステータスとはつまりその記事がどのような状態で保存されているか、ということです。
主なものを紹介すると、

  • 下書き(draft)
  • 公開中(publish)
  • 予約投稿(future)
  • ゴミ箱(trash)

が代表的なところです。
他には

  • レビュー待ち(pending)
  • 自動保存(auto-draft)
  • 非公開(private)
  • リビジョン(inherit)

があります。

さて、今回開発していたWebアプリでは、あえてpublishedではなく、futureで記事を登録していました。
なぜかというと記事の公開時にTwitter連携をしていたのですが、最初からpublishedで登録すると、Twitter連携アプリが作動する「記事公開時フック」を通らないので、Twitterに記事が配信されなかったからです。
そこでわざと予約投稿にして、公開はWordPress側にさせることでフックを通そう、という算段です。

しかし、予約登録まではうまくいくものの、公開予定時間になってもwp-cronが作動せず、「予約投稿の失敗」になってしまう。

WordPressの予約投稿のメカニズム

未来の日付で記事が投稿された場合、WordPressの記事ステータスが「future」になります。
この状態で公開日時以降にそのWordPressのどこかにアクセスが有った場合、wp-cronが作動して記事の公開処理が行われます。
cronと言ってもサーバーで時限処理をするcronと違って、WordPressにアクセスされた時に日時を持って公開判定をするので、擬似的なcronといえるでしょう。

しかし、予約投稿には
・記事の日付
・記事のステータス

以外にも、DB上では情報の更新がありました。
今回WordPress上から投稿した時と何が違うのか調べてみると、単純に記事の投稿時刻とステータスだけではなく、wp_optionsの中の「cron」というテーブルに予約動作に関する情報が登録されていたのでした。

wp-optionsのcronを調べてみる

中をのぞいてみると、このレコードは記事予約の他にはakismetのスパム削除スケジュールなど、WordPressが扱う予約動作全般の情報を保存しておくものでした。
で、今回の予約記事に関しては

i:1368027884;
a:1:{s:19:”publish_future_post”;
a:1:{s:32:”2b1da4ca66a51f7e26369cbe52edd54f”;
a:2:{s:8:”schedule”;
b:0;
s:4:”args”;
a:1:{i:0;
i:567;

という情報が増えていました。
publish_future_postはこの予約動作の種類を、最後のi:567は記事IDを示している、といった程度は分かるのですが、「2b1da4ca66a51f7e26369cbe52edd54f」などはどうもWordPressが乱数を発生させて割り当てているようで、これを解析して再現するのは骨が折れそうです。

その労力を考えると、素直にWordPressのXML-RPC投稿を利用したり、Twitterの投稿アプリを追加開発したりしたほうが良さそうな気がします…。

普通に予約投稿が失敗する場合

こういうなにか特別なことをしてるわけではなく、普通に運用しているはずのWordPressで予約投稿がうまくいかない場合は、こちらの記事が参考になるかと思います。
WordPressの予約投稿が失敗する件の解決方法

コメントを残す