月日が経つのは早いものですねぇ。半年ぶりのリリースとなってしまいました。

本当は今年のシーズンが始まる4月までには出したかったのですけど、予想外に(!?)常勤の仕事が決まるなどして、開発する時間が減ってしまいました。

今回のリリースはメジャーバージョンアップです。

今まで1チームしか管理することができなかった自チームを、3チームまで複数チーム管理できるようになりました。

これにより、低学年チーム、高学年チームの両方が存在する少年野球チームや、二軍がある草野球チームなどに対応できますので、利用の幅が広がっていくと思います。

画面操作的にはあまり変わっていませんが、内部のデータ構造は大きく変わっています。

そのため、「今まで問題なく動いていたところが動かなくなった」という不具合がもしかしたらあるかも知れません…

もし問題あれば教えてください。

なお、私としてはなるべくデータベースのバックアップをとってからバージョンアップしていただいた方が安心です。

ダウンロードはダウンロードページからどうぞ

V1.31->V2.00の変更点(2010/06/08)

• [機能追加]V1.31までは自チーム1チーム分しか管理できませんでしたが、V2.00から3チームまで登録できるようになりました。
    これにより小学校高学年チーム、低学年チームなどで分けたり、2軍チームの管理ができます。
• [機能追加]モジュール複製ができるようになりました。モジュールディレクトリ名を変えて複数のWebScoreRevolutionを
    1つのXOOPSサイト内にインストールできます。
• [不具合修正]個人成績画面：規定打席/規定投球回数を超えているにもかかわらず打率グラフと防御率グラフに成績表示
    されない不具合を修正しました。
• [不具合修正]対戦結果詳細画面：PHP5.1.6環境で、投手成績の2人目以降の名前が表示されない不具合を修正しました。
• [不具合修正]「チームの活動予定」ブロックは、本日より未来の予定について表示するのが仕様ですが、
    一部のレンタルサーバーでは過去の日付の予定も表示されてしまっていたのを修正しました。
• [不具合修正]対戦結果登録画面：打撃成績の「打球方向」と「打点」テキストボックスのサイズが大きすぎたので変更しました。
• [不具合修正]対戦結果登録画面：投手成績のtabindexが正しくなかったので修正しました。
• [不具合修正]管理画面：FTP関数が使えない環境向けにエラー処理を追加しました。

デザイナー・デベロッパーのためのGoogle Chromeエクステンション17 | CREAMU

http://blog.creamu.com/mt/2010/02/google_chrome17.html

ここで紹介されているchrome snifferというエクステンションがなかなか便利です。

訪問したサイトがどんなCMSや技術を使っているかを教えてくれます。

こういうの見ていると、「へぇ、WordPressでこんなサイト作れるんだ！」とか新しい発見が合ってなかなか楽しいです。

うちのサイト。XOOPSを使っているのでXOOPSのマークがアドレスバーに表示されます。

WordPressを使っているとき

jQueryを使っているとき(青色の電波のようなマーク)

Google Analyticsを使っているとき

などなど、使っているCMSや要素技術がひと目で分かるようになっています。

ちなみにまだ読んでいませんが、以下のエントリも最近見つけて気になっています。あとでチェックしなきゃ。

SEO解析データ 全部入りChrome拡張機能「SEO Site Tools」 – WEBマーケティング ブログ
http://web-marketing.zako.org/hacks/google-chrome/seo-site-tools.html

無料で使えるSEOやホームページ制作に役立つツールまとめ【パシのSEOブログ】
http://www.jweb-seo.com/blog/wordpress/2010/03/01/752

とあるお客様から、レンタルサーバーのバックアップ(DBとディレクトリ)の要件があったので、サーバー上で動くPerlスクリプトを作って定時にバックアップする仕組みを作りました。

するとホームページ制作「Webの森」さんから「これは他のサイトでも需要があるのではないか」と提案を受けましたので、一般的なサーバー上で動くように、汎用的に使えるパッケージ商品としてリリースすることにしました。

個人で作っているサイトや趣味のサイトでしたら、データを失っても「あーあ、やっちゃった」で終わるかも知れませんが、XOOPSやWordPressなどCMSを使ってそれなりに立派に作っている企業のホームページやブログなどは、データを失ったら計り知れない影響が出ることもあります。

そんな方がたを対象にした、レンタルサーバー上のデータをバックアップしてくれるサービスです。

特徴

・毎日、毎週、毎月など決まった時刻にMySQL DBとディレクトリのバックアップを実行できます。

・バックアップファイルを保存する日数を指定できます。ディスク領域の都合に合わせて設定できます。

・バックアップが終わったらメールでお知らせします。(オプション)

・バックアップファイルは別のサーバーへFTP転送も可能です。(オプション)

気になるお値段は以下のようになっております。

詳しくはWebの森のBK-Blog、BK-CMSまで！

XOOPSで作っている野球チーム「神戸グフ」のホームページ環境を、EUCからUTF8に移行しました。

以前、このtoyao.netもEUCからUTF8環境に移行したことがあったので、その手順をもとに移行しました。

あのときはxpwikiで書いたページがそんなに多くなかったので、xpwikiの移行については文章を手で文字コード変換して新しくページを登録しなおすなどしましたが、今回の野球のホームページはxpwikiで作ったページが大量にあるので、とても手作業で移行できません。

そこでなんとかツールなどを駆使して自動で変換して移行することを試みました。

でも、あまり資料ないですね… 仕方がないので自分で試行錯誤して移行した手順を残しておきます。

xpwiki自体は、EUCにもUTF8にも対応しています。ですので、モジュールの一般設定などの管理項目は、通常のXOOPSのEUC→UTF8移行手順で解決できます。

問題なのはwikiで書かれた各ページの移行です。

• wikiのコンテンツはDBに格納されておらず、ページはファイル単位で管理されているので、
     移行時にはファイルの中身をすべてUTF8に変換する必要がある。
• 上記wiki用のファイルにつけられたファイル名は、EUC文字列をエンコードした記号だらけのファイル名であり、
     このファイル名をUTF8文字列からエンコードしたファイル名に変更しないといけない 。
• ファイル名はxpwikiのテーブルにて管理されているので、テーブルデータも洗い替えなければならない。

このような超めんどくさい事情があるので、移行がかなり面倒です。

手順が無い中で調べながらやったのもあり、私自身も移行にかなりの時間がかかりました。

続きを読む

拙作の野球スコアブックモジュールWebScoreRevolutionはV1.31まではシングルモジュールとしてのみ動作し、モジュールの複製には対応しておりませんでした。

しかしこのたび、モジュール複製可能なように実装を見直している最中なので、その過程をメモとしてまとめておきます。

モジュールの複製とは

XOOPSで言う複製可能なモジュールとは、例えばhogehogeというモジュールがあった場合、

XOOPS_ROOT_PATH/modules/hogehoge

の他に

XOOPS_ROOT_PATH/modules/hogehoge2

というような、ユーザーが(ある程度)自由に決めたモジュールディレクトリ名でファイルを置くことができ、両方のモジュールがインストール可能であることを言います。

続きを読む

XOOPSのWodPressモジュールXPressMEのV2.2.0がリリースされました。

早速アップデートし、WordPressも2.9.0にバージョンアップしました。

先月、WP SuperCacheのハックを組み込んでもらった縁か、リリースのプレゼンテーションの最後に私の名前も入れていただいてますｗ

V2.1.4からV2.2.0にバージョンアップすると、今まで使っていたWordPressテンプレートが古いと警告が出てしまったので、仕方なく新しいデフォルトのテンプレートxpress_defaultをコピーしてオリジナルテンプレートを作り直しました。

とはいっても、日記のタイトルのフォントが小さいので大きくしたのと、タイトルのバックグラウンドを水色の帯にしたくらいの変更ですが。

WordPressも2.9.0が出たのでバージョンアップしました。WordPressも更新早いですね。あっという間にV3まで行きそう。

先日、WP Super Cacheについての記事を書きましたが、その後も格闘しております。

まず、分かったこと：

WP Super Cache は「ON」モードと「HALF ON」モードがあり、「ON」モードの方が高速らしいです。

しかし、自分のサーバー環境では「ON」モードにするとうまく動作しません。
「ON」モードと「HALF ON」モードでは、cacheファイルが置かれる場所もファイルの名前も違いますが、なぜか、
・cacheを作るときは「ON」モードで
・作ったcacheを見に行くときは「HALF ON」モードで
というナゾな動きになっており、処理がかみ合っておらず、何回リクエストしても「cacheがないので新しく作るぜ」モードになってしまいます。
時間があれば原因も突き止めたいと思うのですが、もうあまりかかわりたくないので「HALF ON」モードのまま使ってます。

「ON」モードの方が高速って言ったって、「ON」モードで動くシーンはそんなにないだろう

ログとかソースとか追っかけてると、POSTリクエストはそもそもキャッシュされる対象にはなっていないし、GETリクエストも、パラメータ
を渡しているリクエスト(?key=valueみたいなリクエスト)は、「ON」モードではなく「HALF ON」モードで処理される仕様みたいです。
うちのサイトのWordPressは、各記事エントリは「?p=xxxx」みたいなURLになるので、必ず「HALF ON」モードになるってことです。

言いかえれば、「ON」モードで動くURLはindex表示(記事一覧表示)くらいしかありません。
なので、「ON」モードに無理にせず、「HALF ON」モードで使ってりゃいいんじゃない？ということになるわけです。

2回目ではなく、3回目のリクエストで初めてキャッシュが効くリクエストがある

XOOPSでXPressMEを使っているときに限った話ですが、WP Super CacheとXPressMEのプラグインが処理される順番の

関係により、2回目ではなくて3回目で初めてキャッシュが効くようです。

WordPressプラグインは、アルファベット順に処理されるようなので、WP Supeer Cacheの方がXPressMEより先に実行されるため、
上記のような現象が起こります。

Chromeではキャッシュが効かなかったが、いつのまにか直っていた

たぶん「ON」モードではなく「HALF ON」モードにしたから直ったのか…？ 知らん間に直ってたから謎。

XPressMEの作者toemonさんとの昨日からのディスカッションの過程で、自分の理解の浅さに気がついて、今日焦ってそんなことを調べていたのでした。
そんでディスカッションも私の言ってることがおかしな方向に行ってるのでちょっとかみ合ってなかったり…

しかしこの人はすごいなぁ。XOOPSとWordPressの仕様を熟知しておられる。それでいて仕事が速い。そして指摘がするどい。

とりあえず、WPtouch用のハックをマージしていただいた件に続き、今回のWP Super Cahceプラグインの件も次期リリースに

取り込んでいただけるみたいでホッと一安心です。

かまって君みたいな粘着で、しかも的を得ない要求でもちゃんと受け入れてもらえてほんまありがたいですが…