2017年 – シングスブログ

WordPress本体をより安全に自動更新できるWordPressプラグイン「WP Auto Updater」をリリースしました

公開日: 2017年9月29日 15:20 更新日: 2019年11月25日 22:16 投稿者: thingsym

WordPressプラグイン「WP Auto Updater」の生まれた背景とかも書いてみたので、めっちゃくちゃ長い文章になっています。
なので、WordPressプラグイン「WP Auto Updater」をサクッと知りたい方は、読み飛ばしてこちらから読んでください。
全文は暇なときに読んでもらえればと思います。

2017年2月に情報公開された WordPress 4.7.0, WordPress 4.7.1の脆弱性

2016年12月6日にリリースされたバージョン 4.7 には、容易に攻撃できる脆弱性が入り込みました。

原因元は WordPress 4.7　から追加された機能 REST API。結果、外部から REST API の脆弱性を利用して WordPress のコンテンツが改ざん被害が確認されました。WordPress の新機能はまずプラグインとして開発されます。機能として完成した段階で WordPress本体に取り込まれます。その過程で脆弱性が入り込み、典型的なメジャーバージョン特性を表すように発見されたわけです。

WordPressは、常に最新版にするべきか

WordPressサイトを運営する側として対応することはあるだろうか?

基本的なスタンスとして、脆弱性を悪用されて被害にあったからアウト。会わなかったからセーフではなく、
被害に関わらず致命的な脆弱性があるコードを晒した時点でアウト。
そういう状況に置くこと自体がアウトというスタンス。
そこを考えて WordPress をアップデートしていくことが必要になってきています。

WordPressは、管理画面を経由してボタンをクリックするだけで簡単にアップデート更新できます。WordPressに詳しくなくても、スキルがなくても、何も考えなくてもできます。便利さの反面、そこに盲点が生まれます。

致命的なことが起こった後に火消し的に対応するのではなく、100%は無理でも、避けられるものは避ける。
自動更新が機能していないから被害が広がるとか聞かれますが、関係ありません。

一番大切なことは、手動、自動かかわらず普段からアップデート方針を持っていること。
その上でサイトを運営することです。

WordPressの管理画面には、メジャーアップデート、マイナーアップデートの区別なく常に最新版に促すメッセージが流れます。スマホアプリのようにバッチで通知されます。
もちろん WordPress はスマホアプリではなく、ウェブアプリです。
さらに WordPress はオープンソースで誰でも使える。
いろんな人がいろんな目的で利用し、ウェブサイトやブログを運営しています。

WordPressのセキュリティに関してのブログ記事を目にすることもあるかと思います。
そこに最新版にするとよく書かれていますが、
メジャーアップデート、マイナーアップデートのどちらを指しているかわかりません。

はたして常に最新版にすることが安全と言えるのでしょうか。

現場でやっている WordPressアップデートの基本的な考え

実際、WordPressサイトを運営したり、
クライアントのウェブサイトの運営をお手伝いしていますが、
常に最新版にしていることはありません。

マイナーアップデートは自動でまたは手動でこまめに適用していますが、
メジャーバージョンがリリースされてもすぐにはアップデートしません。
最新のメジャーバージョンで追加された新機能をつかいたいなど特段の理由がない限り、
ある程度時間をおいてから行います。
前出のメジャーバージョン特性があるからです。

また、メジャーアップデートを止めることもしません。
必ずどこかの段階でメジャーアップデートを行います。
目安としては最新のバージョンとのバージョンナンバーが大きく離れないこと。
アップデートを止めていたり、アップデートはしていてもバージョンナンバーが大きく離れると、
検証作業が別途必要になってきます。

ということで、検証作業を行う必要がない範囲で
メジャーバージョンのアップデートをする前提で
WordPressサイトを運営しています。

これもすべて普段からアップデート方針を持っているからです。

より安全なWordPressの自動更新を目指して

上記のアップデート方針を取ろうとしてもなかなかできないのも事実です。
まず手動ですることが前提になります。
いちいち管理画面でアップデート更新するしかありません。

それも一定のスケジュールをもって行う必要があります。
どこかで忘れたり、面倒くさがってアップデートを怠ります。
場合によっては、ブログを更新するときについでにアップデートする。
けどそれは、ブログを書かなくなるとアップデートが止まることを意味します。

やはりここは自動更新でと思っても。

メジャーバージョンの自動更新を有効にしても、
リリースされるとすぐに最新版の WordPress が適用されてアップデートします。
基本的な考えに沿った形になりません。

自動更新で実現するには、「どのようにして自動更新を行うのか」
「いつメジャーアップデートをするのか」という問いに答えなければなりません。

WordPressのバージョンを固定してコントロールという発想を実装

幸い WordPress のバージョンナンバリングは、セマンティックバージョニングのように体系化がきっちりなされています。
バージョンナンバリングをうまく活用すれば、WordPress本体の更新がコントロールできるのではないかと、早速ソースコードを読み進めました。
また、WordPressの裏側には API があります。この API は、インストールされた WordPress本体と現在の最新版とのバージョンの比較をしています。WordPressの最新版やマイナーバージョンがリリースされたらアップデートを通知する仕組みでもあります。

WordPressの自動更新でメジャーバージョンのアップデートを有効にすると、常に最新のバージョンにアップデートします。
これをあるときには最新のバージョンにアップデートさせない、ある条件を満たせば、メジャーアップデートさせる。バージョンナンバリングと API を組み合わせて、バージョンを固定したり、アップデートそのものをコントロールする。というところに行き着きました。

メジャーアップデートでいかに安全な方向に倒すか、フェイルセーフ 2 つの方向性「Minor Only Version Update」「Previous Generation Version Update」

それによって可能になることは、メジャーアップデートをするけれど、より安全にできること。
メジャーバージョン特性をなくせれば、メジャーアップデートもより安全になります。
メジャーバージョン特性を無くすことの基本的な原理は単純で、メジャーバージョンのリリース直前のメジャーアップデートを辞めるに尽きます。

ではいつメジャーアップデートすればいいのか。方向性は 2つあります。

一つ目は、メジャーバージョンのリリース直前のアップデートではなく、マイナーバージョンがリリースされた段階でメジャーアップデートする「Minor Only Version Update」。これはある程度メジャーバージョンが使われて、あらかた不具合も発見されている可能性は高まった段階でメジャーアップデートをおこなう。以降はマイナーアップデートをきちっと適用してくれます。

もう一つは、最新のバージョンを使わない。ひとつバージョンを遅らせて使う「Previous Generation Version Update」。
常に前バージョンを使えば、極めて安全な運営が実現できます。
最新のメジャーバージョンがリリースされると、一つ前のバージョンにメジャーアップデートする。
この場合、大体においてマイナーアップデートが入ったバージョンで行ってくれると思います。

おまけにもう一つ可能になることが出てきました。
自動更新を常に安全な方向に持って行けば、
WordPress本体の更新は、今まで手動だったのを、これからは自動で行うことを前提として運営できる。
テーマ、プラグインも最新バージョンに対応して出揃った段階で WordPress本体をアップデートできる。

また管理面の負担が減ります。
手動で WordPressの管理画面に入って更新する、またはコマンドで操作する必要がなくなりました。
最新版を使いたいときだけ、手動でメジャーアップデートする。
でも基本的な方向性は安全な方向を保ったまま。といった運営が実現します。

そして、WordPressプラグイン「WP Auto Updater」が生まれました。

長くなりましたが、ようやく本題です。

WordPressプラグイン「WP Auto Updater」は、WordPressの本体 (コア)、テーマ、プラグイン、翻訳を自動更新するプラグインです。WordPress本体のバージョンをコントロールしてより安全に自動更新ができるようになります。

主な機能は、

WordPress 本体 (コア) の自動更新
テーマ、プラグイン、翻訳の自動更新
自動更新スケジュールの設定
個々のテーマ、プラグインの自動更新を無効化する機能
自動更新の履歴を記録 (ログ)

以上を管理画面で設定できます。

まずは、

WordPressの自動更新をする前に、重要なことがあります。
それは、バックアップをきちっと取ること。
WordPressの更新はファイルの変更が伴うため、バックアップ系プラグインを導入など必ずバックアップ体制を作ってください。

WordPressプラグイン「WP Auto Updater」をインストールして有効化すると、管理画面が用意してあります。

自動更新シナリオ (Auto Update Scenario) を作る

WordPressプラグイン「WP Auto Updater」の管理画面で、
自動更新シナリオ (Auto Update Scenario) を作って WordPressの自動更新の方針を決めます。

WordPress 本体の自動アップデートは、以下の 5 つから選択できます。

マイナーバージョンをアップデート (推奨) / Minor Version Update (Recommended)
メジャーバージョンをアップデート / Major Version Update
マイナーバージョンだけをアップデート / Minor Only Version Update
一世代前のバージョンをアップデート / Previous Generation Version Update
手動でアップデート / Manual Update

マイナーバージョンをアップデート (推奨) / Minor Version Update (Recommended)

マイナーバージョンをアップデート (推奨) は、マイナーアップデートを有効化します。
マイナーアップデートは、セキュリティのための WordPress のデフォルトの機能です。
バージョンナンバーの動きから観ると、4.8 から 4.8.1, 4.8.2… とマイナーバージョンがリリースされる度に自動更新されます。メジャーバージョンである 4.9 に自動更新はしません。
WordPressプラグイン「WP Auto Updater」では、マイナーアップデートをできるだけ有効な状態を保つようにしています。

メジャーバージョンをアップデート / Major Version Update

メジャーバージョンをアップデート はメジャーアップデートを有効化します。
WordPressのデフォルトでは、無効になっています。
バージョンナンバーの動きから観ると、4.7 から 4.8, 4.9 とメジャーバージョンがリリースされる度に自動更新されます。

マイナーバージョンだけをアップデート / Minor Only Version Update

マイナーバージョンだけをアップデート は、バージョン x.y.0 のメジャーバージョンを除くメジャーアップデートとマイナーアップデートを有効化します。

この自動更新は、セキュリティの修正が入ったバージョン x.y.1 以降の WordPress がリリースされた段階でメジャーアップデートを実施します。メジャーバージョンであるバージョン x.y.0 or x.y ではメジャーアップデートをしません。
バージョンナンバーの動きから観ると、4.7.z から 4.8.z, 4.9.z とメジャーバージョンとマイナーバージョンがリリースされる度に自動更新されます。つまり 4.7.0, 4.8.0, 4.9.0 のメジャーバージョンをスキップします。

一世代前のバージョンをアップデート / Previous Generation Version Update

一世代前のバージョンをアップデート は、最新メジャーバージョンの WordPress を除くメジャーアップデートとマイナーアップデートを有効化します。

この自動更新は、WordPress 4.6.z をインストールしているとすると。最新メジャーバージョンの WordPress 4.8.0 がリリースされるときには、メジャーバージョン 4.7.z にメジャーアップデート。
常に最新バージョンの一つ前のバージョンにメジャーアップデートします。その場合、大体においてセキュリティの修正が入ったバージョンがアップデート対象になると思います。

手動でアップデート / Manual Update

メジャーアップデートとマイナーアップデートの自動更新を無効化します。
WordPressの管理画面から手動でアップデート更新します。

テーマ、プラグイン、翻訳の自動アップデートは、

自動更新 / Auto Update
手動更新 / Manual Update

が選べます。

またテーマ、プラグインは、個々に自動アップデートの無効化ができます。
ちょっと信頼できないテーマ、プラグインは一時的に自動更新を止めて様子を見たり、
検証環境で確認してから手動でアップデートの手順を取るなど
安全に更新ができる体制が作れると思います。

自動更新のスケジュールを設定

次に自動更新のスケジュールを設定します。

更新間隔は、以下から選べます。

1日2回 (12時間間隔) / Twice Daily (12 hours interval)
毎日 / Daily
毎週 / Weekly
毎月 / Monthly

デフォルトでは、自動アップデートがいつ動くか時間を指定できないですが、
WordPressプラグイン「WP Auto Updater」では、自動アップデートを動かす日時も指定できます。

訪問者の少ない深夜帯に自動更新をしたり、
都合のいい日時時間に自動更新することも可能になります。

自動更新

自動更新のスケジュール間隔で自動更新のチェックが入ります。
アップデートできる WordPressの本体 (コア)、テーマ、プラグイン、翻訳があれば、自動的にアップデートしてくれます。
アップデートしたWordPressの本体、テーマ、プラグイン、翻訳は、アップデート履歴に記録されます。

以上が WordPressプラグイン「WP Auto Updater」での自動更新の設定と自動更新が行われるまでの流れです。

WordPressを自動更新で運営してみたい方は、WordPressプラグイン「WP Auto Updater」を是非使ってみてください。
「WordPress を活用する人を幸せする運営はあるのだろうか」に少しでも応えられたら幸いです。

Nav Menu メニュー項目の id/class 属性を整えるWordPressプラグイン「Nav Menu Trim」を作りました

公開日: 2017年8月2日 17:12 更新日: 2019年11月25日 22:17 投稿者: thingsym

WordPress が生成する Nav Menu のメニュー項目には、id 属性や class 属性にたくさんの値が追加されます。

実際 WordPress テーマの設計やスタイルシートで使うのは、
現在の表示しているページかどうかの class 属性値 current-menu-item だったり、
ドロップダウンメニューを作るために、または矢印アイコンをつけたりするためにサブメニューがあるかどうかの class 属性値 menu-item-has-children の 2 つだけあれば良かったりします。

WordPressプラグイン「Nav Menu Trim」は、Nav Menu のメニュー項目の id/class 属性を必要なものだけに整えてくれるプラグインです。
ユーティリティな感じで作ってみました。

使い方は簡単。

インストールして有効化すると。WordPress のカスタマイザー「Menus」の下のほうに
メニュー「Nav Menu Trim」が追加されます。
そこで取り除きたい項目をチェックするだけ。

外観 > カスタマイズ > メニュー
(Appearance > Customize > Menus)

id 属性値と class 属性値すべてを取り除きたかったらすべて選択。
ドロップダウンメニューを作ったり、メニューにアイコンを付けたかったら上 3つだけ選択。

またメニュー項目を作るときにつけられるオプション CSSクラスで独自の属性値がつけられるので、class 属性を独自の値だけにしたいときにも役に立つと思います。

WordPress テーマ設計で HTMLやCSS　にこだわりを持つ方にどうぞ。

WordPressをサーバH2Oで動かす (WordPressアプリケーションサーバとしてのH2O)

公開日: 2017年3月24日 14:28 更新日: 2019年11月27日 14:36 投稿者: thingsym

常時SSL とプロトコル HTTP/2 に対応するため、サーバ環境を新しくしてウェブサイトを移行しました。
新しい試みとしてサーバ構成を CentOS7 + PHP7 + MariaDB + H2O + WordPress にしてみました。

次世代の HTTPサーバ H2O を中心に速い WordPress を目指してサーバを構築。

今回 WordPress を HTTPサーバ H2O でどのように動かせばいいのか見てみたいと思います。

HTTPサーバ H2O とは

H2O は、プロトコル HTTP/2 に最適化されたウェブサーバです。

ここ数年でセキュリティ面で SSL が必須になりつつあり、ネット環境も新しい通信規約 (プロトコル) が求められている時代に最適なウェブサーバのひとつになっていくのだろうと注目していました。

H2O の開発は、2014年から元DNAの @kazuho さんが中心にオープンソースとして進められています。Perl を使っている方はウェブアプリを作るときに Server::Starter でお世話になっているのでは。ボクもいつもお世話になっています。
Server::Starter は、H2O のバックグラウンドにも使われていて start_server が動いているのが見て取れます。こういうところにも使われているのかとほんと感心しますね。

HTTP/2 時代を見据えているだけあってサーバの性能もベンチマークを見るとレスポンスが Apache や Nginx より速い。
他にも H2O の技術要素に注目したいものがたくさんあるのですが、詳しく知りたい方は、公式サイトやスライドも上がっているのでそちらを見ていただければと思います。

WordPress をサーバ H2O で動かす

2015年6月に FastCGI機能を実装したバージョン 1.3.0 がリリースされて、PHP が動くようになりました。
サーバ H2O で WordPress を動かすには、2 つの方法があります。

ひとつめは、WordPress を PHP-FPM や HHVM で管理。Nginx で従来やっている馴染みのあるやり方をそのまま踏襲。H2O も fastcgi.connect でホストに繋げてレスポンスを返してくれる。

今回採用したもう一個の方は、H2O 自体で管理する方法。
fastcgi.spawn で起動してH2Oの下で PHP のプロセスを管理してくれます。
PHP-FPM や HHVM をインストールしてコンフィグの設定起動、運用の手間がなくなります。

今回の試みとして思っていたことで、
WordPress とかPHPアプリを動かすアプリケーションサーバとしてH2Oは、最適なんじゃないかなぁと。

実際 H2O の下に php-cgi が動いているのが見て取れます。

WordPress を動かすサーバ設定 (/etc/h2o/h2o.conf) もYAML書式でシンプルに書けます。

以下これだけでWordPressが動きます。

paths:
  "/":
    file.dir: /path/to/wordpress
    redirect:
      url: /index.php/
      internal: YES
      status: 307
    file.custom-handler:
      extension: .php
      fastcgi.spawn: "PHP_FCGI_CHILDREN=10 exec /usr/bin/php-cgi"

実にシンプル。YAMLでわかりやすいのがいいですね。(本番運用には、自動更新やダッシュボードへのアクセスのところでもう少し手を入れる必要があるのですが。)

で今回の試したサーバ設定は、

常時SSL
www にURL正規化
http から https にリダイレクト
WordPress ツールバーからダッシュボード (www.example.com/wp-admin/) へアクセス
WordPressの自動更新ができるように
FastCGI のスループットチューニング
他もろもろ

で以下のような本番運用サーバ設定 (/etc/h2o/h2o.conf) になりました。

user: nobody
 
listen:
  port: 80
listen:
  port: 443
  ssl:
    certificate-file: /path/to/fullchain.pem
    key-file: /path/to/privkey.pem
 
hosts:
  "localhost":
    paths:
      "/":
      redirect:
        status: 301
        url: https://www.example.com/
 
  "www.example.com:80":
    paths:
    "/":
      redirect: https://www.example.com/
  "www.example.com:443":
    paths:
      "/":
        file.dir: /var/www/wordpress
        redirect:
          url: /index.php/
          internal: YES
          status: 307
 
file.index: [ 'index.php', 'index.html' ]
 
file.custom-handler:
  extension: .php
  fastcgi.spawn:
    command: "PHP_FCGI_CHILDREN=10 exec /usr/bin/php-cgi"
    user: example
  fastcgi.timeout.keepalive: 10000
 
access-log: "| exec sudo rotatelogs /var/log/h2o/access.log.%Y%m%d 86400"
error-log:  "| exec sudo rotatelogs /var/log/h2o/error.log.%Y%m%d 86400"
 
pid-file: /var/run/h2o/h2o.pid
http1-upgrade-to-http2: ON
http2-reprioritize-blocking-assets: ON

WordPressを動かすH2Oサーバ設定のポイント

WordPress ツールバーからダッシュボード (www.example.com/wp-admin/) へアクセス

通常の設定では、WordPress ツールバーからダッシュボード (www.example.com/wp-admin/) へアクセスは、トップページを返してしまいます。

ダッシュボードにアクセスできるように file.index で index.php を追加して www.example.com/wp-admin/ で　www.example.com/wp-admin/index.php にアクセスするようにしました。

WordPressの自動更新ができるように

H2O はデフォルトで nobody の下で動きます。
H2Oの管理下にある PHP も nobody で動きます。
WordPressの自動更新は、WordPressのファイル所有者の下でPHPが動かないと自動更新が働きません。
fastcgi.spawn には、どのユーザ user で動かすか指定できるので、WordPressのファイル所有者を指定して動かします。

FastCGI のスループットチューニング

fastcgi.spawn での PHP への接続は、デフォルトでは1回限りの接続です。これだとWordPressが動くたびにコネクションが発生します。
fastcgi.timeout.keepalive で Keep-Aliveを 10 秒に指定。一定時間 FastCGI の接続を継続させてスループットを改善してみました。

まだまだキャッシュ周りやいろいろチューニングができそうなので、運営しつつ試してみたいと思います。

参考サイト

ブログを Movable Type から WordPress に移行

公開日: 2017年1月16日 12:55 更新日: 2019年11月25日 22:19 投稿者: thingsym

Movable Type から WordPress に移行したときの備忘録です。

このブログは、PSGI Plack 環境の Movable Type で運営してきました。
今回 WordPress の移行をどこまでできるか、開発環境でいろいろ試してみました。移行前に考えたのは...

コンテンツマネジメントシステム (CMS) は同じでサーバ間の移行は経験があるけど、CMS 間の違いの移行はやったことがない。
Movable Type はバージョン 5
CMS 間で形式が違うデータをどうやって WordPress に移行するのか。
どの程度コンテンツデータに手を入れる必要があるのか。
パーマネントリンクの URL は、すでに登録されている検索インデックスに影響を与えないようできるだけ維持したい。

まずは、データの移行

Movable Type のブログデータのエクスポート。
「ツール > 記事のエクスポート」からエクスポートしてテキスト形式のファイル (export-xxx.txt) をダウンロードします。

開発環境に構築していた WordPress にそのエクスポートファイルをインポートします。
「ツール > インポート」にある Movable Type と TypePad で「今すぐインストール」をクリックするとインポーターがインストールされます。インストールが完了して「インポーターの実行」をクリックすると、インポーター画面に移動。
実際は裏でプラグイン「Movable Type・TypePad インポートツール」をインストールして有効化されています。
移行が済んだら無効化しましょう。

インポーター画面では、
エクスポートファイルを選択する方法と、
エクスポートファイルを mt-export.txt に変えて /wp-content/ ディレクトリに直接アップロードする方法の
2 つのやり方があります。

今回は、エクスポートファイルのデータサイズが大きくないので、ファイルを選択する方で。

ダウンロードしたエクスポートファイルを選択して「ファイルをアップロードしてインポート」ボタンを押すと、
新しくユーザを作るか、今いるユーザに投稿者を割り当てて「実行」をします。

いたってスムーズにデータの移行ができました。

どこまでデータが移行できたか

タグは移行できなかった。タグはほとんど使っていないので問題ないけれど。
やる場合はプラグインに手を入れる必要がある。
画像がメディアライブラリに入ってくれたら嬉しかったけど。
エクスポートファイルとの対応付けの難しさ、
エクスポートしたデータを変更してしまうデータ保全から無理もない感じで。
実装が難しそう。

あとは問題ない。投稿もコメントもちゃんと入っている。

コンテンツデータに手を入れるとすれば、画像の張り替え。
いままでの画像フォルダを残しておけば、そのまま引き継がれる。
特段手を入れる必要は無いけれど。
今回は画像数が少ないので、メディアライブラリで管理することに。
コンテンツデータは画像のところだけ手を入れた。

パーマネントリンクのURLをどう維持するか

一番考えて調整が難しかったのがパーマネントリンクの引き継ぎ。
パーマリンクの構造は、Movable Type のテンプレートで設定していたアーカイブマッピングに依存してしまう。

ブログ記事のアーカイブパスは、archives/%e.html
%e は、6 桁のエントリー ID、桁数が 6 桁に満たないとき、0 で埋めて表示される。

ブログ記事リストでは
カテゴリが %c/index.html
月別は %y%m/index.html
とパーマリンクの構造を設定していた。

WordPress に設定するパーマリンク設定として、
ブログ記事は Movable Type から完璧に引き継ぎ。
これは記事が検索されることを考えると譲れないところ。
ただし、今後はパーマリンクを変更できるようにしたい。

カテゴリやアーカイブは、
プラグイン「Custom Permalinks」でカテゴリ、タグを個別にパーマリンクの設定ができるので、対応できる。
けれど、今後の運営のことも考えて WordPress のパーマリンクの構造に変更することにした。

ということで、パーマリンク設定のカスタム構造は、
投稿のスラッグを 6 桁のエントリー ID でヒモ付けて
パーマリンク設定のデフォルトの選択にはない以下の通りに設定した。

/archives/%postname%.html

記事のスラッグを 6 桁のエントリー ID に変える作業をやった。

これでいままでのパーマリンクを引き継ぎつつ、
今後はパーマリンクを自分でつけられるようにしてみました。

Blue-Green Deployment で無事に移行完了

あとは、メニューを作ったり、必要なプラグインを入れたりしてレイアウトを整えた。
本番環境のサーバーに新しい DocumentRoot を作って WordPress を入れてそこに WordMove で同期。
サーバーの設定を前のブログの DocumentRoot から新しい方の DocumentRoot に向けて振り替え。
サーバーを再起動すると、WordPress ブログの運営が始まりました。
Blue-Green Deployment 的にデプロイを進めてみました。

ウェブサイトの移行は?

まだ試していない。ウェブサイトの移行も試してみたい。
普通はホームページのリニューアルを考えるものが大半だと思うので、正式なやり方がない。
そもそもCMS間でサイトの捉え方が違う。
Movable Type は、今までのサイト設計のようにフォルダーを作ってウェブサイトの設計ができるけれど、
WordPress は、固定ページを作ってそこに親子関係を作っていく設計をするので、
そこをエクスポートデータでどう吸収できるかがサイト移行の肝のような気がする。

最新版メジャーアップデートは安全とは言い切れない問題がはらんでいる