XOOPS Cube Legacy 2.1.0 リリース 55
ストーリー by mhatta
CMSのダークホースとなるか 部門より
CMSのダークホースとなるか 部門より
nobuhiro 曰く、
XOOPS 2.0 と互換性を持った XOOPS Cube Legacy 2.1 が、長い開発期間を経て 4/30に正式リリースされた。XOOPS は、PHP で作成された人気の高いコンテンツ管理システム (CMS) だが、XOOPS Cube は全く新たに書き直された基本システムであり BSDライセンスで提供されている。 従来の XOOPS との互換性は Legacy モジュール (GPL) によって提供され、数多く配布されているサードパーティ製のモジュールがそのまま利用できる。
小さいコア + 互換モジュールと言う柔軟な構成にすることで、従来固定されていたシステムの振舞いまで追加プログラムでのカスタマイズが可能となった。全く別のシステムモジュールの開発など、今後の展開が楽しみである。また、コードのローディング手順が改められ動作速度も向上しているようだ。 互換性などまだ完全ではないとのことだが、問題点の報告によって改善していく予定らしい。実用に使って、不具合を見つけたら報告しよう。
Wiki+Blog+BBS対CMS (スコア:2, すばらしい洞察)
だから、この手の統合CMSシステムがライトユーザーに使われるような場面ってほとんど残っていないと思うのですよね。むしろ、100倍簡単な無料サービスのmashupの方が個別の機能がしっかりしていて、安定してコンテンツを提供できてしまう。
で、ほんとに寄せ集めじゃ困るような本格的な用途のために自分でサーバー立てるとなると、今度はXOOPSみたいな中途半端なシステムじゃ使いものになりません。管理機能も貧弱だし、パフォーマンスも悪いし、相当頑張らないと「XOOPSっぽい」サイトしか作れない。どうせ頑張るなら、結局TYPO3みたいなより高性能なものを選ぶことになってしまいます。
今後も続けていくつもりなら、XOOPSの中の人は方向性を真剣に考えた方がいいと思います。「気軽にインストールできるCMS」じゃ生き残れない時代。
個人ならそれでもよいけど (スコア:2, 興味深い)
お金も人材もいない教育機関(大学の専攻や学科レベルの部署、高校、中学校、小学校、幼稚園、保育園など)、NPO法人やその他の組織にとっては、無料のBlogやWebサービスは責任の所在がはっきりしなくなるので使いづらいのです。責任の所在をはっきりとさせるためには、業者に発注するのが一番良いのですが、お金がないからそれはできない。すると、レンタルサーバを借りてサイトを構築するか、自前でサーバを立てるかという選択肢しかなくなります。担当者はちょっとパソコンに詳しいくらいの素人で、試行錯誤しつつサイトを構築することになります。
こういう状況においては、簡単にインストールできてCMSが構築できるというのは大きなメリットです。特に日本語ドキュメントが多いことは魅力です。ですので、
が事実だといたしましても(実際に事実ですが)、ライトユーザがフリーのCMSを使うという場面はまだまだ存在していると思います。四十九次
つまり (スコア:2, おもしろおかしい)
お金の無い組織のちょっとパソコンに詳しい素人の恨み節がふんだんに含まれているから
ということでよろしいか?
#XOOPS Cubeはマルチバイトに優しいところが好きです。
Re:個人ならそれでもよいけど (スコア:0)
#会社のが廃墟状態なのでAC
Re:個人ならそれでもよいけど (スコア:0)
特に大人数で一つのサイトを構築している場合は、それがCMSと呼ばれなくても、
何らかの仕組み(デジタル、アナログ問わず)が必須になるでしょう。
逆に、「CMSを使っているけど一貫したワークフローが無い」という場合、悲惨な事になると思います。
Re:個人ならそれでもよいけど (スコア:0)
そのようなケースはほとんど無いと思います。
むしろ、そりゅーしょん屋としてはサイト更新の口を絞る運用を提案しますね。
Re:個人ならそれでもよいけど (スコア:0)
自分でサーバ:責任は100%自分がかぶってしまう
責任の所在がはっきりしないサービスプロバイダ:責任は100%自分がかぶらずにすむ可能性もある
ということで、無料のプロバイダの方がましな気がするのは、志向がネガティブ?
Re:個人ならそれでもよいけど (スコア:0)
よくわからないならやらないほうがいい。 周りに迷惑かけるんだから。
ちょっと詳しいくらいの人が一番厄介なんだよな。 知識が中途半端で。
だからこそ、そこそこ安全なCMSが欲しいのです (スコア:1)
おっしゃるとおり。なので、素人としてはマニュアルどおりインストールすればそこそこ堅牢なものが欲しいのです。ポイントは素人が工夫しなくてもよい点。最新版がリリースされたら、簡単に置き換えられたらなお良し。
残念ながら、いろいろな事情によりやらないという選択肢はなく、やる場合に運用コストが比較的低いかつ問題が起こる可能性が比較的低い(と素人目に見える)かどうかなんです。
四十九次
Re:だからこそ、そこそこ安全なCMSが欲しいのです (スコア:1)
これは思いますね。新しい products を試すたびに堅牢なインストール方法を考えながらとか面倒すぎますもの。
でもまあ、堅牢にするための手法がサーバーによって使えたり使えなかったりすると、どうしてもどこでも動作するようなインストール方法が紹介されてしまいますね。
Re:Wiki+Blog+BBS対CMS (スコア:2, 参考になる)
>安定してコンテンツを提供できてしまう。
そんなにすごいなら例をあげてみてもらえます?
本当なら移行を検討しますよ。
個別の無料サービスの寄せ集めだと、細かい部分の使い勝手が
違うとか、シームレスなアカウント処理ができないとか
一括管理ができないとか、いろいろ問題点はあるから
CMSがでてきたんだと思いますけど。
Re:Wiki+Blog+BBS対CMS (スコア:0)
生き残らなくてはいけない理由もよくわかりませんが…
新しい方向性の代替案くらい出して欲しいものです。
Re:Wiki+Blog+BBS対CMS (スコア:0)
「今後も続けていくつもりなら」って条件が付いてるでしょ。
理由がよくわからないんならこの条件に当てはまらないんじゃないですか?
> 新しい方向性の代替案くらい出して欲しいものです。
こっちが生き残って欲しいと思ってるわけでもないのに代替案出せとはこれいかに?
それに「生き残らなくてはいけない理由もよくわかりません」なあなたが方向性の代替案が欲しいという理由がよくわかりません。
Re:Wiki+Blog+BBS対CMS (スコア:0)
> 理由がよくわからないんならこの条件に当てはまらないんじゃないですか?
当てはまるか当てはまらないかは、開発者にしかわかりませんし、開発者も複数いれば、総意があるとも思えません。
そもそも、なぜ外野のあなたが考えた方が良いという提案をするかがわからないです。
余計なお世話ですし、そもそも書く必要がないですよね?
>こっちが生き残って欲しいと思ってるわけでもないのに代替案出せとはこれいかに?
であればなおさら、はじめからそんなこと書かないでいいですよね。
なぜ生き残って欲しいと思っていないソフトウェアに未来に関する提案をしたのですか?
>それに「生き残らなくてはいけない理由もよくわかりません」なあなたが方向性の代替案が欲しいという理由がよくわかりません。
代替案が欲しいと言っているわけではありません。
あなたが何かを主張するのであれば、代替案くらい出して主張しろと言っているだけです。
Re:Wiki+Blog+BBS対CMS (スコア:0)
今のままで (スコア:0)
個別のWiki+Blog+BBSを一元的に管理するのはメンドーって思うのが一般的だから生き残ってる。
単機能CMSでは満足出来ないが大規模なシステムは管理出来ない、中途半端なニーズが多いから生き残ってる。
なので、今後もこの方向で宜しく。
リッチ側に進まれてもプア側に進まれても現状のニーズからは外れてしまいます。
そんなもんは今現在リッチを目指しているCMSやプアを目指しているCMSに任せればよいのです。
中途半端な位置で支持されているCMSは、今の中途半端なスタンスを守って下さい。
# 人類の大多数は「シェア取れなきゃ負け」ではない世界に生きてる。
Xoops使ってます (スコア:2, 興味深い)
今のところ不具合ありません。
インストールして最初は、メインメニューとユーザーメニューが2つずつ出てきたので、不具合かとあわてましたが、互換モジュールと新しいモジュールの両方が動いていたせいでした。
互換モジュールのメニューを外すと治りました。
モジュールはPico、Waffle、PowerDL List、CCLinks、Sitemap、BM-Surveyなど利用しています。
Xoopsのニッチは確実に存在すると思います。
ある程度動的なホームページを業者に注文すると結構いい金額がかかります。
メンテナンスのたびに費用がかさみます。
うちの会社はネット上でカタログ的な情報を流して、注文は直接電話で受け付けているので、Webショップのような大掛かりなシステムは要りませんが、情報の更新は欠かせません。
基本的に従来の顧客とは電話やFaxでやり取りするので、Webの重要度もそんなに高くありません。
また、顧客によってアクセスできる情報を管理する必要があります。
製品ごとに問い合わせフォームも必要ですし、各ページのレイアウトや、リンク情報、更新情報の整合性もとる必要があります。
各商品の更新は各担当者が行うので、情報の更新できる権限の管理も必要です。
こういったニーズに結構マッチしているので、うちではXoopsを利用しています。
また、個人のページもXoopsで作成しています。
個人ページでもいろいろやりたい私にとっては、Blogは楽だけど構成の自由度が低いし個性が出しづらい、Wikiだとレイアウトに凝れない、かといってHTMLを一から書くと各ページごとの統一をとるのが大変。
といった理由で、3年ほど前からXoopsで個人ページも運用しています。
Xoopsのような非商用のシステムは、シェアの獲得よりは既存ユーザーのニーズにいかにマッチできるかが存続価値でないかと、個人的に考えています。
Re:Xoops使ってます (スコア:1)
というか教えてください。
このページは良いXOOPS(を使った)のページだ!というような具体例があったらリンクして欲しいです。
ThinkPadClubがXOOPSに移行して、
メニュー構成があまり気に入ってなくて、
個人的には、昔の構成で良かったんじゃないか?と思ってるんですよ。
# ユーザごとに「ここまで読んだ」が保存されるのは良いんですけど。
# あと、CPUパワー(DBパワー?)が結構必要な印象。
XOOPSとはあんなものなのか?と思っていて、今は高い評価じゃないので
「こういう用途にはXOOPS便利だぜ!」という具体的な例が見たいです。
# XOOPSでぐぐったら、作り方のページばっかりHitしてしまう。
Re:Xoops使ってます (スコア:1)
http://xoopscube.jp/modules/mylinks/viewcat.php?cid=1 [xoopscube.jp]
私のページがデザインいいですよ・・と言いたいところなのですが、出自がばれてしまうので秘密です。
Xoopsって標準のフォーラムや掲示板のデザインが悪いんですよね。
私は使いやすいモジュールを探してきて対応しています。
公式サイトのリンクで、結構よさそうなデザインのサイトをピックアップしてみました。
福島ラーメン会議 http://www.aizu.net/frm/ [aizu.net]
@Yaimaコミュニティ http://www.at-yaima.com/ [at-yaima.com]
すぎなびネット http://www.suginavi.net/ [suginavi.net]
桜ヶ丘病院 http://www.sakuragaoka-hp.jp/ [sakuragaoka-hp.jp]
NGO Network Japan http://www.ngo.ne.jp/ [ngo.ne.jp]
アースデイとやま http://earthday-toyama.org/ [earthday-toyama.org]
Re:Xoops使ってます (スコア:1)
わざわざ、ピックアップまでしてもらってありがとうございます。
ざっくりとネットで調べてみたんですけど
>標準のフォーラムや掲示板のデザインが悪い
こういう意見多いですね。
# 自分のホームページは(自分ひとりしか書き込まないから)wiki使ってるんですけど。
個人、小規模コミュニティには大げさな気がする (スコア:1)
#つくば市のサイトがXOOPSなのにはちょっと驚いた。
妖精哲学の三信
「だらしねぇ」という戒めの心、「歪みねぇ」という賛美の心、「仕方ない」という許容の心
Re:個人、小規模コミュニティには大げさな気がする (スコア:2, 参考になる)
去年のOSCでユーザ会の人が資料を配布していました。
Your 金銭的 potential. Our passion - Micro$oft
Tsukitomo(月友)
Re:個人、小規模コミュニティには大げさな気がする (スコア:0)
なので、中規模以上の場所でもかなり使われていますよ。
企業や、地方自治体や政治家のサイトでもかなり採用事例がありますし、XOOPSを扱ったWeb製作会社もかなりあります。
googleで検索してみればわかるかと。
正直、先行き不安 (スコア:1, 興味深い)
果たしてCubeもいつまで続くやらと不安になってしまう。
XOOPSが普及しない理由 (スコア:1, すばらしい洞察)
オープンソースとかを勘違いしまくってる上に
Linuxがなぜ普及したかを理解していないから
一般ユーザをどんどん排除して行ってしまう。
また、小規模サイトならWikiを流用した方が手軽だし
中規模以上なら OpenPNEの使い方を工夫すればいいので
XOOPSでないとこの機能が使えないって人じゃない限り
XOOPSを選択する理由は無い上に、そのXOOPSにしか無い
機能を使えるようになるまでが、非常に時間がかかる。
ま、そんなとこかな?
Re:宣伝乙 (スコア:1, 参考になる)
・なぜ普及していないということを前提としているのか?
・そもそもなぜCMSとSNS構築システムという目的の違う物を比べてるのか?
という疑問があります。
そんなに宣伝したいのですかね?
Re:XOOPSが普及しない理由 (スコア:1, すばらしい洞察)
>また、小規模サイトならWikiを流用した方が手軽だし
どのような小規模サイトを想定しているのかが不明なので、反論もしようがないのですが…
XOOPSとwikiと比べる意味がさっぱりわからないです。
wikiでは、ユーザ登録も、ユーザによるコンテンツの管理も、お問合せも、既存HTMLの利用も、段組等を利用したデザインもできないです。
>中規模以上なら OpenPNEの使い方を工夫すればいいので
これも想定している中規模がさっぱりわかりませんが…
OpenPNEでは、できないことばかりです。
ユーザのグループ管理。コンテンツの管理、デザインの自由度などなど…
そもそもSNSを一般Webサイトとして工夫して利用しようとする意味がわかりません。
>XOOPSでないとこの機能が使えないって人じゃない限り
>XOOPSを選択する理由は無い上に、
この機能が使えないからXOOPSを使う。立派な理由かと。
>そのXOOPSにしか無い
>機能を使えるようになるまでが、非常に時間がかかる。
そのような時間がかかる機能を一つも知りませんが、どの機能を言っているのでしょうか?
Re:XOOPSが普及しない理由 (スコア:1)
>wikiでは、ユーザ登録も、ユーザによるコンテンツの管理も、お問合せも、既存HTMLの利用も、段組等を利用したデザインもできないです。
この程度は Wiki でも出来るよ。
XOOPS のメリットを否定するわけではないですが。
Re:XOOPSが普及しない理由 (スコア:0)
互いにAC同士なんだからさ。
Re:XOOPSが普及しない理由 (スコア:0)
>互いにAC同士なんだからさ。
コレは全くその通り。ACは全員同じ人の書き込みなんだから。
# と思って眺めると、働き者だしころころ意見は変わるし自演だらけで可愛いヤツです
# と、自演してみました
Re:XOOPSが普及しない理由 (スコア:1)
Re:XOOPSが普及しない理由 (スコア:0)
Re:XOOPSが普及しない理由 (スコア:0)
どっちが知名度高いのか悩んだのでGoogle様にお伺いを立ててみる。
OpenPNE の検索結果 約 1,390,000 件中 1 - 50 件目 (0.21 秒)
XOOPS Cube の検索結果 約 1,280,000 件中 1 - 50 件目 (0.13 秒)
XOOPS の検索結果 約 30,200,000 件中 1 - 50 件目 (0.07 秒)
XOOPS の検索結果のうち 日本語のページ 約 2,190,000 件中 1 - 50 件目 (0.10 秒)
OpenPNE の検索結果のうち 日本語のページ 約 1,240,000 件中 1 - 50 件目 (0.05 秒)
日本国内じゃ段違いという程でもないような?
# XOOPSは語感がXOOMとかZOPEとかと混ざってよくない・・
Re:XOOPSが普及しない理由 (スコア:3, 興味深い)
段違いですな.
実際のユーザ数はわからんけど.
Re:XOOPSが普及しない理由 (スコア:1, 興味深い)
偶然とはいえ、こう見ると、なんか関連性があるようにしか見えないな。
http://www.google.com/trends?q=xoops,+slashdot,+phpbb,+wordpress [google.com]
やっぱ、ブログは強いんだなぁ、と。
Re:XOOPSが普及しない理由 (スコア:0)
Googleの検索結果になにか意味を持たせようとする間抜けさ
を捨ててきなさい。
オープンソースは普及しなくてはいけないの? (スコア:1, 興味深い)
「こうしなくちゃ普及しない。」「これじゃダメだ。」
というのは、どこから来る発想なのでしょうか?
全ての開発者が、普及することを望んでいると思っているのでしょうか?
特にXOOPS Cubeに関しては、普及しなくちゃいけないと言う考えでやっていないと思いますけど。
Re:オープンソースは普及しなくてはいけないの? (スコア:0)
続けていくことが大事だと思います。頑張ってください>中の人
Re:オープンソースは普及しなくてはいけないの? (スコア:0)
自分からXOOPS Cubeのコミュニティに突撃して同じようなことを言う人がいたらどうかしてると思うけど、今回のようにSlashdot-Jのトップページに宣伝記事が掲載されて「実用に使って、不具合を見つけたら報告しよう」まで書かれてるんだから、否定的なリアクションが来ても仕方ないでしょ。
Re:オープンソースは普及しなくてはいけないの? (スコア:0)
今回のケースではないけど、10年前に触ったきりなのに現在も同じようなものだ、と語るのもあまりよくないです。いつの話か明確にしていただきたいなぁ、と。
Re:オープンソースは普及しなくてはいけないの? (スコア:0)
> 「こうしなくちゃ普及しない。」「これじゃダメだ。」
> というのは、どこから来る発想なのでしょうか?
オープンソース(に類する開発)=趣味や好きという「だけの理由」でやっている というのはちょっと伝統的すぎる見方かとも思います
たとえ 趣味や好き という場合でも 自分の趣味や好きなものの魅力や価値を他の人に積極的に伝えたい という態度も珍しいものではないと思います
> 全ての開発者が、普及することを望んでいると思っているのでしょうか?
「全て」の開発者が普及することを望んで「いない」 状態ならば こうしなきゃ普及しない という助言はまとはずれしょう
しかし たとえひとりであっても普及することを望んでいる開発者がいる ならば助言は助言として受け止めてもいいのではないですか?
公式サイトの (スコア:1, 興味深い)
他のCMSだとネット上をさまよって捜さなくてはならなかったりします、
そう言う意味ではBlogのMTもWordpressもプラグインはあるけど
捜すのがめんどくさい。
その点、Nucleusも公式で豊富に紹介されている。
仕事で顧客の要求の機能を捜すときにこの祖ソフトの機能や追加機能の豊富さより
公式の充実度がキーになってくる。
Re:公式サイトの (スコア:0)
>捜すのがめんどくさい。
CMSとBlogをごっちゃにしておりませんか?
そうでない、というなら、必要としている機能をまとめてリストされていると「何が必要とされているのか?」参考になっていいと思います。
個人的なXoopsの感想としては
「設計が汚い」
一旦、現状のXoopsを諦めて、ディレクトリ構成を決める所からフレームワークを明確に決めなおすべきなのではないかと思っています。
(旧遺産が足をひっぱりまくってるけど・・・っつか、そこまでするなら「Xoops」である必要ないのか。ってか、オレは別のCMSを使って・・・)
Re:公式サイトの (スコア:1)
CMS のコア部分は、過去のしがらみを捨てて、全く新らたに書き起こされたものです。 コア単独では XOOPS と直接の互換性はなく、互換モジュールが従来の XOOPS と同じ API の動きを実現しています。
Mach がマイクロカーネルの OS が、パーソナリティを載せて UNIX と同じ振舞をするようにしたのと同じアプローチですな。
旧資産なんぞ要らん、ってことなら、互換モジュールを取っぱらってコアを直接使うか、別のシステムモジュールを導入すればいいのです。
%% でも、ばりばり OOP で私のような Legacy な奴には読むのが辛いコード orz
の
plone (スコア:0)
Re:plone (スコア:0)
悪口を言って尊敬された人はいない (スコア:0)
自分が気に入らなくて、貢献したくもないなら、黙っていれば良いこと。わざわざ悪口並べる必要なし。
自分が気に入らなくても、貢献したいなら問題点を直接そのプロジェクトのMLなりに投げればよいこと。
もっとすばらしいと思えるCMSがあるなら、そのCMSをもっと素晴らしくすることに協力すべき。
要は建設的な考えで望まないと、単なる悪口だけの人になってしまいますよ。
Re:悪口を言って尊敬された人はいない (スコア:0, 余計なもの)
自分が気に入らなくて、貢献したくもないなら、黙っていれば良いこと。わざわざ悪口並べる必要なし。
自分が気に入らなくても、貢献したいなら問題点を直接そのプロジェクトのMLなりに投げればよいこと。
もっとすばらしいと思えるOSがあるなら、そのOSをもっと素晴らしくすることに協力すべき。
要は建設的な考えで望まないと、単なるMSの悪口だけの人になってしまいますよ。
Re:悪口を言って尊敬された人はいない (スコア:0)
言い換えで反撃しているつもりならせめて話題の流れを守りましょう。
ここは2ちゃんねるではないので。(笑)
Re:悪口を言って尊敬された人はいない (スコア:0)
「これは良いテンプレートですね」
って事じゃないかなぁ…………
# もしかしてネタにマジレス?