シングルインストールのWordPressをマルチサイトの子サイトとしてインポート/マイグレーションする。

WordPress のシングルインストール(普通にインストールしてあったサイト)のコンテンツから何からをまとめてマルチサイトの子サイトとしてマイグレーションする方法。

普通のWordPressの移行の方法とほとんど同じで差があるところは、

  1. url が変わる
  2. uploads/ ディレクトリのパスが変わる( uploads/sites/site_id )になる
  3. users と usermeta がマルチサイトの親サイトに統合される

の3点です。

今回は、3点目は手動でなんとかすることにして、1, 2 をぱぱっとやる手順についてまとめます。example.jp というサイトを example.com/ja に移行するとすると以下のようになります。

  1. マルチサイトを用意して、子サイトを作る
  2. 子サイトのIDを把握する。以下、サイトIDは2だったとして進めます
  3. シングル側でDBをダンプする(wp_users, wp_usermeta はしない)
  4. ダンプしたDBに対して、以下の置換を行う
    1. example.jp -> example.com/ja
    2. /wp-content/uploads/ -> /wp-content/uploads/sites/2/
    3. `wp_ -> `wp_2_ (バックティックを含めると事故が少ない)
  5. themes/, plugins/ ディレクトリを移す
  6. uploads ディレクトリを wp-content/uploads/sites/2/ に移す
  7. マルチサイト側にインポートする

これでできます。作業中なので他にも何かあったら更新していきたいと思います。

コマンドで置換する

sed コマンドを使います。

cat ./prod-single-sub.sql \
 | sed -e 's/https:\/\/example.jp/http:\/\/example.com\/ja/g' \
 | sed -e 's/http:\/\/example.jp/http:\/\/example.com\/ja/g' \
 | sed -e 's/example.jp/example.com\/ja/g' \
 | sed -e 's/`wp_/`wp_2_/g' \
 | sed -e 's/\/wp-content\/uploads\//\/wp-content\/uploads\/sites\/2\//g' \
 > ./dev-multi-sub.sql

wp-cli で、特定のテーブルのみをエクスポートする

3の wp_users, wp_usermeta を排除するには、次のようにするとよいです。

wp db export prod-single-sub.sql --tables=wp_commentmeta,wp_comments,wp_links,wp_options,wp_postmeta,wp_posts,wp_term_relationships,wp_term_taxonomy,wp_termmeta,wp_terms

--tablesでどのテーブルを対象にするのかが決められるのですね。

↓ プラグインを作る方々への本、書きました。 ↓

AMPとかInstant Articlesってメディアやブログにとっては結構でかい意味があると思う。

AMP とか Instant Articles って何?それはメディアやウェブサイトを持つ人にどういう意味を持つの?WordPress とこれらの関係は?

最近のことですが、AMP や Instant Articles がちょっと話題になっていますね。

これって、技術的なことよりも、SEOがどうしたということよりも、こういうものが出てきたことは偶然ではなくて、今後のコンテンツパブリッシングの仕方が変わる兆しであって、必然なんじゃないかと思います。

ということで、AMP とか Instant Articles って何か?それがメディアやブロガーやウェブサイトを持つ人にどういう意味を持つのか、WordPress とこれらの関係は?ということについて、ちょっと書いてみました。

AMP とか Instant Articles って何?

そもそも、これってなんなのでしょうか、というところを簡単におさらいします。

AMP とは

まず AMP の字面は、Accelerated Mobile Pages の略で、「高速化されたモバイルページ」の意味ということでよいと思います。

Google とTwitter が立ち上げたオープンソースのプロジェクトだそうです。

ちゃんと見てないのでものすごくザックリですが、具体的には form や iframe などの表示に時間がかかったりブラウザに依存したりするものを排除した、簡易型の HTML を作っておいてください、と。

スタイルシートについても、リンクではなくて<head />内に書いてくださいね、と。HTML について以外にも、AMP JS や AMP CDN などスクリプトや CDN についての規格を決めているようです。詳しくは、amphtml/amp-html-format.md at master · ampproject/amphtml で仕様が読めます。

WordPress のサイトであれば、AMP — WordPress Plugins をインストールして対応することが可能です(が、まだいろいろと調整中のようなので、待つのがいいと思います)。

このサイトでも個別記事のURL の末尾に /amp を追加すると一応 AMP HTML が出力されます。

Instant Articles とは

Instant Articles は日本語では、インスタント記事というそうです。

インスタント記事をすべてのメディア媒体社へ4月より提供開始を発表

こちらは Facebook が作った仕様にのっとって、RSS のような専用 Feed を作ってね、ということのようです。

こちらについてもWordPress のプラグインの開発が進んでいるようで、 Automattic/facebook-instant-articles-wp で確認、インストールなどができます。このサイトでも有効化してみまして、ここをクリックすると、Feed 自体はどんなものなの?というのを確認できます。簡易版RSSみたいなイメージですかね。

AMP や Instant Articles を導入するとどうなるのか。

AMP ではスマートフォンで Google 検索をした際にプリロード(記事コンテンツの先読み)が発生して 、ユーザーがクリックするとコンテンツが即時表示(超速い)されます。また、Twitter ではどうなるのか、まだ確認できていませんが、多分、アプリなどでツイートの中にあるリンクをクリックしたら、サイトに飛ぶのではなくてプリロードされた AMP バージョンがアプリ内で表示されるだとか、Twitter Card の代替のようなことになるのではないかと思われます。

Google 検索で言うと、今までは、

  1. ユーザーが検索する
  2. 検索結果が表示される(タイトルとかディスクリプションとか)
  3. ユーザーがリンクをクリックする
  4. ユーザーは遷移する

という流れだったのが、今後は、

  1. ユーザーが検索する
  2. 検索結果が表示される(でかいサムネイルとかが出てる)
  3. AMP HTML が先読みされてブラウザでダウンロードされる(クリックする前に終わってる。軽いからできちゃう)
  4. ユーザーがリンク(これはリンクと呼べるのだろうか?)をクリックする
  5. ユーザーはすでにブラウザの中にあるコンテンツに飛ばされる
  6. なんなら、となりにあった検索結果にスワイプで移動できちゃったりする

という流れに変わります。

Instant Articles でも似たような感じで、今までは

  • タイムライン、フィードに流れてきたリンクをクリックしたら遷移してた

のが、

  • Facebook アプリの中に先読みされている記事がその場で表示されるだけ

みたいになる、ということのようです。動きはここの動画で見れます

検索や SNS とメディアの関係が逆転する?

さて、前置きが長くなりましたが、AMP や Instant Articles の概要を把握したところで、だからなんなの?というところについて。

要するに、サイト(メディア・ブログ・サイト)を持つということは各種プラットフォームへのパブリッシングセンターを整備することになりますよ、ということだと思います。

たとえば、メディアサイト。ニュースサイトでもアフィリエイトブログでもオウンドメディアでもなんでもいいんですけど、これまでの基本的な流れというのは、

  1. ウェブサイトを作る
  2. 広告を貼り付けたりお問い合わせフォームを作るだとかアプリのダウンロードリンクなどを設置しておく
  3. SEO 対策だとかバズるタイトルづくりだとかをする
  4. 検索やソーシャル経由でユーザーがやってくるのを待つ
  5. コンバージョンする

ということだったと思いますが、これがうまくいかなくなるんじゃないか、という気がします。今までよりもシンプルにそうはならないというか。

AMP も Instant Articles も、口を悪くしていうと、

こっちのプラットフォームにコンテンツを出しなさいよ、ユーザーは Facebook や Twitter のタイムライン/アプリ、Googleの検索結果からあんまり動きたくないんだから、そっちのほうがいいよね(ユーザーにとっては)オラオラ、こっちのプラットフォーム上でやっておくから、コンテンツだけ(文字だけ)送ってよ、そっちへのトラフィックはあげないけど。

という話なんですよね。

もちろん、AMP のフォーマットの中で広告や外部リンク(関連記事とか)を入れることはできますし、 Instant Articles でも広告が表示されて FB とコンテンツ供給者が広告(規格決まってるっぽい)で上がったお金を山分けというようなことはあるようですけど、メディア側に人が来ないです。

回遊性を高めよう!とか、Facebook の Like をしてもらおう!とか、RSS登録(古いかな・・)してもらおう!とか、今までよりも難しくなります。

この記事では AMP と Instant Articles の話に絞っていますが、Smart News への配信規格とか、Yahoo! News への配信規格とか、まあこれまでもありましたし、これからももっといろんな規格が出てくるのかもしれませんね。

数年単位の話で言えば、モバイルサイト、モバイルアプリだけではなくて、時計やらメガネやら何らかの空中でふわふわしているようなディスプレイやら脳に直送やら、なんでもいいのですけど、そういう各種メディアやデバイス(脳はデバイスじゃないけど)に対して適切な形でコンテンツを送り込むセンターとしてのウェブサイトを持とう、という話に移行していくのかもしれませんね。

この話は、昨年の WordCamp Tokyo 2015Human Made の哲学者 Noel Tock さんがしていた、 “Content Publishing in 2016” というセッションがズバリ言い当てていると思います。

このセッションでは、Instagram における National Geographic 社の取り組みなどを事例に、各プラットフォームで活躍して存在感を示すようなやり方に、パブリッシングの本質が移行していくんじゃないか、という話をしています。

(Noel Tock さんの予言に興味がある人は 2016 年の WordPress — Medium という僕の訳した記事もあるのでこちらも是非どうぞ。)

WordPress どうなる

さて、僕は WordPress が好きで、収入の大部分をこのオープンソース・ソフトウェアに依存しているわけですが、こうしたプラットフォームやデバイスなどにコンテンツを配信するようになる、という流れと、WordPress を使ってブログを書いたりメディアを運営したりすることの関係がどうなるのかについて整理したいです。

結論から言いますと、WordPress 使っててよかったー、という話になるのではないかと思います。WordPress はそもそも Publishing Tool であり、今はたまたまHTML 製造機としての WordPress が前面に押し出されていますが、コンテンツをパブリッシュする(世界に向けて、言いたいことを言う)ということで言えば、別に HTMLじゃなくてもよくて、HTML のサブセットでもちょっと変わったXMLでも json でもなんでもいいわけですね。

WordPress でよかったね、というふうに思うのは、これから、メガネ用の規格、脳みそに直接送信するための規格、スマートウォッチ用の規格、スマートカーで読み上げやすいようにするための規格とかがバンバン出てきたとき(もしかしたらひとつに統合されるのかもだけど)、いちいち対応するのは面倒だけど、プラグインを入れたらそれでいいじゃないか、という話になるのは気が楽です。別に WordPress じゃなくてもいいけど、現状を見ると対応が早いのは WordPress ですよね。

作家でプラグイン作者で破滅派社長の高橋文樹さんの WordCamp Tokyo 2015 でのセッションも同様の話だったかと思います。

キラキラした何か。
「キラキラしたナニか」を通してマルチプラットフォーム・パブリッシング!

WP API どうなる

WordPress のコア機能(プラグインじゃなくて本体の機能)として、今ホットな話題といえば WP JSON REST API なのですが、これも似たような文脈で理解することができます。

WP JSON REST API とはなんなのかというと、WordPress のデータを json で restful に配信できるようになって、コンテンツやデータを色んな所から引っ張ってきたり(サイトに来なくても)、アプリやサービスなどから追加/変更/削除できるようになったりする、という話です(ザックリですみません)。

なので、コンテンツを入れておく場所はWordPressであって、HTMLも表示できるけど json で各種プログラムと仲良く話をすることもできる、というようになる。ということはいろんなデバイスに対してコンテンツをオープンにすることができるようになるわけですね。

今は HTML のサブセットやらちょっと変わったXML を出力するためにプラグインを入れているわけですが、今後は json で配信しておくから各プラットフォームさんは勝手に持って行ってくださいな、ということになるかもしれません。

そう思うと、何が何でもこっちのサイトに人を引っ張ってきてコンバージョンしたい、というのはかなり無理筋になってきて、コンテンツを適した形で読めるように配信する、コンテンツで魅了する、作者やメディアのブランドがちゃんと伝わるようにする、そしてマネタイズは後から考える(←)、という姿勢で取り組まないといけなくなっていくのではないでしょうか。

大変ですね!

↓ プラグインを作る方々への本、書きました。 ↓

WP REST API の OAuth 認証の方法と何が起こっているのかとなぜそんなことをしているのか

ウェブアプリ、スマホアプリなどの外部のアプリケーションから WP REST API を利用して WordPress のデータを更新などするために必要になる OAuth 認証の方法について。何が起こっているのか、なぜそんなことをしているのかを丁寧に調べてみたレポートです。

OAuth認証やってまいります。

WP REST API の OAuth 認証用のプラグインの github レポジトリのドキュメントのフローの通り進めます。また、リクエストの送信には、Paw という Mac アプリを利用します。

この記事自体の中に上記のドキュメントで伝えられていることを逐次翻訳して残しておこうと思います。上記のドキュメントは読まなくても大丈夫になるように頑張ります。間違いがあったら、 @shinichiN へお願いします。

STEP 0: Client Key と Client Secret を作成する

ドキュメントサイトの方には「OAuth のプラグインにUIはありません。そのうち作ります」などと書かれておりましたが、実際にはありました。

WP REST API の OAuth プラグインのアプリケーション作成画面
WP REST API の OAuth プラグインが提供するアプリケーション作成画面

wp-cli を利用して $ wp oauth1 add みたいなことをしないといけない、とドキュメントサイトにはありますが、管理画面でできました。

というわけでさっそく作っていきましょう。

コンシューマを作ってみました。
コンシューマを作ってみました。

NameDescription は管理用のものだと思われますので適当に入れます。Callback URL はよく分からないですが必須なので /success としました。

Client Key と Client Secret をメモしておきましょう。

OAuth フローの概要と、その意義

OAuth1/Auth-Flow.md at master · WP-API/OAuth1 にある OAuth 認証のフローを翻訳します。クライアント側から見ると、3つのフローに分かれています。

“WP REST API の OAuth 認証の方法と何が起こっているのかとなぜそんなことをしているのか”の続きを読む

↓ プラグインを作る方々への本、書きました。 ↓

習うより慣れろ。WP API にリクエストをいっぱい投げる。& REST クライアント “Paw” が超便利。

WP REST API サイトの主要なページをじっくり読んだところで、次は習うより慣れろということで、リクエストいっぱいしてみて、レスポンスをじっくり見てみよう、という趣向で進めてみたいと思います。

前提として、以下の記事を読んでおくと、話がよく分かると思います。

また作業にあたり、Mさんこと @miya0001 さんから Paw – The ultimate REST client for Mac という、REST クライアントを紹介してもらいましたので使ってみました。

スクリーンショット 2016-01-03 10.34.36

Paw is a full-featured and beautifully designed Mac app that makes interaction with REST services delightful. Whether you are an API maker or consumer, Paw helps you build HTTP requests, inspect the server’s response and even generate client code.

Paw は機能フル装備の美しい Mac 用アプリで、REST サービスとのインタラクションを快適にします。API を開発するひとにとっても、使う人にとっても、HTTP リクエストをビルドしたり、サーバからのレスポンスを詳しく見てみたり、さらにはクライアントコードを生成してみたりするのに便利です。

いやー、実を言いますと httpie はとっても手軽なんですけど長い json がどわーっと来ると目的の key を探したりするのが不便で困っていたんです。手元でパッとテストするにはとてもいいのですが、使い分けですね。

ということで、

  • エンドポイントやリクエスト内容を整理して保存
  • レスポンスを綺麗に見る
  • 自分が何をやっているのか見て分かるようになる

ということのためによさそうです。まずは30日間の Trial ができるということです。

インストールするとこんな感じで、

Paw の初期画面
Paw の初期画面
  • アクションを選び、
  • URL を入れて
  • パラメータを指定する

ための画面が出てきました。とりあえず、

というのをやってみます。

Paw では認証関連もサポートしているようなので、次回以降は以下の作業もやってみます。

  • 認証をしてみる(参考: WP REST API のドキュメントの認証ページの翻訳)
    • まず Basic 認証を
    • 次に OAuth 認証を

“習うより慣れろ。WP API にリクエストをいっぱい投げる。& REST クライアント “Paw” が超便利。”の続きを読む

↓ プラグインを作る方々への本、書きました。 ↓

WP REST API ドキュメント Discovery

Discovery | WP REST API v2 Documentation の翻訳です。

Discovery 発見/探索

未知のサイトにアクセスする際、そのサイトでは何が可能でどのように設定されているのかを知る必要があります。何を知りたいのかによりますが、幾つかのステップで探索することができます。

“WP REST API ドキュメント Discovery”の続きを読む

↓ プラグインを作る方々への本、書きました。 ↓