Please Sign In or Register

他の CMS から Drupal へのデータ移行

私自身は、使用している CMS から別の CMS へシステムを移行したいと感じたことはないのだが、XOOPS サイトを Drupal サイトとしてインポートするための Xoops Import というモジュールの開発が行われていたり、実際に Movable Type から Drupal へ移行した時の方法が公開されていたりと、巷では需要があるのかもしれない。
ということで、他の CMS から Drupal へのデータ移行について簡単に Drupal ハンドブックで調べてみた。 本当に "ちらりと" だけだが...

Drupal ハンドブックの Migrating from other software | drupal.org に、移行に関する内容が CMS ごとにまとめられて記載されている。
コンテンツ内では移行のためのモジュールや非公開スクリプトも紹介されている。
残念ながら、モジュールや非公式スクリプトなどの多くはまだ Drupal 5.x に対応していないようだったが、コンテンツ自体には Drupal 5.x に対応した内容も追記されているようなので、移行前には目を通しておきたいたいものだ。
もちろん、移行を考えている CMS や Drupal のバージョン、日本語環境や個々の環境など、複雑な問題を考慮しなければ移行可能かどうかの判断は難しいので、あくまでも参考程度ということにはなるだろう。

[参考]
Migrating from other software | drupal.org
Xoops Import | drupal.org
Perl Tips: Movable Type 3.35 を、Drupal 5.1 に移行する。

トラックバック

トラックバックは承認後に表示されます。

URLから "-nospam" を削除してトラックバックを送信してください。

コメント

日本におけるXoops事情

日本においては、xoopsからフォークをしたxoopscubeというモノが後継という扱いになっています。
厳密には後継というのはおかしいですが、xoopsを日本国内で正式にサポートしてきたグループがフォークすることになったので、後継という見方です。
あらたに、別のグループがxoopsの正式なローカルサイトを立ち上げればxoops互換(派生)CMSという扱いになるんでしょうね。
xoopsは正直に言って、これから混迷するかと思います。

xoopsは、コンテンツを基本的にモジュールが管理していますから、どれだけ多くの外部モジュールに対応できるかがすべてですね。
そもそも、CMSの骨格そのものがまるで違うモノだと認識しているのでなかなか難しいと思っています。
登録ユーザーの情報くらいはコンバートできるといいですね。
ていうか、それだけやったら、後は作り直した方がよいかと思います・・・(^_^;)
だいたい、モジュールの趣向がまるで違うし・・・。

日本で XOOPS といえば...

「日本で XOOPS といえば XOOPS CUBE のこと」 っぽいですよね。 個人的には、使うのであれば XOOPS 2.0 なのですが...

どの CMS を選択したとしても、使い込んでいけばそれが一番使いやすい物になると思うので、Movable Type のように再構築が必要だとか、そういう根本的な部分で問題が発生しなければ移行する必要性というのは感じないのですが、思ったより話題に上がっているようなので...皆さん大変だな、と。

Drupalがxoopsに劣っている点

Drupalがxoopsに劣っている点がトップページの自由度だと思っています。
xoopsはトップページのブロック区分がDrupalよりも多いので、ポータルサイトっぽい作り方をしたい場合には優れています。
そう言うてんではDrupalは所詮ブログサイト・・・という雰囲気ですね。
そこが、Drupalの唯一劣っている部分なのではないかと思っています。
ま、比べるモノでもないのですがね(^_^;)
モジュールのあり方そのものが違いますからね。Drupalではコアの機能を拡張するモノ、xoopsは機能を追加するモノ。
ワタシはそんなイメージです。
サイトの中で、趣向の違うコーナーを置きたいのならxoops、違う趣向でありながら統一感のあるコーナーを置きたいのならDrupalではないかと思っています。
どう違うの?と言うのを説明するのはやっかいですが(笑)
だから、元々目指すモノが違うモノなので、コンバートというのは意味がないのではないかと思っているくらいです。
しかし、xoopsで作り始めたけど、どうもDrupalの方がイメージに合う・・・という場合にはコンバートという欲求はできますよね。
ワタシ的にはユーザー情報だけ引き継いで、それ以外は作り直した方がよいと感じています。
それくらいxoopsとDrupalでは感覚が違います。
Geeklogもxoopsを意識しているモノですから同様だと思います。
他のCMSは使ったことがないので判りませんけど(^_^;)

確かに。

デフォルトの状態で...という意味ですよね。 それだと、確かにブログっぽい感じですよね、Drupal は。
XOOPS っぽいレイアウトも求めている場合にはデメリットとも言えますし、他のブログツールと似たようなレイアウトを求めている場合にはメリットとも言えますよね。

多少手を入れても OK ということであれば、Drupal のレイアウトは結構自由度が高い気がします。
XOOPS のことはよくわからないのでなんとも言えませんが...

今、これからテーマを作成していくための基盤にならないかな?というテーマを作成しているのですが、それが終わったら、XOOPS っぽいテーマとか作ってみるのも面白いかもしれませんね。
Drupal → XOOPS 化計画 みたいな感じで。 XOOPS のことが良くわからないので、できたとしても見た目だけということになるでしょうけど。

...って、思い切り話題から逸れてしまいました。
まぁ、「今使ってる CMS に不満を感じた時に、どうにかならないかと使い慣れた CMS でいろいろ試してみるのも、さっさとあきらめちゃって他の魅力的な CMS に乗り換えるのも... 自由だ~っ!」 ということで。

なにげに・・・

今、これからテーマを作成していくための基盤にならないかな?というテーマを作成しているのですが、

期待してますので\^o^/バンザーイ

自分で作れよっ!

とか、言われそうだなぁ・・・(^_^;)

あ。

自分用だったりしたのですが... 公開するみたいな印象を与えてしまいましたかね?

template.php でテーマ関数を追加する方法の一例くらいにはなるかもしれませんから、そういう意味でなら、公開してもいいかな...とは思いますけど、IE で表示が乱れることをわかっていながら放置していることや、最近コンテンツの更新を怠っていることへの言い訳を含めて "書いちゃった" だけなので、あまり期待はしないでくださいね。

他のCMSから乗換と考えたら

多少手を入れても OK ということであれば、Drupal のレイアウトは結構自由度が高い気がします。

他のCMSから乗換という前提で考えた場合には、モジュールの追加程度でレイアウトできるブロック区分が増やせないと意味を成さないと思います。
多少手を入れられると言うことは、Drupalを知っていると言うことじゃないと難しいと思われますから。
Drupalを知っている人がやるのであればそれは、好きにやればいいので(笑)

ワタシは普段Drupalは文献管理システムという表現をしますが、ポータルサイト構築ツールとxoopsなどは例えられる事が多いですからそれだけシステムの開発思想が違うと言うことなのです。
そもそも、Drupalをポータルサイト構築ツールとして使おうとしたら何かしら手を入れないと実現は簡単ではないという当たり前のことなんですけどね。
ま、xoopsを使ったことがあれば、Drupalとはまるでシステムの目指しているモノが違うと言うことが理解できますよ。
それくらい、違うと思っています。

説明になってませんね(^-^;△フキフキ

乗り換えできるのであれば...

他のCMSから乗換という前提で考えた場合には、モジュールの追加程度でレイアウトできるブロック区分が増やせないと意味を成さないと思います。

Panels モジュールがおそらくそういった機能を持っているのではないかと思っているのですが...というか、そもそも、その程度では CMS を乗り換えることは難しいように感じます。
少なくとも現在の私の知識では CMS を乗り換えることはまず無理ですから、「乗り換えることができる = 移行元および移行先の双方のシステムに精通している」 ものだと...

このコンテンツでも、もしも真剣に移行を考えているのであれば参考にはなるのでは?ということで、あえて、詳細を記載したり、日本語に翻訳したりといったようなことは行わず、簡単に移行できるものではないのでは?という気持ちを表現したつもりだったんです。
基本的に、こういった作業では、CMS のシステムの構造だけでなく、それぞれのサーバの環境なども左右してくるものだと思いますしね。

公式サイトの参考文献はこのあたりにありますよ...というご案内程度に。ということです。

と、試しに、最新安定版 XOOPS Cube Legacy 2.1.1 をインストールしてみましたが、最初からいろいろなモジュールが同梱されているものだと思っていたので、必要最低限しか同梱されていないことにちょっと驚きました。
Drupal にも負けないシンプルさだな...という印象です。 個人的には、必要なものを自分で追加するスタイルが好きなので、好印象ではありましたが...

結局、テーマはいじらないと駄目ですよ

Panels モジュールがおそらくそういった機能を持っているのではないかと思っているのですが...というか、そもそも、その程度では CMS を乗り換えることは難しいように感じます。

結局、テーマはいじらないと駄目と言うことです。
テーマがいじれると言うことは、ある程度Drupalなり、xoopsなり、PHPなりに、触れていないと難しい話になるのだと思います。
ですから、同じようなイメージでとらえたら痛い目に遭いますよ・・・と、言う感じですね。
だから、移行するならユーザー情報だけで、他はまっさらから構築し直した方がよいですよ・・・と、思うわけです。

xoopsimportも最低限のコンバートしかできないようですから。

xoopsって、コンテンツ作る機能は基本的に入っていないんですよ。
Drupalはstoryや、page、blogとコアに含まれていますから、そう言う意味じゃDrupalの方がすぐ使える状態のモノとも言えそうです。
xoopsはその辺がホント、最低限しか入ってません。
xoopsの場合、インストールしてまず最初にやることはモジュール探しですから(笑)
モジュールの有効/無効/DB削除はxoopsの方が完備してますから、Drupalにも早く追いついて欲しいモノです。

ま、ワタシもxoops -> Drupalの乗り換え組ですが、データのコンバートなんてはなっから考えていなかったので気楽なモノでした。
ただ、xoopsとDrupalはまるで仕組みが違うので、考え方を切り替えてかからないと壁にぶち当たりますね(笑)

申し訳ありません。

すみません。今頃気づきましたが、「乗り換え」というのは、データの移行を含む含まないは別として考えられていたのですね...
確かにそうですよね。一緒くたにしていました。本当に申し訳ありません。

xoopsって、コンテンツ作る機能は基本的に入っていないんですよ。

XOOPS Cube は人気の高いモジュールがパッケージされているのかと勝手に思っていたのですが、Simple, Secure, Scalable をコンセプトにしていると書いてありましたね。 これもまた、よく読まないと...でした。

cubeは

XOOPS Cube は人気の高いモジュールがパッケージされているのかと勝手に思っていたのですが

xoopsとは別のプロジェクトだと思った方がよいです。
今はまだ、xoopsとの互換性維持の部分が多いですが、そう言う部分はこれからは一側面という状況になっていくようです。おそらく、最終的にはxoopsという名はついていても、xoopsとは非なるモノ・・・ということになるのだろうと思います。
て言うか、そうなったときに"xoops"とついていることの意義は疑問と言う気がしますけどね・・・。
ま、今のうちからxoopsとは別のモノだと思った方がよいです。
日本ではcubeの方が多数を占めているようですが、それはあくまでも日本語に関する情報が豊富だと言うだけのことです。今後は、xoops用のモジュールなんかも動作が怪しくなっていくのでしょうから、cubeの行く先はまだ見えてこないというのが客観的な見方ではないでしょうか。

乗り換えに関しては、データコンバートの有無に関係ないように言っていたつもりでしたが・・・そうは見えなかったですかね?スミマセン。

自分用だったりしたのですが... 公開するみたいな印象を与えてしまいましたかね?

てっきり、テーマデザインを配布するのかと(笑)
ワタシとしては、ベースとなりうるテーマデザインを作って欲しいかなとか思っています。
本当に骨だけみたいな。
ま、実装のやり方は三者三様のようですからね・・・色々なテーマデザイン使ってみてると。
ただね、あんまり懲りすぎると、折角コアで日付まわりのフォーマットが選べるようになっているのに、テーマデザインで反映しないような造り方をされるのが最近多くて・・・なんか、意味がないと言う気がしてきてますけど(^_^;)
懲りすぎるのも考え物です・・・。

いつもスミマセン。

データを移行することについてまとめていた(つもりの)コンテンツだったので、頭から、データ移行を含む乗り換え作業と決めてかかっていたのでしょうね。 ホント、いつもいつも申し訳ないです。

XOOPS や XOOPS Cube については、XOOPS のこと自体もよくわからないので、違うのかどうかもわかりませんが...、一応、フォークということになっているようですし、異なる方向へ歩んでいくのは当然のことなのでしょうね。
暇があったら、自分なりに Drupal との違いを比較してみようかなと思ってインストールしてみたのですが、簡単に始められるものではなさそうなので、いつになるやら...です。

......テーマ、ですね。
カスタマイズのベースになるようなものを配布していきたいなとは思っているのですが、どのくらいまでの出来上がりがちょうどいいかの判断が難しいな。というのは確かにありますよね。
今回のは自分用にということで、ほとんどこのサイトのイメージで作成していたので...もうちょっとプレーンな感じのものを仕上げることができたら、公開したいな。と思います。

xoops

昔、Drupalを始める前に、紹介してくださった方が言っておりました。
「xoopsと同じ感覚で始めると痛い目に遭いますよ」
って。
まさにそう思いました。
それくらい違うと言うことです。
taxonomyでコンテンツをリンクするDrupalに対して、xoopsはモジュール毎なんですよ。
つまり、コンテンツが独立しているのです。
だから、ポータルサイトに向いているんですね。共有するのはユーザー情報だけで、コンテンツはモジュール依存。
だから、コンテンツを作る際には最適なモジュールを探すことが一番最初に必要になるんですよ。
例えば、フォーラムというのはxoopsにもありますが、そこでの発言はフォーラムの中だけなんです。
他のモジュールでコンテンツを作っても同様で、そのモジュールの中だけなんです。
検索を例に取ると判りやすいのですが、検索をするとモジュール毎に分類されて結果が出力されます。
Drupalのようにtermで検索して、結果は純粋にコンテンツで検索されて・・・という事ではないのです。
それから、xoopsの検索モジュールが対応しているモジュールのコンテンツしか検索できません。
これが、xoopsとDrupalのシステムの根本的な違いだと判る良い例かもしれません。
マニアックな例として言えば、WindowsとTRONの違いとでも言えばいいかもしれません。

どのくらいまでの出来上がりがちょうどいいかの判断が難しいな。というのは確かにありますよね。

そうですね。
複雑な飾り付けはしていない、手を入れて使ってもらうという前提と言うモノがあるといいなと思っています。
ただし、最低限のレイアウトは出来る程度の。
日本語前提なのであれば、日本語でバリバリコメントを書き込むというのも手でしょうかね。
そう言ったベースが欲しいなぁって、思っています。
ま、気が向いたらよろしくお願いします。

・・・って言うか、おねだりばかりしていないだろうか?(^-^;△フキフキ

逆に、楽しめるかもしれませんね。

実際にサイトを運営するということになれば、他の CMS はまだ実用レベルまで使い込んでいないので "Drupal" 以外に選択の余地はないのですが、特に定まった目的を持たずに CMS を試す時には、いつも 「どんな特徴を持っているのだろう?」 ということを知りたいという気持ちで挑んでいますから、痛い目にあうくらい違った性質のものの方が楽しめるかもしれませんね。

テーマに関しては、大体の構想が(自分の中で)定まってきましたので、一応、自分のための...ということが前提になってしまいますが、ある程度調整できたところで公開したいと思います。
いつになるかはわかりませんが...

勉強にはなると思います。

ワタシも、xoopsを少し、Geeklogを少々触った程度で、使いこなすまで至りませんでしたのでアレですが、Drupalとはまるで違うモノであると言うことは間違いないです。
システムにおけるコンテンツというモノのあり方が大きな違いだと思っています。
Drupalは本当に、文献管理システムと表現したいくらいにコンテンツをカテゴリ分類でまとめている感じなのですが、xoopsは色々なモジュールを追加して、それぞれモジュールの作り出すコンテンツの棲み分けをさせていると言うイメージが強いです。Geeklogは正直言って自由度があまり高くないという印象しかないのでよく憶えてません(Drupalよりはxoopsに近いというのだけは確かです)。
xoopsはまさに、サイトを作るってなイメージで、Drupalは文献を作るってなイメージです。
どちらがいいも悪いも無いのですが、好みは別れるところだと思います。
ただ、xoopsのシステムが他のCMSと比べて重いというのは感じます。そろそろ、システム自体の再設計をしなければいけない時期でもあったのだろうと思います。
そう言う意味ではCubeのフォークはいいタイミングだったのかもしれません(フォークまでの経緯はポジティブではありませんけど)。
デザイン系もスッキリしてくれるといいですね。Drupalのようにテーマデザインだけでかなりの装飾がコントロールできるようになればいいような気がします。モジュールが持っているテンプレートは全廃して。その方がスッキリすると思います。二重構造はわかりにくいだけです。
Geeklogは日本のローカルサイトが頑張っています。
頑張っているとは思いますが、システムそのものが扱いやすいとは思えません。
セキュリティに拘るのはいいのですが、セキュリティの高さと運用のしやすさのバランスがとれていないのが課題ではないかと思っています。
例えば、システム本体の設定がプラグイン(拡張機能。Drupalで言うところのモジュール)なしにはできない(基本、テキストエディタでファイル書き換えです)。インストールが公開領域と非公開領域に分けなければいけない(インストールはすべて公開領域にすることも可能だけど、セキュリティが下がる・・・当たり前だけど)。記事の編集がすぐできる(管理画面を経由しない)とか言うのを売りにしてたけど、Drupalではごく当たり前のこと。WYSIWYGエディタのFCKeditorを内蔵しているが、オン/オフができないのでHTMLタグを入れてはいけないエディット画面でもオフにすることができない(つまり、PHPを使ったページとかを作るのには不都合がある)。・・・などなど、運用にはあまりおすすめできない内容でした。ただし、去年の話でいくつかの課題は克服したという話は聞いています。聞いただけで、試してませんのでどの程度進化したかは判りません。インストールするだけでも骨なので、テストで入れただけの人間にとってはめんどくさいだけ(笑)

でも、サイトとしての構築の仕方はDrupalとは違うので新鮮かもしれません。
遊んでみる分には楽しめると思います。ユーザー層の数が桁違いなので、色々なモジュールがありますからね。
特に、日本語で使うにはDrupalより遙かに情報量が豊富ですからね。
いい刺激にはなると思います。

テーマデザインの公開、お待ちしています。
それを使ってカスタマイズが思い通りにできるのかどうかは別な次元の話ですけど(笑)
PHPがホンの少し判ってきたのでそれを使ってなんか仕掛けができたらな・・・なんて夢見てますけど(笑)

時間があれば、勉強してみます。

まぁ、何事にもチャレンジということで、"時間があったら" 勉強してみようかな...と。

と、Drupal 6.x では、確か、各モジュールにテンプレートを持たせるような方向に進んでいるようです。
細分化されることには違いないのですが、モジュールがアウトプットする内容のフォーマットは、現時点では theme_fanctions() でテンプレートっぽいものを定義するようになっているのですが、そこをテンプレートファイルとして別にすることで、フレームワーク化されるという感じになるのだと...
(ん~。 正直、ちょっと便利になりそうだけど、使ってみないとわからないってことですね、結局。 スミマセン。)

また話が逸れてしまいました...

私は、jQuery のプラグインをつかっていろいろ仕掛けしたいな...と、密かに目論んでいます。

ちょっと、表現がきつかったですね。

モジュールがテンプレートを持っているのを悪のように書いてしまいしたが、ちょっと、誤解を生みやすい表現でしたね。スミマセン。言葉足らずでした。
要は、作る人次第と言うところに帰結するのですが、本来、テンプレートでは装飾に関わることを記述するのは好ましいことではないはずなのですが(テーマデザインという機能を意味のないモノにしかねない)、テンプレートにばりばりにclassやid指定を独自に定義してたり、htmlタグで装飾を指定していたり、styleを直に書き込む作者が予想以上に多かったので、テンプレートの使い方が好ましい状況ではないので廃止した方がよいと言うところから来た意見でした。
Drupalの方で、どのようなルールを決めて実装するのか判らないので現時点では何とも言いようがないですが、そう言う轍を踏まえたような仕組みになれば言うことはありませんね。
ただし、テーマデザインを作る立場から見たら喜ばしい状況ではないというのもあります。
テーマデザインでいくら頑張っても、コントロールできない部分ができてしまうからです。これでは、テーマデザインの存在意義が希薄になりかねません。これが、ワタシの心配する二重構造です。
こうならないためのルールが確立できればいいとは思いますが・・・果たしてどうでしょうか。
どのような仕組みとして登場するかが楽しみですね。良くも悪くも・・・。

0829@drupal.orgさんの読み通りなら、現行の仕組みがファイルとして抽出されるだけになりそうですがね・・・。
xoopsのような事態にならなければ取り越し苦労と言うことで。

スミマセン、あっち書いては、こっちに付け足して・・・って書いたので、文脈、かなり変です(^_^;)

いえいえ。

いえいえ、大丈夫だと思いますよ。言わんとすることは伝わっていると...

フレームワークが意義を成すのはガイドラインがしっかりしているからこそ、という面は大いにあると思いますから、モジュールの開発者の個性が表に出すぎてしまうとなると大変かも…というのは確かに納得です。
まぁでも、自分の個性と合致しない部分があれば、自分で改変して楽しむということができるのもオープンソースの醍醐味だということで。

コメントの表示オプション

お好みの表示方法を選択し、「設定の保存」をクリックすると、表示方法を変更することができます。