SKYNETs_EYE

先日来の不可解な仕様にかなり頭に来て、もう放り投げたい気分になったのだが、せっかくここまで時間をかけてectoとの同期も可能になったのだからもう少し落ち着いて付き合ってみようと、まずは外見のテンプレート関連をいじってみた。

ブログ形式の時系列と差別化したいので標準の日付時間が大きく表示してあるテンプレートはどうしても替えたい。
XOOPSのテンプレートマネージャーを見てみると
xoops/modules/wordpress/templete/blocks/wp_block_contents.html
というファイルを参照しているらしい。

で、このファイルを直接エディタで編集して再度アップする。
モジュールマネージャーから編集したファイルの入っているwordpressモジュールのアップデート。
再度テンプレートマネージャーからこの参照すると、編集後のものが表示される。
よしよしと思って実際にコンテンツを表示させると、反映されていない。
もちろんキャッシュも削除した上である。

これはアップデートでなくてモジュールの再インストールしないといけないのかなぁ
とやや面倒ながら実行してみる。
すでに4つほどエントリを入れてあるがそれはアンインストール後に再インストールした後も反映されると聞いた。
そりゃそうだろうなぁ4つでも面倒なのにこのさき数百というコンテンツを加えた場合、気分転換にテンプレートをいじる度に再び掲載作業をしていたのではラチがあかない。

で、前エントリの手順でアクティブチェックボックスを外して「送信」ボタン。
しかしこれではまだアンインストールされていない更にモジュールマネジャーの横に現れたアンインストールボタンを押す。

これでようやくアンインストールがなされた。
で、一番下にインストール待ちのモジュールとして再度表示される。

これをインストールしたのだが、驚いたことに中のコンテンツは吹っ飛んで初期化されている。
しかも書き換えたテンプレートは書き換わっていないままの状態で表示される。

なんだか、やって欲しいことをなかなかやってくれないのに、余計なことばかりやる仕事の出来ない手合いを相手にしているみたいで真剣に頭が痛くなってきた。

もしかしたら、XOOPSではなく、このモジュールがタコなのかもしれない、しかしそんなことはもうどうでも良い。
こういう多参加型の開発では元を作るところとモジュールを作る個人のボランティアの技術的格差が大きいので不具合が出ても果たしてどちらに問題があるのかなどは切り分けが難しい。

ちょうどDOS/V機のように複数の開発元の寄せ集め+OSの開発元という責任のたらい回しのような感覚に似ていて、それに付き合わされるユーザの方が哀れである。
なのでXOOPSは私の感覚だと嫌いなWindowsの印象がある。

まだMovableTypeの方ならば一応企業向けのパッケージとして売り出されていて、殆どの機能も単体でまかなえて開発元も一つである。
こちらは感覚で言えばAppleっぽくて好印象である。

MTにも拡張機能など一部ボランティアの手によるものもあるがそんな物を使わなくても基本の機能だけでectoとの更新も出来る。

よくよく調べてみればカテゴリの階層分けも可能らしい。

先日は一時的な感情だけでXOOPSを辞めたくなったが、今回はだいぶ冷静に見て辞めたくなった。
たとえ世間で高評価でも(ゲイツOSがそうであるように)私自身が馴染まないものを無理して我慢して使うことはないのではないかと言うのが結論である。

どうもXOOPSの当たり前の仕様というものに私自身はなじめない。
MovableTypeではなかった違和感のようなものがしばしば感じれる。
これが慣れによるものかどうかは分からない。
しかし、未だにFlashの変態的な仕様を嫌ってFlashでは描画しない出来ないしたくないのと同質のにほいを感じる。

先日のエントリに書いたモジュールのアンインストールについて違和感を覚えたように
今回のテンプレートの変更と反映に対する仕様にも首をかしげざる終えない。

XOOPSの管理画面テンプレートマネージャーで一括して表示するのだが、まずここの仕様が何とも不可解だ。
追加したモジュールのテンプレートもこの一覧に自動的に追加されるのでその中身を見ようと「一覧」というボタンを押してみる。

画面が切り替わり、そのモジュールが使用しているテンプレートのリストが表示される。
アクションの項目から「参照」というボタンを押すとテンプレートソースが表示される。

テンプレートセット・マネジャー ?? default ?? テンプレートファイルの編集

とあるから当然ここで編集できると思い、修正して、確定しようとするとボタンは「参照」のただ一つ。
普通、編集したものを用いたい場合は「反映」というボタンになるはずなのに、そこには「参照」しかない。
そもそも「参照」という行為は今現在しているじゃないか!参照している最中にさらに「参照」とはこれ如何に?

で、しかたなくこの「参照」というボタンを押すと画面ではあたかも更新しているような様子。
なんだぁ「参照」ボタンって書いてあるけど更新してくれるんだね。
と安心したのもつかの間、ページに戻ってみると何故か反映されていない。

おかしいなぁ編集したはずなのになぁと思ってテンプレートマネージャー画面に戻りソースを見ると反映前である。
結局、編集が反映されていなかったのね・・・

で、確実な方法でそこに表示されたファイル名から該当ファイルを直接開き、編集して再度アップした。
これで大丈夫かと思ったが、何故かこれでも反映されない。

あとで友人に相談して解ったことだが、モジュールのテンプレートはモジュールを再インストールしないと反映されないらしい。
もしかしたらアップデートボタンがあるのでそれで反映されるかもという話だったが、実際にやってみて反映されない。
もちろん一般設定でテンプレートを自動反映に設定してある。

やはりモジュールを一度アンインストールして再度インストールし無いとダメですか・・・そうですか・・・

なんかもぉこれ以上付き合うのはムリポ。
お互い住むべき世界が違う気がする。
いくら、世間で評判が良くても、こういうフィーリングの点で違和感を覚えるようでは我慢も限界になりそう。

違和感がこれで終わればよいだがこれ以上意外なサプライズなんかに感心できるほどの心のゆとりもない。

ectoとXOOPSのBlogモジュールのWordPressが無事に同期が取れるようになって、いよいよ箱物を作り始めようと複数のWordPressをXOOPSにインストールしてみた。
特に変な使い方ではなくて、モジュール付属のReadMeにも

ディレクトリ名には従来のwordpressにくわえてwordpress0~9の10個の計11個のブログを持つ事が出来るようになりました。

とあるから、あらかじめサポートされた使い方なのである。

現在、私のXOOPS環境は標準のモジュール以外はこのWordPressだけである。
別に多機能が売りのXOOPSだからといって色々取り込まなければならないというわけではなく、最低限で間に合うのならそれで十分だと思っている。

特に私の場合はコンテンツの管理をローカルで行いたいという要望があるため、それが可能かどうかがまず判断基準になる。

説明書の通りサーバーの「modules/」デレクトリーに「wordpress_01~05」と複製しながらおいてみた。
最終的に11までという二桁になるのだから、どうせならソートで綺麗に見られるように00という二桁で記述したのだが、これは失敗だった。
やはり、開発元が指定するように「wordpress0~5」というようにフォルダ名は固定らしい。

フォルダ名を指定の物に替えると、やっとXOOPS管理画面のモジュール管理画面で複数のwordpressが表示されるようになる。
これを一つ一つインストールすればOKである。

なにも複数入れなくても、カテゴリに階層が設けられるのでそれで管理すればとは思うかもしれないが、今後、細かく分けるためにも大まかなカテゴリ分けを複数のブログシステムで分担した方が後々の管理もしやすいと判断した。

複数のWordPressをインストールするまではうまくいったのだが
今度はectoとの更新がうまくいかなくなってしまった。

一番最初に成功したWordPressの方は今でも無事に同期が出来るのだが
うまくいった方を参考に設定しているのだがフォルダ名を替えた「wordpress0~5」の方はダメである。
もちろん、パスが変わるので

うまくいった方の http://t.y-sky.net/modules/wordpress/xmlrpc.php
から http://t.y-sky.net/modules/wordpress0/xmlrpc.php

にはしている。

あとは wp-config.php や wp-settings.php の内容にパスが書かれた物があるので

if( ! preg_match( '/wordpress(\d*)/' , $wp_dir , $regs ) ) echo ( "invalid dirname of WordPr
ess: " . htmlspecialchars( $mydirname ) ) ;

require(XOOPS_ROOT_PATH.'/modules/wordpress'.(($wp_id=='-') ?'':$wp_id).'/wp-settings.php');
if (!strstr($_SERVER['REQUEST_URI'], 'install.php')) {
$siteurl = XOOPS_URL.'/modules/wordpress'.(($wp_id=='-')?'':$wp_id);

この箇所のパス指定を変更後の物に替えてみたが、これでもダメである。
う~ん、確かにXOOPS上では複数のインストールも運用も可能である。
WordPress単体とectoの同期もサポートされたとおり上手くいく。

しかし複数のWordPressとectoの同期は未知の領域でどこにもヒントが無く、今のところ手探りで実験を繰り返しているところである。

ようやくXOOPSのブログモジュール「WordPress ME Xoops Module」への投稿・エントリ管理をectoから出来るようになった。

キーはWordPress MEではモジュールとして組み込んだだけで、XOOPSからの投稿は可能である。
これに騙され、動作していると勘違いしてついつい「wp-config.php」の中の設定を忘れていた。
エディタで以下の箇所を自分のデータベース設定に書き直す。

// ** MySQL settings ** //
if (!defined('WP_DB_NAME')) {
define('WP_DB_NAME', XOOPS_DB_NAME); // データベース名
define('WP_DB_USER', XOOPS_DB_USER); // データベースのユーザー名
define('WP_DB_PASSWORD', XOOPS_DB_PASS); // データベースパスワード
define('WP_DB_HOST', XOOPS_DB_HOST); // 99% このままでOK
}

これだけでectoから「再読み込み」ボタンを押すとXOOPS上で投稿したエントリも引っ張ってきてくれる。
やっとここまで行った。
しかし、投稿の動作がちょっと遅いし、不安定である。
以前にMTとectoを使い始めた頃の症状とよく似ている。
以前のエントリを参考に詰めてゆきたい。

なんにせよやっとコンテンツの同期が出来るようになった。

追記:
ectoのアカウント設定でAPIをMovableTypeに設定してみた。
この設定で「WordPress ME Xoops Module」側のカテゴリも持ってこれるようになり、MovableTypeサイトと全く遜色なく使うようになった。

やはりMovableTypeのAPIとの相性が良いようだ。

ectoのアカウント管理からWordPressの設定を終わり、エラーを表示されずに通信が無事終わるようにはなった。
ただ、MovableTypeとの通信の時にはウェブリストやカテゴリを確認しているのが作業ログで確認できるが、WordPressの方は何もしていないようだ。

XOOPSサイトから投稿は反映されるのでちゃんと動作はしているらしい。
あとはectoとのコンテンツの同期である。
パーミッションの設定かと思って色々設定を変えてみているがうまくいかない。
phpの場合はcgiと違い、開発元が指定するパーミッション設定をするらしいが、WordPress ME Xoops Moduleの設定が記述されているところはない。

ectoにこだわらなくてもメールソフトから投稿でエントリの管理は可能だ。
ただ、複数のブログエントリ管理となるとメールソフトでは煩雑になる可能性がある。

まずは基本のXOOPSコンテンツのスムーズな管理環境に集中するためここしばらくはモジュールをWordPress ME Xoops Moduleだけに絞ることにする。

追記:
う~ん設定をいじっても出来ないが、このモジュールの説明ページでectoはしっかりとサポートされている。
XML-RPC インターフェイス

Ecto, BlogBuddy, Bloggar, WapBlogger (ワイヤレスアプリケーション携帯端末からの投稿用), Radio Userland (Radio's email-to-blog の投稿機能の利用), Zempt, NewzCrawler 等、Blogging API をサポートしているツールから WordPress へ投稿することができます。

ただ、APIの指定がBloggingというのが見つからない。
Bloggerならあるのだがこれでは繋がらない。

仕方がないのでectoの開発元で調べてみた。

Making ecto work with Runcms/E-Xoops

Last week I spend some time helping a customer with her Mac version of ecto. The customer in question wanted ecto to work with Runcms, a content-management system not very unlike Drupal. The problem was that Runcms has an XML-RPC implementation that doesn't follow specifications and had some odd bugs. First, I made a few changes in ecto to be more happy when an XML-RPC implementation is sending integers instead of strings (available as latest build). Then, I had to patch up Runcms' implementation of the Blogger API. I already made one concession a while ago, passing titles as embedded tags in the main body to Blogger API-only weblogs (LiveJournal, for example). But Runcms also uses embedded “hometext" and “moretext" tags. This is where I drew my line, it shouldn't get more crazy than that. However, if ecto only provides an embedded title tag with the rest of the body, the whole contents would be used as the main text of the entry. In addition, it was impossible to post entries to a blog that has an ID of 0 as it would trigger an error message.

If you use Runcms and you want to have ecto support, please install the patch I wrote. Download and unpack runcms-patch.zip. There are three files which have to be installed in designated locations of your Runcms installation directory (overwriting the existing ones, but make sure to back up those original files):

rpc_functions.php goes in modules/phpRPC/include/
editPost.php goes in modules/phpRPC/library/exoops/blogger/
newPost.php goes in modules/phpRPC/library/exoops/blogger/

Then, in ecto you can set up an account for your Runcms blogs, using Blogger as the API and something like http://YOURSITE.COM/PATH-TO/runcms/modules/phpRPC/server.php as the access point.

なんだかこのパッチがキーになりそうだ。

モジュールによっては、設定しただけで不具合が出てしまうものもある。
別にバグというわけではなくて、サーバーに置いたファイルのパーミッションが違っていたりすると発生するらしい。

XOOPSの説明サイトは多数あれども、逆に基本的なことが説明されたサイトは意外にもない。
たとえばインストールしたモジュールをアンインストールするときは?など
普通に管理画面を見て操作方法が想像できる場合は別にマニュアルなどはいらないだろう。
そんな解りきったことをいちいち文章化する手間暇がもったいないと私自身も思うだろう。

ところがXOOPSのモジュールのアンインストールの方法は教わらなければ管理画面を見てちょっと想像できるものではない。
インストールされたモジュールは上の方にエントリされるのだが普通なら横にアンインストールボタンが付いてしかるべきである。

で、アンインストールボタンの代わりにどんな方法を用いるかというとなんと「アクティブ」と書かれたチェックボックスを外して
下の「送信」ボタンを押すのである。

チェックボックスとは一時的に切り替える時に使うインターフェイスである。
テストなどで他のモジュールと競合する可能性がある場合などで原因の切り分けに、「一時的に」機能を切る場合とかに用いられるものであろう。

XOOPSユーザは長らくこの方法になれてしまって不自然に感じないのだろうけど、こういうインターフェイスを放置しておけるセンスにはちょっと首をかしげたくなる。

WPモジュールを入れた後に管理画面に入れなくなり、モジュールの設定はおろか削除などの管理も出来なくなってしまった。
そこで、MysqlとFTPクライアントから問題のモジュールファイルを削除してしまったが、これは間違った方法だったらしい。

ここからまた切り分けてゆくのも面倒なので、XOOPSを再度フルインストールし直すことにする。
思えば既に4回くらいフルインストールをしている。
ちょうど先月の暮れにマイナーバージョンが上がってxoops-2.0.16-JPになったのでちょうど良かった。
素朴な疑問なのだがコンテンツを大量にエントリして運営しているXOOPSサイトなんかはこういうこまめなバージョンアップの時はどうしているのだろうか?
パッチで該当ファイルだけ自動で上書きしてくれるなら良いのだが、どうも差分の説明もないしたぶんコンテンツだけ待避させてXOOPS本体ごとフルインストールし直しなのではないかと思う。。
なんせ、その辺の基本的なことが書かれた物がないから本当に手探りでやってゆくしかない。

あぁ、安定して運営という本当に基本的なことが出来るまで、こんなに面倒なもので良いのだろうか?

ここのところ全く手つかずだったXOOPSサイト。
夢や理想は膨らむのだが、どうにも面倒くさがり屋で箱物を作ったあとのコンテンツの移行とそれからの管理を考えるとげんなりしてしまう。
人間、慣れとは恐ろしいもので、半年前までBlogの投稿や管理をiBlogで行っていたのがより手軽なecto+MovableTypeで行うようになって全ての基準かこれになってしまった。
だから、XOOPSでWebブラウザのフォームからエントリを書き込んで反映なんて堅苦しい手順は想像しただけで萎えてしまうのである。

かといって、Blogは時系列で後で詳細に内容を分析しようとするときに、手助けになるのがカテゴリと検索のみである。
まぁカテゴリがあればざっくりとした分類が可能なのだがコンテンツが増えるに従ってカテゴリの項目が増えたりだんだん複雑化してゆく。
これはひとえにカテゴリの階層化が出来ない(もしかしたらMovableTypeでも出来るのかもしれないが)事によるものだと思う。
たとえばこのエントリなんかでもBlogというカテゴリにも当てはまるしInternetでも当てはまる。 中にはectoも扱っているからMacOSXにも引っかかる。
これらを複数チェックしていくつかのカテゴリにまたがる設定をすることも可能だがやはり階層化した方がずっと理解も管理もしやすい。
Internet/Blog/ecto みたいな。
ectoにチェックを入れると自動的に上の階層のBlog・Internetにもチェックが入るような管理が望ましい。

XOOPSならば自由度が高いので時系列をあまり意識させないようなコンテンツ管理が可能だろう。
なんとか、コンテンツの投稿や管理をecto+MovableType並に簡略化できないものか、色々と調べてみた。

ectoがサポートするBogシステムはMovableTypeだけではない。
そこでXOOPSのBlogモジュールの中からectoがサポートしているものを探してみた。
WordPress というものがそうらしい。
そこでWordPress の日本語版 WordPress ME のXOOPSモジュール化した、WordPress ME Xoops Moduleを使用してみることにした。
サーバーにモジュールをインストール後

ectoのアカウントマネージャーで新規アカウントを追加する。

ウェブログのURL入力欄にXoopsサイトを記述。 次へ ボタン。

システムの選択一覧からWordPressを選択。
API:に何を選択して良いか解らないからとりあえずMTで。

追記:ここはAtomで接続を確認。

アクセスポイントにhttp://yourURL/modules/wordpress/xmlrpc.php
とxmlrpc.phpが設置してある場所までのパスを記述。

今日はここまで
XOOPS側でのモジュール設定がまだ全然なされていないので、まだ投稿は出来ないが、何となく希望のようななものは見えてきた。
ブログでも何でも良いから一度XOOPSに取り込まれれば後はモジュールの間でコンテンツのやり取りは出来るのではないかと思う。
なのでXOOPSのシステムとローカルとでコンテンツの同期が容易に出来ることがまずは第一目標なのである。

仕事上でどうしても参加型ポータルサイトの構築をしなければならなくなり、急遽「XOOPS」を学習し始める。
こういうう、ポータルシステムは「コンテンツマネジメントシステム(CMS)」とも呼ばれているが、どうもデザイン面で似通った作りの物が多く、魅力的に映らなくてイマイチ触手が伸びなかった
だいたい参加型コミュニティサイトってあまり好きじゃないんだよなぁ。
機能的にはさすがにそれ向けに作られたパッケージとモジュールなので組み込み構築は楽であろう。公式サイトからモジュールの種類を探すとかなりの量がヒットして何も目的を持たずに見ているだけだと途方に暮れる。
やはり、サイトで何をしたいか(掲示板やセキュリティや認証システム等々)そこから目的のモジュールを探していった方が早そうだ。外見にはテンプレートが配布されており、それを元にカスタマイズしてゆくことになりそうだ。
ただ、カスタマイズにはHTMLとスタイルシートの内容を理解し修正する必要がある。
スタイルシート自体はあまり詳しくないし、HTMLと微妙に記述が違ったり、また数種類の書き方があったり、混乱を招きやすい。
どうせならHTMLと同じ記述にしていくれたほうがもっと解りやすかったのに・・・。

テンプレートのカスタマイズにはローカルでPHPやMySQLの使える環境にXOOPSをインストールすることで確認作業が楽になるらしい。
幸い、運の良いことに先日に新しいMAMP が発表されてそこには標準でXOOPSが入っていた。
これで、ローカルでの確認環境は楽に構築できた。