最近、HTMLのFORMを処理していて、radioボタンが１つあるか２つ以上あるかで処理を
分岐させないといけないケースがありました。

//CASE1: form内にnameが一致するラジオボタンが１つだけのケース 
<FORM name="frm1">
<input type="radio" name="rdo" value="a">
～
</FORM>

//CASE2: form内にnameが一致するラジオボタンが複数あるケース 
<FORM name="frm2">
<input type="radio" name="rdo" value="x">
<input type="radio" name="rdo" value="y">
～
</FORM>

この時、frm1.rdo.valueは"a"、frm2.rdo[0].valueは"x"、frm2.rdo[1].valueは"y"
となるのだが、rdoで[]がつかえるかどうかをその場で判断したいことがありました。

で、[]でアクセスできるから、rdoをJavaScriptのArrayだとおもい、
alert( frm2.rdo instanceof Array);　とすると、FALSEが返り、
もちろん、alert( frm1.rdo instanceof Array); もFALSEが返ってきてしまいました。

これだとCASE1とCASE2で処理分岐できないことになります。

じつは、<input type="radio">は、
同一FORM内に同じname属性が１つしかない場合、HTMLElement　オブジェクトになり、
同一FORM内に同じname属性が２つ以上ある場合、HTMLCollectionオブジェクトになるのです。

HTMLCollectionは、「読み取り専用」のlengthを持ち、[index]でアクセスできるので、
一見配列Arrayと錯覚しますが、Arrayではないのです。

ここの判断コンビニエンス関数をつくってみました。

//HTMLCollection判断関数
//IE9,FF15,Chrome21,Safari5,Opera12 動作確認済
//
function isHTMLCollection(e){
 return ( e && e.item && typeof e.length === 'number' ) ? true: false;
}
//HTMLElement判断関数
//IE9,FF15,Chrome21,Safari5,Opera12動作確認済
//
function isHTMLElement(e){
 return ( e && typeof e.innerHTML === 'string' ) ? true: false;
}

ちなみにCASE1,2での使い方は、

isHTMLCollection( frm1.rdo );　//falseになります。
isHTMLCollection( frm2.rdo ); 　//trueになります。

isHTMLElement( frm1.rdo );   //trueになります。
isHTMLElement( frm2.rdo );   //falseになります。

です。

　去る2010/09/24にNetCommons2.3.1.0がリリースされましたね。
みなさん、すでにバージョンアップはされましたでしょうか。
遅ればせながら弊社サイトも先週末にバージョンアップを実施しました。
今回のリリースはデータベース周りの処理速度改善の手がいろいろと入っているようです。表示がサクッとされるようになりましたね！

　私はこれまでのバージョンアップは、ノーミスで来ているので今回のバージョンアップもさほど心配はしていませんでした。
　万が一のためのバックアップをきちんととり、
　ファイルの上書きを行い、
　モジュール更新を実施し、
　弊社独自のカスタマイズをしている部分と、今回のリリースされた部分の整合性を取り（これが結構手間をとります）、
　再度、更新を行い......

　いつもでしたらこれでOKです。
　
　今回も無事に作業が終わり、今回の目玉のひとつ、WYSISWYGエディタでのAmazon商品紹介を行おうとしたらですね、　Amazonボタンが見当たらない！！
いや、ボタンは一個増えているのですが、Amazonのボタンの位置には太字にするためのボタン「B」が表示されているばかり....
試しにその「B」ボタンを押してみると、しっかりAmazonの商品を選ぶ画面が開きます。
　機能は生きているのに、ボタンが表示されないって.....何？私は何のミスをしてしまったの？

　はい、皆様はもうお気づきですね。
　そう、CSSキャッシュです。
　NetCommonsは2.3.0.0よりCSSがキャッシュされるようになっています。
　以前のCSSが残っていたために、WYSISWYGエディタの新しいAmazonボタンが正しく表示されない状態が生じていたのです。
　そう、NetCommonsは2.3.0.0より、システム更新が行われたときには、キャッシュのクリアが必須になっているのです！！

　私は通常FireFoxを使用しています。
　FireFoxはF5を押せば、ほぼ強制リロードになって、JavascriptやらCSSのキャッシュを消し、新しいものを読み込んでくれるので、キャッシュのクリアは特に必要を感じていませんでした。
　しかし、WYSISWYGエディタのCSSは、エディタを開いたときに初めて動的に読み込まれる仕様となっているため、F5リロードの対象外となっていたのです。

　自分でデザインカスタマイズ本に「デザインをいじった時はキャッシュのクリアを！」とか書いておきながら、何をやっているのか　まったくもってお恥ずかしい。
　恥さらしなお話ですが、今後、みなさんがCSSキャッシュを心に強く留めていただくためにもあえて語らせていただきました。

　え？更新時のキャッシュクリアなんて常識だ？
　すいません顔を洗って出直します。

レンタルサーバ会社様の共用サーバーでNetCommonsを運用されている会社・団体様も多いと思います。その際、以下に当てはまる方

・かなり頻繁にNetCommonsにコンテンツ投入している。
・データベース管理画面としてphpMyAdminのみを提供されている。
・共用プランなのでsshが使えない。
・NetCommonsのバックアップとして、定期的にフルバックアップを実行している。

に注意していただきたいことがあります。

ネットコモンズのフルバックアップ.tar.gzをＰＣ上で展開すると、いろいろな復元ファイルとともにDataBaseの復元ファイル(backup_full.sql)ができます。


これを、（事前に作成しておいたDatabaseに対して）phpMyAdminのインポートを
使い、データベースの内容を復元します。


ここで注意していただきたいのが、青いまるで囲んだ部分です。
このケースでは、phpMyAdminでインポート可能なsqlファイルの上限ぎりぎりまでＳＱＬファイルが大きくなっている点です。

運用してしばらくは問題ありませんが、ＮＣを使い続けて、かつ過去コンテンツの整理をしないでおくと、データベースの内容が膨れて、このphpMyAdminのインポートファイルの上限値を越える可能性があります。（この事例では、ぎりぎりセーフです）

教訓）
バックアップファイルしたファイルは解凍し、sqlファイルのサイズをチェックしよう！

この話題はNetCommons上で拡張モジュールなどを開発されている方には必須のTipsです。
いろいろと拡張モジュールを作成しだすと、様々なデータを取り置くためDBに独自テーブルを作られる必要に迫られるでしょう。
そのとき、ひとつ大切なことがあります。
テーブル名は「config」で終わるものにしてはいけません。

xxxxx_configでもooooo_configでもoxoxoxoｃｏｎｆｉｇでもだめです。
テーブル名の最後の6文字がconfigで終わるものが、DB上に（通常の<prefix>_configテーブル以外に）存在すると、コンパネのセキュリティ管理＞プレフィックスマネージャーの動作に悪影響を与えます。

プレフィックスマネージャは、DBのテーブルのプレフィックスを変更する機能を持っている管理系のモジュールです。
その機能を実現するため、DBに存在する全てのconfigテーブルを調べて、DBに存在する全てのサイト名とそのサイトのテーブルにつけられているプレフィックスを取得しようとします。取得に失敗すればエラー扱いとなります。

はい、そうです。
プレフィックスマネージャでコピー作成されたテーブルたちも管理対象にするため、終わりがconfigのテーブルを全て調べ回ります。うっかりconfigで終わるテーブルを作ってしまうと、それも調べられて、『サイト名が取り出せないconfigテーブルがあるなんて！大変だ！！エラーだ！！！』となってしまうということです。

お作法：
１．終わりがconfigになるようなテーブルは本物のconfigテーブル以外は作成しない。
２．configっぽいデータを格納したいなら、本物のconfigテーブルへいれましょう

昨日は、この現象のため半日つぶしてしまいました

それともみなさん既に既知のことかも。私が知らなかっただけ？

追記：

後日、公式サイトでこの現象が正式にバグとして認められ、パッチが発行されました。
現在は、パッチを充てれば、configで終わるテーブルが存在しても問題なく動作するようになっています。

NetCommonsのキャビネットモジュールは、その使いやすさから人気のモジュール１つです。
みなさんもよく使っていらっしゃるのではないでしょうか？
私も社内の文書管理や、お客様サイトの構築でよくつかうのですが、ちょっとした癖があります。今日はそのことを少し書きます。

まずは、実際にキャビネを配置し、ダミーの文書ファイル「試験20100310.xls」をアップしてみます。



続いて、実際の業務でもよくやる、修正⇒再アップ⇒修正⇒再アップをしてみます。すると結果はこうなります。


見ての通り、同じファイルを連続してアップすると、Windowsのように「上書きしますか？別名で保存しますか？キャンセルしますか？」と聞いてこなくて、いきなり３桁連番が付加されて別名保存されます。

この時、ファイル名の後半が数字（この場合はYYYYMMDDの日付）だと、数字が連続してよくわからなくなりますので、ご注意ください。

また、最新のファイルをダウンロードしようと、「試験20100310002.xls」をクリックすると、以下のＰＯＰＵＰが出ます。



マルで囲ったように、見た目のファイル名は連番002がついていますが、ダウンロードする時は、アップした時の（連番がつく前の）オリジナルファイル名でダウンロードしようとします！（私の手がすべって最初のアップしたファイルをクリックした訳でありませんヨ）

なので、これを手元のローカルＰＣに保存する時、気をつけないと、オリジナルファイルとかぶります。

ちなみに、キャビネモジュールの該当ファイルのプロパティを表示すると、

と表示されるので、属性的にも002がついたファイルになっているので、ダウンロード時だけの特殊（思いやり？！）仕様ですね。

理解して使うと便利ですが、初めて経験したときはちょっと？？？になります。

以上まとめますと

（１）ＮＣのキャビネは同名ファイルをアップすると、無条件で連番ついた別名ファイルで格納される。

（２）連番がつく＝ファイル名の後半が数字だと繋がって訳がわからなくなるので、アップするファイルの名前後半には数字をつけない方がよい。

（３）ＮＣ上は連番がついた別ファイルで管理されていますが、ダウンロードするときは、アップした時のオリジナルファイル名でダウンロードされることを意識しましょう。

です。

皆さん、日々バックアップをされていると思いますが、リストアされたりすることがあるでしょうか？

リストア元のサイトに特に問題なかったので、？？？と思ったのですが、調べた結果、原因はリストア元のサイトにBASIC認証が掛かっていたためでした。

このような場合の対処策は２つ。１つは、リストア元のサイトのBASIC認証を一時的に外す、です。ですが、BASIC認証は意味があってしているので、そう簡単に外すというわけにもいきませんよね。その場合は、
webapp/components/request/Main.class.phpの中で、sendRequest()を発行する前に、setBasicAuth(BASIC認証ID, BASIC認証パスワード)を発行するようにしてください。
これにより、リストア元にBAISIC認証をかけたまま、リストアをすることができます。

なお、これはNetCommonsの共通コンポーネントを修正する力技なので、リストアが完了したら、必ず、Main.class.phpを元のソースに戻すことをお忘れなく。

NetCommons2.2より、固定リンク対応できるようになりました。
http://xxxx.net/?page_id=xx...
ではなく、
http://xxxx.net/会社/　とか http://xxxx.net/company/
とかでＵＲＬがスマートになるので使い始めた方も多いかと思います。

この固定リンクを有効にするのが、[管理]＞[システム管理]＞[サーバ設定]タブの固定リンクの設定です


ここで、「いいえ」から「はい」にすると、固定リンクが有効になるのですが。。。この時、注意が必要です。
固定リンクは、apacheのmod_rewriteを利用して実現されているので、それを有効にするため、.htaccess　にそれを書いてあげる必要があります。

注意書きをよむと、「htdocs直下に　（あるいはインストール時にURLをhttp:/xxx/htdocsでなく、http://xxx/にした方は、DocRoot直下に）『.htaccess』が自動的に作成されます」とあります。
が、この自動的にというのは、既存.htaccessファイルがあれば追加書き込みする、ではなく、既存.htaccessファイルがあっても上書きされる、ということです。

つまり、、、サイト構築の最初によくやるBASIC認証などを.htaccessに書いておいていても、固定リンクを有効にしたとたん、上書きされて設定がクリアされる、ということです。

これを回避するには、
（１）独自の設定を書いた.htaccessを一旦別名(ex: .htaccess.backup)にしておき、
（２）固定リンクを有効にして、mod_rewrite設定がかかれた.htaccessが新規作成され、
（３）速攻、その.htaccessに、元あった.htaccess.backupの記述を追記する、

という手順を踏むことになります。

これって、けっこう綱渡りの作業なので、気がゆるんで作業していると、固定リンクを効かせてやった～と思っていたら、その他の設定がすべてクリアされていた。という笑えない状況に遭遇します。

作業者の皆様、固定リンクの設定をされる際は、この点注意して作業してくださいね。

こんにちわ、オールクリエイターの藤原です。
今日の話題は、NetCommonsを使い倒しておられる方からのご質問を受けての話です。
ちなみにバージョンは2.2.0.1です。

NetCommonsを使っていて、掲題のようなことに悩まれた方、結構おられるのではないでしょうか。
WYSISWYGエディタにて、「詳しくはお問い合わせのページにて....」というようなリンクを作成しますと、PCで表示されている場合は、リンククリックでちゃーんとお問い合わせページへ行くのですが、携帯で閲覧しているとき、そのリンクをクリックすると、あら不思議、携帯のTOPページへいってしまう？？

実は、NetCommonsは、PCと携帯でページを表示させるための仕掛けが異なるため、PC用のURLをリンクとして作成すると携帯ではどこのことかわからなくて、とりあえずTOPページへ飛ばしてしまえ！となるらしいのです

じゃあ、PCと携帯で共通のURLリンクが埋め込まれた文章は作成できないの？
これができるんです。
決め手はブロックのIDです。
携帯は、基本、ブロック単位で情報を表示するため、直接ブロックを指定すると該当のコンテンツを表示できるのです。

弊社のサイトのお問い合わせはページIDで指定するなら30ですが、そこに配置しているお問い合わせのモジュールブロックのIDは37です
http://allcreator.net/?page_id=30 →これは通常のPCのURLです
http://allcreator.net/?block_id=37 →これがPC、携帯共通的に使える問い合わせページへのリンクです
携帯、PC共通的に問い合わせフォームに行くリンクです。お試しください。
問い合わせページはこちらです


さてさて、ここまで読まれた方の中には、このページに埋め込まれた２つのリンクをPCでクリックしたり、携帯でクリックしたりした方もおられるでしょうね。
そうしますと「なーんだ、どっちのリンクも、携帯でクリックしても、ちゃんとお問い合わせのページに行くじゃん。しかも仰々しく説明してた、下のリンクのほうより、最初に書いてあるリンクのほうが、いきなりお問い合わせフォームじゃなくて、『お問い合わせ』のページにいってて、ちゃんとしているじゃないか！オールクリエイターめ嘘をついたな」と思われた方もおられるかも。

すいません、弊社のサイトは携帯プログラムにちょっとばかし手を入れて、通常のPCのURLを理解して携帯で表示できるようにカスタマイズしちゃっているんです。

いやー、だってリンクはるとき、いちいちブロックID調べて回るのが嫌になったもので；
だってコンテンツ作成するときはPCでやりますもの。PCのブラウザに出てくるURLを其のまま使いたいんですもの。
そう思いません？
皆さんが強くそう思われるなら、そのうち本家の方々のほうでも対応版出されるかもしれませんね。

先日、某レンタルサーバー（共用型）にNetCommonsをインストールする機会がありました。

インストール先のレンサバは(レンサバ業者は公開してなかったけど、独自に調べたら）FreeBSD。なので、「NetCommonsはLinux版もWindows版も違いはないけど、インストール先がUNIX系だからLinux版でいいだろう」と思い、NetCommons公式サイトから、NetCommonsNetCommons2.2.0.1 for 「Linux」（NetCommons2.2.0.1.tar.gz)をWindowsVistaにダウンロードしました。

で、lhaplusで展開後、お決りのhtdocs、maple、webappとindex.phpをffftpでレンサバにバイナリーモードですべてアップロード。そして、これまたいつものように、ブラウザ(FF)でアクセスし、NetCommonsインストール画面からインストール開始。なに１つ問題なく、最後までインストールが成功したので、安心してＴＯＰページに飛んだら。。。

なんと、お知らせモジュールのWelcome to NetCommonsの本文が抜けていました。そのほかにも、管理画面が真っ白！さらには、セッティングモードのモジュールリスト追加リストボックスが空っぽ！！

いくつか調べたのですが、ＤＢの特定テーブルへのinsertができていないなど、変な状況なので、「そういえばＦＦＦＴＰでアップするとき、何回かTimeOutしたので再アップしたけど、どれか失敗したかな？」と思い、アップロードした全ファイルを消し、登録したテーブルもすべて消した後、今度はWinSCP(FTPモード)で注意深くアップロードし直し、再度インストール。。

しかし、今度のＴＯＰもやはりWelcomeToNetCommonsのお知らせ本文が抜けている。モジュール追加のリストボックスはでるようになり、管理画面のアイコンが出るようになったけど、セキュリティーのプレフィックス設定タブが空っぽなど、やはりどこかおかしい。。。

レンサバの設定を疑ったり、通信時のアップ失敗を再度疑ったり、、、いろいろと調べててもどうもそれらではないらしことはわかってきたが、、ただ、設定した後のファイルやテーブルの状況がおかしいのは確か。（ＴＴ）

最後にVistaに展開した転送元ファイルを調べているうちに、webapp/modules/announcement/templates/defaults 下を覗いてびっくり、、、拡張子の.htmlが
.ht000664といったへんな拡張子になっているものがいくつか。。。その他のテンプレートファイルを調べると、あるある、拡張子.htmlがhtxxxxxxとばけばけのファイルがいっぱい。。。こりゃいった何だ、と調べたら、どうやらこういうことのようです。

 補足）具体的にどうなるか知りたい？と知人に言われたので、画面キャプチャを載せます。



GNU tar で圧縮されたtar.gzファイルを、Windows上の圧縮展開ソフト lhaplusなどで展開した場合、「長いファイル名が格納されている GNU 拡張フォーマット 」が問題で、ファイル名が化けるらしく、それらはデスクトップ上に@LongLinkファイルで報告される、とのこと。

試しに、NetCommons2.2.0.1 WIndows版（アーカイブ形式はzip）をダウンロードし、lhaplusで展開したら、展開後すると、これらのファイル名の文字化けはなくなりました。

NetCommons2系では、Windows版とLinux版でソースに違いはなく、ただtarボール（圧縮ファイル）の作り方が違うだけ、ときいていたので、あらためてレンサバの環境をクリーンにしなおし、今度はこのローカルＰＣに展開したNetCommons2.2.0.1 Windows版をアップロードして、インストール。。。すると、今度は、インストール後のＴＯＰ画面でちゃんとWelcometoNetCommonsの本文が表示され、その他おかしかったところもすべて直っていました。

いや～参りました。。。汗汗；；

そういえば、今まで自分たちは、UNIXを自由に扱える環境だったので、
tar.gz(Linux版）を直接ダウンロードし、LinuxやFreeBSD上でtar -xvfz で直接展開していていたこと。
windowsからレンサバにアップする時も、このtar -xvfzで展開されたファイル群を使ってアップしていたこと。
zip（windows版）を使うときは、XAMPPに入れるケースだったこと、
に気づいたのです。

（教訓）
レンサバでsshが使えないため、WindowsマシンからNetCommonsの展開後のファイル群をレンサバにアップする時は、レンサバのＯＳが、Linux/BSD/Windowsに関係なく、NetCommonsの「Window版」（というか、ZIP版）をダウンロード＆展開してから、アップすべし。

Linux版(というか、tar.gz版）を使うのは、Linux/BSD上でtarコマンドで直接展開できるときに限定すべし。

※lhaplusでなく、lhazなどを使えばこの文字化けはおきないとの記事も見ましたが、Windowsの場合、かなりの人が圧縮展開ソフトとしてlhaplusを使っているので、上記の教訓のようにするのが無難ですね。

2010/02/11追記）
lhaplusで同じ問題にあたり、lhazを入れて対応された方の記事があります。参考になれば。
http://voicetwo.selfip.com/yashikiba/blog/item/193/catid/11

先日、NetCommonsをベースにした、とあるシステム開発を行いました。その時に遭遇した問題のお話です。

---

開発したシステム

お客様からのご要望で、独自の会員データのインポート機能をおつくりしました。
別システムから独自のCSVが出力されるので、それを読み取ってNetCommonsベースのシステムの会員情報として取り込んでほしい。。。とのこと。

さっそく、もともとある会員データのインポート機能をちょっとカスタマイズかけた形で、新しいインポートモジュールを作り、お納めしました。
実際、さほど難しい話ではなく、
１．別システムで出力されたCSVがサーバーに自動的にUPされている
２．コントロールパネルから会員管理画面を開き、「インポート実行」ボタンをクリック
３．CSVから粛々とデータ取り込み
４．取り込み終わると結果画面を表示
これだけの処理のものです。

---

発生した問題

当初、なんの問題もなく稼働していたのですが、ある日突然お客様より
『いくら待っても結果画面が出ない』とのご連絡が！

調べてみますと、３番までの取り込み処理は、無事に完了しているのに４番の結果画面の表示だけが行われていない、という謎の現象でした。
しかも、この現象、弊社からのアクセスで試行しても再現しない、お客様のネットワーク内のPCからでないと発生しないようなのです。

お話を伺うと、このインポート処理、別システムとの同期をとるため、毎日別システムからの会員情報を取りこんでおり、幸いにも好評を得、日々会員が増加し、そして、会員が１万人近くなった最近、突然、結果画面が出なくなったのだそうです。

この他にも、いろいろ調べていった結果、どうも原因は
「取り込み処理が１５分を超えると、Ajaxの応答がPCに返らない（セッションの強制切断？）」
のではないかという結論に達しました。

---

解決策

そこで、この現象の対策として、会員情報の取り込みを小分割し、小さな分割した取り込み処理を行うたびにPCとのやり取りを行うように変更しました。
そして最後の小分割データを処理した後、結果画面を表示するように。
弊社内では起こらないだけに、かなりの目測対処だったのでかなり不安な対処でした。が、、これがどんぴしゃだったようで、お客様からは「結果画面が出るようになりました」とのうれしいご連絡が

---

あれ？

でも私は、NetCommons標準の会員データの取り込みを真似して作ったんです。（まぁ結構カスタマイズはしましたが；）
NetCommonsの標準の会員データインポートをなさっているところでは、このような問題は発生していないのでしょうか。
それとも１５分を超えるとセッションが強制切断される、という話のほうが珍しいのでしょうか。
是非とも皆さんの体験談などを伺ってみたいものです。