うぇびん あけましておめでとうございます。フリーランスのフロントエンドエンジニア、CMSのウェビングスタジオを今年もよろしくお願いいたします。
今週はスロースタートではありますが、本日から営業を開始しています。
a-blog cmsについて、メモしておかないといけない件が出てきました。
そうとうa-blog cmsを使っていないと、理解不能な内容となりますがご容赦ください。
追記：現象が確定したので、より詳しく書き直しました。
a-blog cmsのインポート機能の種類
a-blog cmsには、影響範囲が異なる、さまざまなエクスポート・インポート機能が実装されています。これは、ほとんどの設定をテンプレートではなく管理画面側で行う仕様によるものですが、使いこなすことで二回目以降の案件がとても楽になります。
上から順に影響範囲が大きくなります。他にもユーザーデータのインポートもありますが割愛します。
MySQLでログイン情報も含むすべてのデータ
ブログ単位ですべてのデータ
ブログ単位で、コンフィグ（編集、テーマ等）・ルール・モジュールのみ
CSVファイル形式でエントリー・カテゴリー・フィールド・タグのみ
WordPress・Movable Type形式でエントリー・カテゴリー・タグのみ
このうち、２番目の「ブログ単位」のインポートは、以前はメンテナンスモードのみの機能でしたが、バージョン2.7.0から管理ページ内でできるようになりました。
ちょうど一年前にリリースした「echo_zero」はこの機能の実装前だったので、ablogcms.ioでは利用できませんが、今後公開するa-blog cms用テーマやハンズオンデータは、できるだけこちらを使っていきたいです。
…が、この「ブログ単位のエクスポート」には、いろいろと不安定なところがあるようです。
二個目以降のブログからエクスポートした場合の問題
ちょっとまだ検証中なので断言はできませんが（なのでQiitaではなくブログで書いています）…
ブログIDが「002」以上（つまり、二個目以降のブログ）からエクスポートしたデータを、ブログが一個しかないブログへインポートすると、フィールド、ユニットなどのすべての画像 カスタムユニット内の画像がリンク切れになってしまいました。
システム内に存在していないブログIDのアーカイブディレクトリは無視する仕様なのかもしれませんし、ablogcms.ioの問題かもしれませんし、よくわかりません。
通常、a-blog cmsのインポートデータの画像パスに入っている「ブログID」は、IDがいくつであっても、インポート対象のブログIDに自動的に変換されます。
ですが、カスタムユニットの場合は、後述の「カスタムユニットの画像パスを編集できない」と関連して、自動変換が行われないようなのです。
現時点でわかっていることとしては、公開環境に移す際に、移動先のブログがひとつしかないとわかっている場合は、メンテナンスモードからのエクスポートを使うか、テスト環境も001のブログで構築しておいた方が無難ということです。
原因がカスタムユニットであれば、上記の対策も効果がないということになります。大弱り。
カスタムユニットの画像パスを編集できない
それならエクスポートしたzipファイル内に入っているYAMLファイルをテキストエディタで開いて、画像のパスを「002」から強引にシステムに必ず存在する「001」にすれば…と試してみました。
これについてはecho_zeroでもやっていて、今回もできましたが、今回は「カスタムユニット」がエントリーの大半を占めており、それらのデータが置換できませんでした。
カスタムユニットの情報はJSON形式で記述されたデータを、さらにBASE64エンコードで圧縮しています（BASE64 -> YAML -> JSONってすごいな…）。このため、単純なテキスト置換ができないのです。
BASE64をデコード・解析してパスを置換しようとしましたが、さすがにデータが壊れそうなので断念しました。
二人目以降のユーザーが書いたエントリーをインポートした場合の問題
二人目以降のユーザーが書いたエントリーが「ユーザーがいない状態」となってしまいました。
管理ページからのブログ単位のインポートでは、ユーザー情報は移行しないためなので、これは仕方ないとも言えます。
ユーザーを作ってからインポートするか、あとでユーザーを作って、ユーザーがいない状態のエントリーに振り分ければいいわけですが、Movable Typeのように、インポートの際にユーザーを作るよう促してくれればもっといいのにな、と思いました。
なお、今回の場合は、YAMLデータ内のユーザーIDをすべて置換で解決できました。
—-
そんなこんなで、不特定多数に販売する、a-blog cmsのランディングページ用テーマでこの問題に直面しており、どうしたものか悩み中です。
ちゃんと購入した方の環境で復元できなかったらたいへんです。
エクスポート・インポートは作業効率がかなり良くなるため、どのCMSでも多用しています。
どのCMSでも安定して使えるのはCSV形式ですが、カテゴリーやカスタムフィールドまでが限度で、a-blog cmsのモジュールIDやカスタムユニットのような複雑な情報は移行できません。
Movable Type・WordPressもブロックエディタが採用されます。ブロックエディタは編集する側にはとても便利なものですが、CMS間・バージョン間の移動が簡単にできなくなることは、頭に入れておくべきと思います。