先日、投稿記事の『ごみ箱』の中身を削除しようとしたら、手違いで残したい記事までいくつか削除してしまいました。バックアップがあるので、焦ることはありませんが『そもそも記事データって、どこに保存されているのかな？』って思いますよね。
今回はワードプレス『HTML』の保存先について、探りたいと思います。
記事データは『MySQL』
ワードプレスでブログを書いていると、データではなく、テキスト形式でバックアップを取るべきか迷うことがあります。結果的に面倒臭いから取らないんですけど、日記みたいに保存しておくと役立つ時が来るのかも知れません。
まず結論を言うと、記事データは『/public_html』内にはありません。
ちなみに、WordPressの記事表示は『動的』という存在で、少々ややこしいのです。
でも確実に記事は『MySQL』内にあるので、安心して下さいね。
ただし、今回は既にブログから削除してしまっているので、バックアップ有きの話です。
定期保存の重要性がまだ分からない方には、辛い現実として次に生かして下さい。
目的違いになると申し訳ないので、今回の結果をまず記載します。
- タイトルが分かる。
- テキスト形式の『HTML』が回収出来る。
- 記事IDは出るが、URLは分からない。
- メタディスクリプション、タグキーワードは分からない。
やり方によって、深く探ればくつがえるかも知れませんが、今回はこの程度で納めます。
仮データベースを作ろう
ワードプレスは、まずデータベースを作ってからのサイト構築で、次にデータと紐付けます。
この関係性が絶対的なので、簡単にバラすことは出来ません。
よって、バックアップには必ず『MySQL』が付いて来るのです。
ならば『MySQL』をローカル環境で開き観覧すれば記事が見れそうですが、残念ながら超長い暗号が表示されるだけです。しかし、答えは簡単。
データベースとしてサーバー経由ならば開けます。
この辺りは、サーバー引っ越しによる独自ドメイン移管を経験している方であれば、問題無くこなせるはずです。
現在『エックスサーバー』で運営していますが、移管前の『さくらサーバー』が期限まで使えるので、今回はリスク軽減の為、さくらで行いました。勿論、他社のサーバーでも同じなので、ご安心下さい。
『コントロールパネル』⇒『アプリケーション設定』⇒『データベースの設定』
『データベースの新規作成』を行います。
仮なので『データベース名』は適当で大丈夫です。
『phpMyAdmin』へログインします。
中身は当然、空の状態です。
- 上部バーより『インポート』を選択
- ローカルにある、バックアップファイルを選択
- 実行でインポート
注意ポイント
② 拡張子は『.msql』ではなく『.zip』の状態にして下さい。
記事『HTML』は『posts』の中
『MySQL』って、触るの怖いですよね。
だけど、ワードプレスはバックアップがあれば大丈夫です。
『接頭辞』の後ろに『posts』とあるものを探します。
この中に、記事データが詰まっています。
『pose_title』で記事を探します。
『ID』は単純に記事IDです。
任意のタイトルが見付かったら『編集』へ入ります。
ちなみに、記事数が多いブログは探すのが大変です。
画像も記事扱い表示なので、手作業は現実的ではありません。
左上に『行数』があるので『500』にします。更に『Ctrl + F』で、500件ずつソートします。注意点として、ソートしたら上下ボタンで更新しないとスルーされてしまいます。
復元記事の数による対応
パーマリンク設定が『基本』や『数字ベース』を使用しているのであれば、そのまま使えますが『カスタム構造』の場合はURLが分かりません。おそらく対処方法はあると思いますが、今回は数件だった為、ツイッターやグーグル検索で、オンライン上に残るデータを拾いました。
もしも、大量に削除してしまったのであれば、バックアップ後の新しい更新を保存して、ワードプレス自体を復元した後、新しい更新をプラスした方が早いかも知れません。もしくは、サイト直下の付属ドメインへミラーリング的な復元をし、そこから抜いた方が効率的です。
記事データの回収
記事データに入ると、HTMLがありました。
- 記事ID
- 記事HTML
- 記事タイトル
投稿日時については『post_date』を参考にします。
『post_date』・・・日本標準時
『post_date_gmt』・・・グリニッジ標準時
グリニッジ天文台はイギリスなので、日本との時差は9時間です。
うっかりミスのおかげで、色々勉強させてもらいましたが、本来は知らなくていい情報かも知れません。
とにかく、削除は慎重に・・・。
はい、以後気を付けます。