Movable Type 5.2からMovable Type 6へのアップグレード方法【図解付き】

2015年9月をもってサポートおよび脆弱性対応が終了したMovable Type 5.2。
そこで、Movable Type 6へアップグレードを行いましたので、アップグレード方法のまとめとなります。

基本的なアップグレード方法の解説となりますが、一部、入れ子になっているmt:Elseタグの不具合っぽい症状もみられましたので、そちらもあわせてご紹介となります。

①ライセンス購入

まずはライセンスの購入。今回もラウンロード製品版の「Movable Type ソフトウェア版」を選択。
アップグレード前のバージョンは5.2のため、バージョンに伴う事前作業は必要ありませんでした。

>> ライセンスのご案内(通常/学校・教育機関向けアカデミック/開発者/個人無償)| CMS プラットフォーム Movable Type

>> 5.12、5.06、4.37以前のバージョンからアップグレードした後に必要な作業 : Movable Type 6 ドキュメント

②Movable Typeのダウンロード

上記にてライセンス購入後、「シックス・アパート ユーザーサイト」より該当の製品をダウンロードしておきます。

シックス・アパート ユーザーサイトからダウンロード
シックス・アパート ユーザーサイト

その際に、ログインで事前に登録したSAIDとパスワードが必要となります。

③バックアップ

データベースや既存のMovable Typeのファイルなど、必要に応じてローカルへダウンロード・バックアップを行っておきます。

phpMyAdminでデータベースをバックアップ

※環境によりバックアップ時に「DROP TABLE / VIEW / PROCEDURE / FUNCTIONを追加」にチェック。

phpMyAdmin を利用したデータベースのバックアップ・リストア

今回、サーバーはkAGOYAで自動バックアップを行っているため、データベース以外の完全データバックアップについてはそちらを事前バックアップの代わりに。

>> ファイルのバックアップとリストア – KAGOYA Internet Routing

④新しいmtフォルダをアップロード

ダウンロードしたMovable Type 6フォルダを解凍後、mtアプリケーションディレクトリをサーバーへアップロードします。

その際、既存のアプリケーションディレクトリ(mt)と被らないよう「mt_6」などにリネームしてアップロードし、
アップロード後、既存のアプリケーションディレクトリ(mt)を「mt_52」などに変更後、「mt_6」としていた新しいアプリケーションディレクトリ名を「mt」へ戻します。

mtアプリケーションディレクトリをリネーム

クライアントはTransmitを使ってます。

アップロード&リネーム後(リネーム前でもOK)、既存のmtディレクトリにある設定ファイルの「mt-config.cgi」新しいmtディレクトリへを移動し、新しいmtアプリケーションディレクトリ内のcgiファイルのパーミッションすべてを「755」へ変更します。

この際、新しいmtディレクトリに入っているmt-config.cgi-originalは削除しておきます。

新しいmtフォルダに入っているmt-config.cgi-originalは削除

⑤mt.cgi にサインイン、アップグレードを行う

https://example.com/mt/mt.cgi へアクセスし、『アップグレードウィザード』が実行します。
その後は自動でアップグレードが開始されます。

アップグレードウィザードを実行

⑥プラグインを移動

新しいアプリケーションディレクトリ(mt)のプラグインディレクトリ(mt/plugins/)へ、今まで使用していたプラグインを移動します。

プラグインディレクトリへプラグインを移動

また、「mt/plugins/」内のプラグインだけでなく、プラグインによっては「mt/mt-static/plugins/」に保存されているものもあるので、必要に応じてそのプラグインも移動します。

必要に応じてmt-static/plugins/にプラグインを移動

⑦ブログ別などで検索結果を分けている場合

スマートフォン用サイトなど、ウェブサイトに別途ブログで制作をしていて、検索結果ページ(使用プログラム: /mt/mt-search.cgi)を分けている場合があると思います。

その場合、以下のようにスマホ内で指定している検索結果用テンプレート(◯◯◯◯.tmpl)を、アプリケーションディレクトリ(mt)のsearch_templates ディレクトリへFTPなどで移動する必要があります。

<input type="hidden" name="Template" value="拡張子なしの検索テンプレート名">
※管理画面ではウェブサイトテンプレートの「テンプレートモジュール」箇所で同テンプレートが見られるかと思います。

●移動先ディレクトリ
/mt/search_templates/

⑧再構築

アプリケーションディレクトリ内のパーミッションの確認やプラグインの移動を行った後、すべての再構築を行います。
再構築終了後、実際にサイトを確認して不具合などの確認を行います。

入れ子になっているmt:ElseIfで一部不具合?

再構築後、カスタムフィールドでMTElseを使って分岐している箇所が表示されないなど不具合を発見。

以下に、「入れ子になっている MTIf の中で…」とありMTElseにnameモディファイアやtagを付けてみたのですが改善せず。
もしかしたら、「入れ子になっているMTElse側」にもなにか不具合があるのかもしれません。
※2015/10/01現在。

入れ子になっている MTIf の中で name モディファイアを省略して MTElse、MTElseIf タグを利用した場合、判定結果が正しくない問題を修正しました。(#111805)
Movable Type 6.0.4 リリースノート : Movable Type 6 ドキュメント

問題点の切り分けのため以下を試してみましたが、最終的にmt:ElseIfタグをmt:Elseタグへ変更し、取り急ぎの改善策としました。
MTIfと入れ子になっていないMTElseIfについては不具合が見られないため、カスタムフィールドのタグで判別し、「入れ子」になっている場合が該当するように思います。

改善(分岐)されたなかった修正

  • ・</mt:ElseIf>の閉じタグ有り、name・tagなしで分岐せず。
  • ・</mt:ElseIf>の閉じタグなし、<mt:ElseIf name="◯◯◯◯"> nameモデファイア有りで分岐せず。
  • ・</mt:ElseIf>の閉じタグなし、<mt:ElseIf tag="◯◯◯◯"> tag有りで分岐せず。

改善(分岐)された修正

「改善」ではないですが、コードの状況により改善策の代替になるかと。

  • ・<mt:Else>〜</mt:Else>の閉じタグなし有りで分岐OK。

WordPressでおすすめのバックアップとセキュリティ系プラグイン

WordPressのオリジナルテンプレートでウェブサイトを制作する際に、個人的な経験(汗)からできる限りプラグインを使わずに制作を行っています。

しかしながら簡便さよりも必要性という理由から、いくつかのプラグインは利用させてもらっていて、そういった基本プラグインセットも定期的に入れ替えを行っています。

今回、バックアップ・セキュリティ系のプラグインを見直すにあたり、ちょっと便利だなあと思うプラグインをご紹介させていただきます。

バックアップ系プラグイン

内部・受注どちらでも最低限の定期バックアップを行うためにプラグインを利用していて、その中でも一番利用頻度が高かったのがWP-DB-Backupなんですが、ちょっと別のものも物色。

できればデータベースだけでなく、ファイル全体のバックアップ(cron設定とかをこっちでしなくても)できるものがあれば良いなあと思い、
また、同一サイト内で複数のWordPressを利用する場合もあるので、DBのみ・ファイル全体など選択できるものがあればと思いいくつか試してみたところ、BackUpWordPressがかなり良い感じでした。

BackUpWordPress

BackUpWordPress

近い機能のプラグインも別途あったのですが、BackUpWordPressが一番しっくりきました。
気に入った点は以下。

  • サーバー設定せずに自動バックアップが可能
  • バックアップスケジュールの指定ができる
  • 保存する個数(新しいものから何番目までとか)を指定できる
  • DBのみ・ファイル全体など選択できる

また、有料($99)でDropbox・Google Drive・Amazon S3・FTP(別サーバー)・Rackspace Cloud・Windows Azure・DreamObjectsへのバックアップも設定できます。

セキュリティ系プラグイン – 外部対策用

ログイン画面についてはいろいろと対策含めあるかと思いますが、最終的に外部の人やその他のツールにログインパスワードをブルートフォースアタックされた場合にログイン画面をロックして不正ログインを防いでくれるプラグインです。

SiteGuard WP Plugin

SiteGuard WP Plugin

同類のプラグインもいくつかりますが、個々の設定ができたりCAPTCHA(画像認証)があったりと多機能です。

セキュリティ系プラグイン – 内部用

テーマの問題点をチェックするプラグインなどもありますが、こちらはオリジナルテンプレートに限らず使用するテンプレートやWordPressの設定状況・脆弱性のセキュリティをチェックするプラグインです。

Acunetix WP Security

Acunetix WP Security

セキュリティ上の脆弱性を一括でチェックでき、必要な箇所は任意で設定変更が可能です。
また、チェックする脆弱性のレベルも選択可能です。

常に使うことはないかもしれませんが、公開前とかのチェックには役立つのではないでしょうか。


2015.07.10
Acunetix WP Securityを有効化しておくと、読み込みがかなり遅くなる(?)ように。常時は停止しておいた方が良いかもしれません。

こういった防止策の前にユーザー名にadminを使わないとか、オリジナルテーマを制作せずに無料のテーマを使用する際にはものによっては一応注意するとか、初歩的な対策も大切ですよね。

heteml でKAGOYA 外部MySQL(MySQLプラン・共用)を使ってみた

MovableType 再構築の不具合がどうにか解消されないものかと、
費用抑えめの専用サーバー から、MT の動作が早いと評判のレンタルサーバーを教えてもらい、まとめていくつか試してみることにしました。

その中で、個人的にちょっと楽しみにしていたのがKAGOYA の『外部MySQL(MySQLプラン・共用)』
MySQL サーバーのみ、外部のものを利用できるとのことで、費用も共用で1GB 月/525円(最高10GB)と、かなり格安。
※専用プランも有り

現状で不具合解消を考えているのが、heteml を利用しているため、
改めて外部DB(MySQL) 利用の旨を問い合わせしたところ、heteml としてはOKとのことでした。

ちなみに、MT が早いという他のレンタルサーバー についても問い合わせしたところ、
各社、基本的に外部DB(MySQL) の利用はOKのようです。

さて、heteml での外部DB(MySQL) 利用についてどうであったかと結論から述べると、
現時点(2011年2月現在)では『接続できず』 というのが、まずの着地となってしまいました。(ホント残念)

というのも、カゴヤ 外部DB(MySQL) と、heteml のMySQL クライアントのバージョンが違うとのことで、
Movable Type のログイン画面の後、下記のようなエラーメッセージが表示されてしまいます。

しかしながら、KAGOYA の外部データベースサービスや、ましてやheteml についておすすめできない的な内容を書くつもりではなく、
現時点で、たまたまバージョンの相違があって利用できず、その件について個人的に時間を多少なりとも、費やしてしまったということをお伝えできればと思っています。

接続テスト の最中についても、KAGOYA、heteml ともにメールで何度も問い合わせを行ったのですが、
双方ともに、その対応の親切さには感謝しています。(ありがとうございます)

heteml については、一応、バージョン変更も案件にはあるそうですし、
もろもろと機能追加や変更など頻繁に行われていますので、今後次第ではないでしょうか。

再構築の不具合については、基本、MySQLサーバーのメモリなどのスペックが関係するようなので、
実際につないでみないことにはなんとも言えませんが、また近々、実際にMTの動作が機敏だった「sixcore」とかで試してみようと思ってます。

ちなみに、今回の件は個人的知識の範囲内でのまずの着地となりますので、
そのほかの方々であれば、もしかしたら可能なのかも知れません。悪しからず。

カゴヤ MySQLプラン

https://www.kagoya.jp/mysql/

heteml

https://heteml.jp

sixcore

https://www.sixcore.ne.jp/shared/index.php

異なるドメインで移転先が『ディレクトリ』の場合、301リダイレクトの使用は正しい?

現在管理中の、某ブランドに特化したECサイトがあるのですが、
某事情から、ドメイン変更(移転)が必要となり、

通常(?)であれば、別のドメインを取得して…、という変更が多いかと思いますが、
今回の移転については、それと異なる移転が必要となったので、ちょっとまとめてみました。

『異なるドメイン』で、尚且つ移転先サイトが既存の総合ショップの『ディレクトリ』
その内容というのが、移転先のサイトについては、関連するブランドなどを総合して取り扱う旗艦サイト、
移転が必要となった旧サイトについては、その取り扱いブランドの一つに特化したサイトになります。

アイテムも、基本、取り扱いが同じアイテムが揃っていることもあり、
総合サイトの、該当ディレクトリへの移転を行うこととなりました。

異なるドメイン間でのリダイレクトについて、
若干、個人的にはっきりしない事柄があることもあり(正当性の立証として)、

個人的にはあまりないケースでしたので、
軽くまとめつつ、今後ちょっと様子を見ながら、必要に応じて追記していこうと思います。
※既に周知のことかも知れませんが

尚、ご覧いただいている方には大変申し訳ありませんが、
該当サイトの詳細については、すべて掲載が出来かねますので、その点についてはご了承くださいませ。

【移転時の情報】

[旧(移転元)サイト A]
  • 公開後約1年10ヶ月
  • インデックス数 約147
[移転先サイト B]
  • 公開後約2年
  • インデックス数 約589

【登録者・管理者情報】

  • whois
  • Google Analytics
  • Google ウェブマスターツール
  • Yahoo!サイトエクスプローラー
  • Bing Webmaster Tools

旧サイト並びに移転先サイトともに同一

【実施したこと】

[301リダイレクト前(PC)]

  1. お客様への統合案内掲載(リダイレクト2ヶ月前より、すべてのページにて統合のご案内を行う)
  2. 統合告知約一ヶ月後、先行してケータイサイトのみリダイレクト

[301リダイレクト後(PC)]

  1. サイクル的なこともあり、告知2ヵ月後にサイト全体の301リダイレクト ※基本、個々の関連ページへ
  2. GWT にて、「アドレスの変更」 ※ディレクトリへの引っ越しだったので、若干迷いましたが
  3. 旧サイトファイル削除 ※移転先サイトが運営中であるため

[Memo]

  • 「/」でルート以下、もしくはルートの301リダイレクトの設定を行っていると、GWTなどでの認証がエラーとなる。「Redirect permanent /index.html https://www.newdomain.com/」とかでリダイレクトする。
  • Google ウェブマスターツールで「アドレスの変更」を行う際には、.htaccessなどでのリダイレクトを行っていると、移転元サイトが認識されない。

【疑問点】
異なるドメインでの「301リダイレクト」について、主要検索エンジンの説明では使用を推奨されていますが、
「管理者が同じ」であることで、それが「正しい利用」と「そうではない利用」と、しっかりと認識されるのかどうか、

また、Yahoo!でのリダイレクトの使用で、挙動が定かではないようなことも耳にしたこともあり、その点が今後どうなるか、
ちょっと見守っていきたいと思います。

ちなみに、今回のように『ディレクトリへの移転』でも、『301リダイレクト』が正しいかどうか、
Google フォーラム、Yahoo! については問い合わせを行ってみたところ、『基本的』には有効であろう回答を頂きました。

[引用]
Yahoo!

「お問い合わせくださいましたにもかかわらず誠に申し訳ございませんが、こちらの窓口では、公平性の観点から個々のサイト作成についてアドバイスを行っておりません。

お力になれず誠に申し訳ございませんが、ご案内可能な内容に限りがありますことを、何卒ご了承くださいますようお願いいたします。

なお、このたびお問い合わせいただきましたリダイレクトが設定されているURLにつきましては、米国Yahoo!(Yahoo! Inc.)が定めるガイドラインに従って、検索エンジン用ロボットがデータベースに登録します。

ガイドラインについては、次のページで詳しくご案内しておりますので、お手数ですが、ご参照くださいますと幸いです。

◇Yahoo! Inc.のリダイレクトに関するガイドライン
https://info.search.yahoo.co.jp/archives/002865.php

※誠に恐れ入りますが、例外的に、上記ガイドラインとは異なる方法で判定し、インデックスに登録される場合がございます。あらかじめご留意ください。

データベースの更新は、適宜実施しておりますが、検索結果に反映されるまで、お時間をいただきますことを、ご理解くださいますようお願いいたします。

最後になりますが、表示順やそのほかの事項については、Yahoo!検索のシステムの変更などの理由で、予告なく変更される可能性があります。あらかじめご了承くださいますようお願いいたします。」

【ヘルプ参考】
サイトの移転 – ウェブマスター ツール ヘルプ
リダイレクトとは? – インフォセンター – Yahoo!検索

================================================================================
【追記】

5/20
Google で、移転元サイトからのメインキーワードでの移転先サイトとの、SERPで順位変更を確認。
5/24
Yahoo! で、移転元サイトからのメインキーワードでの移転先サイトとの、SERPで順位変更を確認。
ただし、SERP のタイトルやスニペットは移転先サイトに変更されているが、表示されるドメインのみ、移転元サイトのまま。

hetemlのWordPress 2.9 への自動アップグレードで、MySQL4から バージョン5への移管

年の瀬も迫ってきたこともあり、
もろもろとたまったものを整理しようと思っていたところ、

heteml で使っている某ブログで、「WordPress 2.9 日本語版」が出ていたので、
ついでにアップグレードしておこうと、自動アップグレード を行ったところ、

MySQL バージョン 4.1.2 以上が必要とのことで、
現状のままでは自動で行うことができないようでした…。

WordPress 2.9 日本語版リリースのお知らせ

若干迷いもあったのですが、取り急ぎ手を付けてしまった(?)のもあり、
少し試してみました。

最初、「phpMyAdmin」にてエクスポート、アップロードを行って見たのですが、
なぜか「文字化け」らしいエラー が続出し、

「phpMyAdmin」でエクスポートして、「utf8」で更に上書き保存とかを行ったり、
該当箇所と思われるところを修正しても治らず、

試しに、
「SQL Buddy」でエクスポートした「export.sql」を「phpMyAdminにインポート てみたところ、
WordPress 2.9 へ、自動アップグレードできました。
※「hReview」がついてる!

========================================================
参考: Heteml(ヘテムル)のMySQLサーバー(データベース)障害対策
https://konohaotoshi.blog69.fc2.com/blog-entry-250.html

◎全ファイルのバックアップ

まずは、heteml 管理画面より。
①「SQL Buddy」での 【データベースのバックアップ方法】
1.SQL Buddyでログインする。
2.Languageのプルダウンメニューから、「日本語」を選択する。
3.左サイドメニューの「エクスポート」をクリックする。
4.データベース名表示エリアにinformation_schemaと既に作成されているデータベースが表示されているので、作成したデータベースのみを選択する(以下、SQLファイル1とする)。
5.オプションは、「完全挿入」を選択する。
6.出力先は、「テキストファイル」を選択する。
7.送信ボタンをクリックする。
8.しばらくすると画面上部に、ダウンロードボタンと「ファイルに書き込み成功ダウンロードNote」のメッセージが表示される。
9.ダウンロードボタンをクリックし、テキストファイルをローカルのハードディスクに保存する。

②「export.sql」ファイルの先頭の方の以下、2行をコメントアウト「– 」
— CREATE DATABASE `旧ーデータべス`;
— USE `旧ーデータべス名`;

③「phpMyAdmin」でインポート

④WordPress の「wp-config.php」を、新しいMySQL5の内容に変更して、アップロード


⑤WordPress 2.9 へ自動アップグレード
========================================================

これであっているかは自分では確認する術もないですが、
現状ではまずは大丈夫そうです。

P.S. このブログはXREA なんですが、自分のサーバー は「MySQL5.1.22」のようで、
そのまま自動アップグレード ができました。
この年の瀬に、ありがとうXREA。

change_history