「XOOPS」カテゴリーアーカイブ

twitterfeedのしっぽ

twitterfeed を使って更新情報をtwitterで流していると、正しくないURLがtweetされてしまうことがある。
リンクのURLの末尾に次のような文字列が附加されてしまうのだ。
?utm_source=twitterfeed&utm_medium=twitter

XOOPSの場合はすべてのモジュールのRSS(ATOM)フィード配信でそういう現象が発生するわけではなく、このWordpressモジュールなどに限られている。
そのため、モジュール側の問題かと思っていたのだが、実はぜんぜん関係なく、twitterfeed側の問題であることがわかった。

リソース
http://webkit.seesaa.net/category/7134710-1.html
http://blog.fkoji.com/2009/11141538.html

どうやら twitterfeed の仕様変更でUTMタグが設定可能になった際、オプションにもかかわらずデフォルトで勝手に設定がなされてしまったことに起因しているようだ。
解除するには以下の手順。

1) 設定済みfeedを「edit」から編集する
2) 「Step 2: Configure Publishing Services」へと進む
3) 「Active Services」から設定済みtwitterアカウントを選択する

twitterfeed_01

4) 「UTM Tags」の設定欄に入っている文字列「Source: twitterfeed」「Medium: twitter」を削除して保存する

twitterfeed_02

これでヘンな「尻尾」のないリンクURLがtweetされる。

XOOPSのUTFなお引っ越し その2

前回はデータベースの引っ越しについてぐたぐたと書いたが、今回はXOOPSの設定などについて。

1) ファイルのバックアップとリストア

sshで入って xoops_root_path と xoops_trust_path で指定したディレクトリを丸ごとtgzで固めよう…と思ったら、root_path側は圧縮中にタイムアウトする。
負荷が高すぎるのでプロセスがkillされたようだが、たかだか2GBくらいでタイムアウトとは、どんだけ弱いサーバなんだ。
(しかし、移転先のサーバも3分以上継続されたプロセスはkillされるのでレストアでもひやひやした)
というわけでいくつかに分けてバックアップを取る。

xoops_trust_pathはそんなに容量がないが、エラーが出る。
sessionやcacheディレクトリに所有者がapacheのファイルができてしまっているためだ。
これらは削除しちゃってもかまわないのでだが、特定ディレクトリやファイルを除外して圧縮バックアップするにはこんな感じ。

まずは除外したいディレクトリやファイルを記述したファイルを用意する。

xoops_trust_path/session/*
xoops_trust_path/cache/*

こんな感じで書いて適当なファイル名(この場合はhoge)で保存。

$ tar cvzXf hoge xoops_trust_path.tgz xoops_trust_path

なお、cronで行う場合はフルパスで書かないとエラーが出ることがある。

で、固めたファイルを新サーバで展開すると。

2) mainfile.phpの書き換え

mainfile.php や.htaccess を新サーバの環境に合わせて書き換える。
たいていの場合は xoops_root_path と xoops_trust_path のフルパス、データベース名、データーベースのユーザ名、パスワードくらいで済むはず。

3) 文字コードの変換

XOOPS Cube の場合は言語ファイル以外のPHPファイルに日本語が直書きされている部分はほとんどないはずだが、モジュールによってはあったりするので、そういう日本語ファイルがあればUTF-8に変換する。
移転したサイトの場合、PHPファイルに日本語なかったが、テーマのHTMLファイルには日本語あるので、変換した。
また、言語ファイルをカスタマイズしていたり、古いモジュールなどでUTF8の言語ファイルが用意されていない場合は、langage/japanese をディレクトリごと ja_utf8 としてコピーし、文字コードを変換する。


$ cp -r japanese ja_utf8
$ cd ja_utf8
$ find . -name "*.php" -print0 | xargs -0 nkf -w -Lu --overwrite

深い階層のファイルまでいっぺんに文字コードを変更する場合には、まずスクリプトを用意。


#!/bin/sh
nkf -w $1 > TEMP
mv -f TEMP $1

これをたとえばhenkan.shというファイル名で保存し、たとえばxoopsというディレクトリ以下全体にあるphpファイルの文字コードを変換する場合。


$ find xoops_root_path/xoops -name '*.php' -exec ./henkan.sh \{\} \;

*円記号に化けている箇所はバックスラッシュ

参考
http://www.e-tsuyama.com/cgi-bin/blog/ms.cgi?ShowDiary_file=/zencart/1177140934&blogid=20&t=sketch

4) パーミッション

casheやuploadなど書き込み可能にしなくてはならないディレクトリのパーミッションをチェックして、必要に応じて変更。

5) 言語選択

cubeUtilsで、言語切換をしている場合は、以下のファイルを書き換える。
conf_ml.ja_utf8_sample.php として設定例が用意されているので、それをコピーすればいける。
xoops_root_path/modules/cubeUtils/include/conf_ml.php

日英で切り替えてきる場合は、以下のファイルの最後の部分、210〜220行あたりを書き換える。
xoops_root_path/modules/legacy/language/english/global.php

変更前

if (!defined('_CHARSET')) {
define('_CHARSET', 'ISO-8859-1');
}
if (!defined('_LANGCODE')) {
define('_LANGCODE', 'en');
}
// change 0 to 1 if this language is a multi-bytes language
define("XOOPS_USE_MULTIBYTES", "0");

※EUC環境で変更していた場合は「ISO-8859-1」ではなく「EUC-JP」に変更されているはず。

変更後

if (!defined('_CHARSET')) {
define('_CHARSET', 'UTF-8');
}
if (!defined('_LANGCODE')) {
define('_LANGCODE', 'en');
}
// change 0 to 1 if this language is a multi-bytes language
define("XOOPS_USE_MULTIBYTES", "1");

「ISO-8859-1」の部分を「UTF-8」に変更し、マルチバイトの設定を「1」にするわけだ。

6) 使用言語を ja_utf8 に変更

管理画面の「互換モジュール>>全般設定 >>使用言語」を「ja_utf8」に変更。
altsysでコンパイル済テンプレートキャッシュをクリアしておく。
altsysの「言語定数管理」での設定も引き継がれるはずだが、反映されていない場合は手動で設定するしかない、と思う。
やっていないのでわからないが、 xoops_trust_path のキャッシュファイルをなんとかすればなんとかなるかもしれない。

なお、文字化け対策としてpreloadにHoge.class.phpなんておまじないを置いていた場合は削除しておく。

< ?php define("LEGACY_JAPANESE_ANTI_CHARSETMYSQL", true); ?>

こういうやつね。

だいたいこんなところでしょうか。
先達の知恵に感謝いたします。

XOOPSのUTFなお引っ越し

とあるXOOPSサイトのサーバ引っ越しを機に、EUC-JPからUTF-8に文字コードを変更することにした。
近い将来 XOOPS Cube もデフォルトの文字コードがUTF-8に変更されるはずだし、現状でも環境は整っているので、今のうちに準備しておこうというわけである。

EUC-JPなXOOPSからUTF-8なXOOPSへの引っ越し。
というだけならば、さほど面倒なことはなく、巷に情報も溢れている。
特に同じサーバ内で文字コードを変更するだけなら、さしたる問題がないケースが多い。
しかしながら、今回は仕様の異なるサーバへの引っ越しのうえに、ひと筋縄でいかない非常にめんどくさい事情もろもろがあったので、ちょっと記しておきたい。

まずはデータベースのサイズ
これがでかいのだ。
非圧縮で約330MBあり、tgz圧縮で約40MBある。
旧サーバは割り当てメモリが少なくまた非力なこともあって、一括バックアップをしようとしても、XOOPSのバックアップモジュールはもちろん、 phpMyAdminでもエラーが出る。
なので、シェルからコマンドラインで行うか、スクリプトで実行するしかない。

バックアップするだけならまだいいが、問題はリストア
一括バックアップではファイルサイズが大きすぎてphpMyAdminでは書き戻しできないので、Bigdumpなどのツールを使うか、コマンドラインから行う必要がある。
それだけならちょっとの手間であるが、EUC→UTFに文字変換したした場合、そのなかに機種依存文字なんかがあると、リストアの途中でエラー終了してしまうのである。
(一般に掲示板なども公開しているサイトなので、ユーザによる書き込みには機種依存文字がけっこう多いのだ)
そのため、単に文字コードを変換するだけでではなく、SQLファイルをテキストエディタで編集する必要があるのだが、AMD最強マシンをもってしても 300MBものファイルを編集するのは重たすぎてめちゃくちゃたいへん。
以上のような理由でスカッと一括バックアップ&リストアは諦め、モジュール単位でテーブルをまとめてバックアップすることにする。
このほうがエラーが出た場合など原因となる箇所を突き止めやすいし、1箇所ダメだから全体がダメという自体にも陥らない。
人間横着しちゃいけないということか。

そもそも上述したように、旧サーバはマシン自体が非常に非力なうえに、チューニングが悪い。
バックアップやレストアしている間はWebページの表示ができなかったりする。
データベースだけでなくファイルのバックアップでも同様である。
なにかにつけエラーが出たりタイムアウトしたりで作業が中断する。
一括ではなく、ちまちまが似合っているのだ。

さて、これで問題が解決したかという序の口である。
最大の問題は文字コードである。
一般的な「EUC-JPなXOOPSからUTF-8なXOOPSへの引っ越しガイド」では、データベースの文字コードを変換し、DEFAULT CHARSET の設定をEUC-JPからUTF-8にすればよいというようなことが書いてある。
しかしそれは「お行儀のよい」サーバの話である。
もともと旧サーバは契約時にMySQL4系/PHP4系だったのが、途中でMySQL5系/PHP5系に移行しており、それに伴い MySQLの文字コードもUTFに変更されている。
しかし、UTFで統一されていればまだしも、こんな感じになっている。

mysql> show variables like “char%”;
+————————–+—————————-+
| Variable_name | Value |
+————————–+—————————-+
| character_set_client | binary |
| character_set_connection | binary |
| character_set_database | binary |
| character_set_filesystem | binary |
| character_set_results | binary |
| character_set_server | binary |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
+————————–+—————————-+

対して新サーバはこんな感じ。

+————————–+—————————-+
| Variable_name | Value |
+————————–+—————————-+
| character_set_client | binary |
| character_set_connection | binary |
| character_set_database | binary |
| character_set_filesystem | binary |
| character_set_results | binary |
| character_set_server | binary |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
+————————–+—————————-+

これが両方とも自サーバであればなんでもなるわけだが、両方ともレンタル・サーバであるから、MySQLの仕様を勝手に変更することはできない。
さらにややこしいことに、旧サーバの旧環境にインストールしたXOOPSのデータベースは、EUC-JPとlatin1が混在しているのである。
ひどいケースだと、同一テーブルでもフィールドによって文字コードが違っていたりする。
いろんなサイトのいろんな情報をもとに、コマンドラインからいろんな指定をして出力してみたり、さまざまな方法を試してみたが、どれもうまくいかない。
問題はバイナリの部分で、SQLのダンプファイルの文字コードを変換しても、バイナリで記録されている部分は、サイト表示で文字化けしてしまうのである。
試行錯誤の結果、シロートも眉をひそめるドシロートな方法(© hirasawa)で乗り切った。

01) phpMyAdminからモジュール単位でSQL形式でエクスポート
02) エクスポートされた文字列をテキストエディタにC&Pし、UTF-8で保存(*1)
03) 機種依存文字をエディタのマクロで置換(*2)
04) DEFAULT CHARSET でEUCやlatin1になっている部分をUTF8に置換
DEFAULT CHARSET=utf8
05) 新サーバのphpMyAdminでインポート
06) Web表示で文字化けする部分(バイナリ部分)はテーブル単位で、CSVデータ形式でエクスポート
07) エクスポートされた文字列をテキストエディタにC&Pし、UTF-8で保存(*2)
08) 新サーバのphpMyAdminで対応するテーブルをいったん空にする(*3)
09) 新サーバのphpMyAdminで対応するテーブル選択してからインポート
インポートするファイルの形式→LOAD DATA する CSV→テーブルデータを差し替えるファイル(チェック)

*1 ファイルに出力してから文字コードを変換するよりも、手っ取り早く、文字化けする可能性が低い

*2 「〜(波ダッシュ」や「−(全角マイナス)」は機種依存文字ではないが、文字コード変換時に全角チルダや全角ハイフンになったり文字化けしたりするのでこれも置換する。
いわゆる全角チルダ問題に関しては、まったくMSを呪い殺したくなります。
http://www.kab-studio.biz/Programing/JavaA2Z/Word/00000716.html

*3 やらなくてもいいが念のため。

以上がシロートも眉をひそめるドシロートな方法(© hirasawa)の実体である。
次回、ファイルの変更、設定その他について書く、かも。

出来損ないのブラウザはいつまでトップで居続ける気か

出来損ないのブラウザのくせに、IE6は未だにトップシェアである。
もうじきIE7にリプレイスされそうだが、それでもまだしばらく生き残るだろう。
Win98とかIE7が使えない環境ならいざ知らず、なぜにXPでIE6を使い続けるのか理解できないが、それがプリインストールの強みなのだろう。
Windowsにおいては、きっとFirefoxやOperaなんてその存在すら知らない、というよりブラウザが「選べる」ものだということすら知らないユーザがマジョリティなのだろう。
自分に与えられた自由や権利に気づかないのが無知の恐ろしさであり、管理する側にとっては幸いなのだろう。
自由は恐怖であり、逃避・放棄すべきものなのだ。

などと真面目なフリをしてみたが、実はIE6でアルファチャンネル(透過)PNGが表示できないとは知らなかったよ、ごめんなさい、という話である。
FF3とIE7だけで検証しちゃいけませんね。
いくらできそこないでも、トップシェア様を無視しちゃいけません。
というわけで対処法(IE6やIE5.5で強引に透過PNGを表示させる方法)を検索したら、出るわ出るわ、いっぱいあるのね。

http://homepage.ntlworld.com/bobosola/pnghowto.htm
http://www.twinhelix.com/css/iepngfix/

上記が有名どこみたいで試してみたが、CSSで背景指定したPNGとHTMLで指定したPNGを重ねてきれいにIE6で表示できるのは、後者の PNGFix v2.0 Alpha だったので、ファッシネイション本家サイトに導入してみた。

XOOPSの場合は使っているテーマの組み込むのが手っ取り早い。
まずはこちらのファイルをダウンロード。
http://www.twinhelix.com/test/iepngfix.zip

展開してできる iepngfix.htc iepngfix_tilebg.js blank.gif の3ファイルを使用しているテーマのディレクトリへ。
もし blank.gif を同階層ではなくimagesディレクトリなどへ置く場合は、iepngfix.htc を編集して相対パスを記入しておく。

ex)
IEPNGFix.blankImg = ‘blank.gif’;
–>
IEPNGFix.blankImg = ‘images/blank.gif’;

あとはtheme.htmlのヘッダ部分に下記を追記。


<!--[if lt IE 7.]>
<style type="text/css">
img, div { behavior: url(<{$xoops_imageurl}>iepngfix.htc) }
</style>
<script type="text/javascript" src="<{$xoops_imageurl}>iepngfix_tilebg.js"></script>
<![endif]-->

相対パスではうまく動作しないみたいなので< {$xoops_imageurl}>でテーマディレクトリを指定。
IE7.x未満にだけ適用されるように、IEの独自拡張で[if lt IE 7.]と指定。
ほかのブラウザには影響ない。

これで出来損ないブラウザへの対応終了。
ありがたくドネーションをPayPalで支払ったのであった。

……とオチをつけて終わろうと思ったら、検証用に使っていたVM上のIE6で透過ではないPNGも表示されなくなった。
一瞬だけ表示されて消える怪現象。
調べてみると、WindowsでのPNGがらみの不具合は多いらしく、レジストリが壊れているせいだとか、いろいろあるが、修正できない。
結局、5年振りくらいにVMwareにWin98を再インストールしましたよ。

Firefox3と入力フォーム

Firefox3では、入力フォーム周りのレイアウトが崩れやすいようだ。
上位のテーブルなどで幅を固定していても、input の size や textarea の cols を指定しておかないと、テーブル幅を無視してどどーんと入力エリアが突き抜けたりする。
XOOPSでは入力フォームを多用するので、テンプレートでいちいち上記を指定してやんないと、テーマによってはぐちゃぐちゃになります。

XOOPSとWordPressを行ったり来たり

まずテーマ・スウィッチャ以前に。

XPressモジュールでは、XOOPSとWordPressを行ったり来たりできるようになっている。
XOOPSモードでは「メタ情報」に「WordPressモードへ切替」というメニューがあり、これをクリックするとWordPressモードへ切り替わる。
翻ってWordPressモードでは、サイドバーに「Change to XOOPS Mode」というようなメニューを設けてあるので、そこをクリックするとXOOPSモードへ切り替わる。
ところで「モードってなによ」であるが、ユーザにとってはルック&フィールの問題でしかありません。
まあ、見た目と操作方法の違いであって、文章の中身は変わりません。

WordPressのHTMLエディタ

WordPressには標準のHTMLエディタとしてTinyMCE(ビジュアルエディタ)が搭載されているほか、プラグインとしてFCKeditorなどがある。
(ほかに、WYSIWYGではない、テキストエディタに毛が生えた程度のHTMLエディタも搭載されている)
FCKeditorはXOOPS本体でも使っているので、 WordPress(XPressMEモジュール)でもFCKeditorのプラグインを使ってみた。
しかし、なぜか二重の改行が入るという怪奇現象が起きる。
はじめは、PとBRの問題かと思ったが、編集中にFCKeditorでソースを見ると、ちゃんとBRになっている。
しかし、プレビューでは、BRが二重に入ってしまっている。

この問題とは長い間格闘したが、結局はFirefoxとの相性問題というか、バグではあることがわかった。
ふだんIEを使っていればすぐに気づきそうなものだが、あいにくふだんのデスクトップはFedoraである。
さて、ブラウザごとの同確認結果が次の通り。

●InternetExplorer7
標準エディタとFCKeditorの両方が正しく動く。

●InternetExplorer6
標準エディタは動作しないので、単なるテキストエディタに代替される。
FCKeditorは正しく動く。

●Firefox2.0
標準エディタは正しく動作するが、FCKeditorは正しく動作しない
(と思ったら、使ってるうちにShift+Enterで改行できなくなった、なぜだ)

——————————–
2008/07/04追記
Shift+Enterで改行できないのは、単にAtokの「推測確定 」にキーアサインされていたからであった。
Atok側の設定をControl+Enterにしたらば、ちゃんとShift+Enterで改行できるようになりました。
——————————–

●Win版Safari
標準エディタは動作しないので、単なるテキストエディタに代替される。
FCKeditorも正しく動作しない。

FCKeditorはデフォルトで、EnterキーでPタグを、Shift+EnterでBRタグを出力するが、fckconfig.jsというファイルを編集すれば変更できる。

FCKConfig.EnterMode = ‘br’ ; // p | div | br

FCKConfig.ShiftEnterMode = ‘p’ ; // p | div | br

標準搭載のビジュアルエディタ(TinyMCE)も、EnterキーでPタグを、Shift+EnterでBRタグを出力するが、いったいどこかで切り換えられるのだろうか。

なお、FCKEditorプラグインを有効化した場合は管理ページの[ユーザー]設定で[記事投稿時にビジュアルリッチエディタを使用する]の
チェックを外しておかないと不具合が起こることがある。

動作検証用Weblogはじめました

XOOPSの設置やメンテナンスをサポートしている某サイトや某サイトや某サイトでWeblogモジュールをインストールしているが、WordPressはけっこう「クセ(仕様とも言う)」もしくは「バグ(仕様とも言う)」のようなものあり、実際に自分で使ってみないことには細かな点はどうもよくわからない。
というわけで、試験導入したモジュールを公開して運用してみることにした。
要は動作検証用サイトであるからして、しょっちゅうデザインが変わったり、動作しなくなったり、放置されたり、予告なく廃止されたりするかもしれない。
また、moderoomは本来、平沢進/P-MODEL関連の情報を扱うサイトだが、ここはなんでもありで、関係ないことも書く。
いや、関係ない話のほうが多くなる気がする。
穴埋め(記事の数がないと検証できない)や備忘録のためにBBSなど既存のコンテンツのリサイクルする予定なので、新着記事は更新の時系列とは必ずしも一致しません。
では、よろしくお願いいたします。