あけましておめでとうございます。フリーランスのフロントエンドエンジニア、CMSのウェビングスタジオを今年もよろしくお願いいたします。

今週はスロースタートではありますが、本日から営業を開始しています。

a-blog cmsについて、メモしておかないといけない件が出てきました。

そうとうa-blog cmsを使っていないと、理解不能な内容となりますがご容赦ください。

追記：現象が確定したので、より詳しく書き直しました。

a-blog cmsのインポート機能の種類

a-blog cmsには、影響範囲が異なる、さまざまなエクスポート・インポート機能が実装されています。これは、ほとんどの設定をテンプレートではなく管理画面側で行う仕様によるものですが、使いこなすことで二回目以降の案件がとても楽になります。

上から順に影響範囲が大きくなります。他にもユーザーデータのインポートもありますが割愛します。

このうち、２番目の「ブログ単位」のインポートは、以前はメンテナンスモードのみの機能でしたが、バージョン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間・バージョン間の移動が簡単にできなくなることは、頭に入れておくべきと思います。