web-dev-qa-db-ja.com

ポストプレビューメカニズムアーキテクチャ

WordPressが公開前にプレビュー投稿をどのように処理しているのかを調べています。

編集したい投稿の編集モードに入り、いくつかのものを変更し、プレビューを押し、プレビューを変更して表示します。

私の質問は:

  1. プレビュー投稿は、ライブと同じようにレンダリングされ、ルーティングされていますか?
  2. そうであれば、WordPressはその投稿の別のエンティティをデータベースに保存しますが、それは元の投稿と同じように見えますが変更されていて、そのエンティティはレンダリングされますか?
6
Dima Gimburg

たとえあなたが「プレビュー」のためにたった一つのボタンを押したとしても、それは2つの異なる「ルート」で終わるかもしれません。

そのようなものです

http://example.com/postname/?preview=true

2番目は次のようなものです。

http://example.com/postname/?preview_id=152&preview_nonce=xxx&preview=true

つまり、最初の引数にはpreviewクエリ引数が含まれ、2番目の引数には引数が含まれます。

  • preview_id
  • preview_nonce
  • preview

引数を問い合わせます。

previewクエリ引数はWordPressに、適切な権限を持つユーザーに未公開の投稿の視覚化を許可するように伝えます。

投稿が "ドラフト"として保存されていて、ログインしている場合は、投稿のURLに?preview=trueを追加するだけで、公開されているのと同じようにフロントエンドで表示できます。

2番目の種類のURLは、ポスト自動保存が実行されたときにJavaScriptを介してプレビューボタンに attached です。

自動保存では、投稿テーブルにその投稿がそのまま(変更も含めて)格納されますが、実際の投稿タイプは "revision"タイプに置き換えられます。

より多くの情報を見つける ここ

自動保存はバックエンドで定期的に実行されますが、[プレビュー]ボタンをクリックしたときにも実行されます。このように、プレビュー画面では最後の変更が常に表示されます。

これが起こるのです:

  1. 「プレビュー」ボタンをクリック
  2. WordPressは現在の投稿を改訂としてpostsテーブルに保存します
  3. Post urlとpreview_idpreview_noncepreviewクエリ引数を含むブラウザページが開かれます
  4. WordPressはpostsテーブルからpostオブジェクトを引っ張ります
  5. previewクエリ引数が存在するため、WordPress
    1. 現在のユーザーがログインしており、適切な機能を持っていることを確認します。
    2. ノンスを検証する
    3. 前回のチェックに合格した場合、WordPressはデータベースから最後の投稿のリビジョンを取得し、リビジョンの投稿名と投稿者が4で取得した投稿オブジェクトの投稿名と投稿者と一致するようにします
    4. 有効なリビジョンが見つかった場合、4の位置で取得された投稿オブジェクトは、リビジョン投稿オブジェクトに置き換えられます

それに加えて、プレビューは通常のフロントエンドの通常の投稿要求と同じ方法で処理されますが、ページの表示に使用される投稿オブジェクトがリビジョンデータベースの行から取得されると、最後の変更は保存されません。 。

6
gmazzap