>1.郵便番号データベースをインストールした状態で郵便番号を入力すると
>　左の欄に「Searching...」と表示されたままになる

辞書とうまく接続されていない場合にそうなります。
どんな方法でされたか詳しく教えていただけますか。

＞2.メールアドレスに確認メールを送信する設定にしても、送信されない

基本的には動作しているはずなので、もう少し詳しく条件を教えてください。

郵便番号検索の件、メールでヒントを下さったからがおられ、中途半端のままだったことを思い出しました。

===========================================
"postno.cgi"の13行目の以下を

my $dbh = DBI->connect("dbi:mysql:dbname=concrete5_c5test1;host=localhost", 'concrete5', 'concrete5');

"/config/site.php"で合わせて変更してください。

define('DB_SERVER', 'localhost');
define('DB_USERNAME', 'concrete5');
define('DB_PASSWORD', 'concrete5');
define('DB_DATABASE', 'concrete5_c5test1');

以下のように置き換えてください。
変数は使えません中身に置き換えてください。

my $dbh = DBI->connect("dbi:mysql:dbname=<DB_DATABASE>;host=<DB_SERVER>", <DB_USERNAME>, <DB_PASSWORD>);

===========================================

このプログラムは、PHPに書き換える予定で、その際にデータベースの情報も
自動的に取得して動作するようにしたいと思います。

それとまだ事業者の郵便番号には対応していません。
ご希望があれば対応を急ぎますが。

郵便番号検索はphpよりjavascript+jsonで作成される方がいいと思います。

勉強不足なんですが、なぜそちらのほうがいいですか？

いづれにしろjsonが勉強になりそうなので、調べてみます。

>　 「郵便番号」の左の欄に「Searching...」と表示されたままになる

原因っぽいのが分かったような気がしますので報告させていただきます。

form_tomoac/block/form_tomoac/controller.php　の中で　CGI を呼び出しているところが、間違っているような気がします。

HTTPdのログ見たら
　 "GET /blocks/form_tomoac/postno.cgi?zip=～
を見に行っていました。


1111行目を以下のように変更したら動くようになりました。

httpObj.open("GET", "./packages/form_tomoac/blocks/form_tomoac/postno.cgi?zip=" + escape(zip), true);

すみません。
そうですね。

作り変えるまで、コードを直接直していただいておねがいしまーーす。

メールの件

設定タブで、メールを受け取るかどうかにチェックが入っていますか？

まず、「設定タブ」でメールを受け取るかどうか、そしてその件名、フォーム等（空欄でデフォルト）を決めていただき、複数のメールアドレスフィールド（PCのと携帯とか）のうちどれに送るかを「編集」で指定します。

「設定タブ」でメールを受け取る設定にしないと「このメールアドレスに確認メールを送信しますか 」を表示しないようにしましょう

そうですね。

表示をなくするんではなくて、グレースケールにはできないですかね。

先にメールフィールドを作った後だと、そんな指定（機能）に気付かないので、やっぱりメールが来ないということになりそうな気がするんですよね。

チェックボックスをグレーにする件
以下の変更でうまく動くと思います。

「form_setup_html.php 」
202行目
<br /><input id="mcheck2" name="mcheck2" type="checkbox" value="1" <?php echo (intval($miniSurveyInfo['notifyMeOnSubmission'])==0)?'disabled':''?> />

329行目

<br /><input id="mcheck2Edit" name="mcheck2Edit" type="checkbox" value="" <?php echo (intval($miniSurveyInfo['notifyMeOnSubmission'])==0)?'disabled':''?> />

「auto.js」
382行目あたり

showRecipient:function(cb){}
を
showRecipient:function(cb){
if(cb.checked)
{
$('#recipientEmailWrap').css('display','block');
$('#mcheck2').removeAttr('disabled');
$('#mcheck2Edit').removeAttr('disabled');
}
else
{
$('#recipientEmailWrap').css('display','none');
$('#mcheck2').attr('disabled','true');
$('#mcheck2Edit').attr('disabled','true');
}
}

ありがとうございます。

早速組み込んで、Version 1.5.6 をリリースしました。
http://concrete5.tomo.ac/index.php?cID=81

メールフィールドでチェックした後、設定で解除した時、グレースケールになるもののチェックが入ったままとういのがちょっと気になるかも。

使用不可時にチェックをはずすと「新着フォームのメール通知を受け取りますか」をあやまって、チェックはずした場合や、一時的にはずした場合に再度チェックをしないといけなくなるのでチェックはいれたままのほうがいいと思います。

tomoac様

「新着フォームのメール通知を受け取りますか？」の設定が
投稿者への確認メール発送へも有効とは認識しておりませんでした。

あらためて確認したところ、確認メールはちゃんと発送されていました。
申し訳ありません。

そこで新たな不具合？なのですが、
運営者宛てSubjectと投稿者宛てSubjectが別々に設定できますが
投稿者への確認メールもすべて運営者宛てSubjectで発送されております。
そのために、確認メールが未発送だと勘違いしていたようです。

ちなみに本文の方はちゃんと切り替わっているようです。
よろしくお願いいたします。

tomoacさんへ

subjectの件
DBにはきちんと保存されています。
メール送信時のみの問題です。

「controller.php」

523行目

$mh->setSubject(sprintf($this->senderSub, $this->surveyName));

↓

$mh->setSubject(sprintf($this->recipientSub, $this->surveyName));

に変更ですね。

でしたね。
いやはや、バグばっかし。

バグの多さは、対応の速さでカバー。

規模は違いますが、昔、WEBサーバーのApatchっていうのがそうだったそうですね。
つまり、多量の頻繁な「a patch（ひとつのパッチ）」がでることから、Apacheとなったとか。
とか書きながら少し反省。

修正して、

Version 1.5.6 としてリリースしました。
http://concrete5.tomo.ac/index.php?cID=81

どこにもメールを送らず、データベースに溜めて、管理画面から確認するという機能もありますので。

まあそうですね。

ところで、フォームの画面のデザインにこだわりたいのですが、先日、画像ブロックか
なんかでテンプレートを入れ替えることで対応できるとのことから、想起したのですがフォームブロックのデザインをテンプレートの入れ替え対応かなんかで設定できるんでしょうかね。
ご存知でしたら教えてください。

今さきほど、5.4.2でテストをしたところ
auto.jsの151行目から155行目までうまく動作してないです。
if文に問題ありのよう。まずは報告

tomoac様

フォームの画面デザインについてなんですが、
見え方自体はテーマごとにCSSで設定するものなので、
ブロック側では、CSSで制御しやすいように、
HTMLの構造を統一し、HTML要素にクラスやIDを設定していただけると
助かります。

後ほど要望をさせていただこうかと思っていたことを述べます。

1.必須項目エラー時のメッセージには DIVタグにmsgクラスが指定されていますが、
　内容確認や送信完了時のメッセージにはmsgクラスが指定されていないので、
　指定して欲しいです。
2.送信等のボタンは、はじめテーブルの中に配置されていますが、
　内容確認時のボタンはテーブルの外に配置されているので、
　同じようにテーブル内に配置して欲しいです。

以上、よろしくお願いいたします。

フォームのデザインについてはなんとかしたいと思っていますので、お教えいただければ対応いたします。

DIVタグにクラスやIDを設定すると、CSSでデザインを変更できることはわかります。ただ、デザインの自由度の幅を広げるために、どのようにDIVタグでくくればいいのかなどのノウハウがありません。

また、Concrete5の多くのマーケットプレースなどで提供されているデザインテンプレートを利用した時でも、そのテーマでデザインが変わることが望ましいと思います。すると、標準化されたIDを付けるべきだと思います。そのような仕組みなのかどうかもわかりませんが。

また、関係あるのかどうなのかもわかっていないのですが、ブロック毎にテンプレートが定義できますが、そのテンプレートでもデザイン変更ができるのではと思って調べています。

ぼちぼち勉強しますが、教えていただければ早く対応できます。

とりあえずこうしてくれないか、ということであれば、具体的にここにDIVタグをいれて、この名称のIDを付加してほしいと具体的に言っていただければ対応します。

masnogさんへ


確認画面と送信後画面のことをおっしゃられているのではないかと思うのですがあっていますでしょうか？

お手数ですが、僕もよくわかっていなくて・・・・すみません。
そこで３つのファイルを添付させていただきました。
それぞれ、formタグの中身のみを取り出したものです。できればこのファイルに書き加えてアップしていただけませんでしょうか？そうすればわかりやすいと思います。よろしくお願いします。


tomoacさんへ

現在のブロックは次期バージョンの5.4.2では動きません。
jquery関係の仕様変更が問題のようです。
その他いろいろ教えていただきたいこともございますので、
一度二人ででも、お会いするかして勉強会をしませんか？
ご返事待っています。

すみません。
先の書き込みをするさいに書き込みがあることに気付きました。
お手数でした。

勉強会の件
すみません。実はいまの会社を辞めることにしたので時間もあったのですが、新しいところに仕事を持っていって引き継ぐことになりそこでしばらくお手伝いすることになったことがあり、ちょっと時間がとれません。８月中旬以降になったら落ち着くかもしれません。
バグ修正等は、逆に気分転換として適当な時間なので対応はさせていただいてます。

具体的にご指摘いただいたところを修正しました。

ご指摘の後、ソースを見ていましたら、ご指摘の意味がわかりました。

Version 1.5.7 としてリリースします。
http://concrete5.tomo.ac/osusumeblock/form/

id="msg"は、エラーメッセージなので、エラーでないメッセージ用に、id="msg2" にしました。

classの指定は必要ですか？
私には意味や用途が分からないもので。

いえ、すみませんでした。余計なことをしてしましまいた。
ひとつmsgはmsgとmsg2に分けるのが気になりました。
たとえば errormsg と checkmsgとするなど分かりやすい名前をつけることが必要ですよーーー。
参考にしてください。

そうですね。
ただそういう細かいことより、テンプレート対応が必要だとわかりました。

フォーム用のアドオン、"Form Tableless Layout"というのを見つけました。
これをインストールするとフォームのタグが<div>タグになります。

これ、別のスレッドにします。

tomoac様

テーマの変更に拡張フォームブロックの外観も統一するためには、
標準フォームブロックの構造やクラスを継承するのが一番だと思います。
なぜなら、標準のフォームブロックで使用されているクラスやIDのスタイルであれば
テーマ内のcssで指定されている可能性が高いからです。

標準フォームブロックの構造、クラス、IDをまとめてみました。
1.先頭にアンカータグを配置
2.アンカー以下のブロック全体をformブロックで囲んでいる
　formのIDは "miniSurveyView"+bID 、クラスは"miniSurveyView"
3.目に見えるフォーム要素はテーブル内に配置
　tableにはクラス"formBlockSurveyTable"を指定
4.左のtd（class="question"）に質問の見出しを表示
　右のtd（classなし）にフォーム要素を配置
5.テーブル最下行の右側tdに、submitボタンを配置
6.完了やエラーメッセージはform最上部にdivタグ（id="msg"）内に配置
7.エラーメッセージはさらにdivタグ（class="error"）で囲まれている

拡張フォームブロックは標準フォームブロックをベースに開発されているので
上記のほとんどはそのままなのですが、独自に拡張された部分がこれらのルールから
はずれている箇所があります。

それが前回あげさせていただいた、以下の2点です。
・id="msg"が指定されていないメッセージがある
・送信等のボタンがテーブル内に配置されていない。

また、今回"msg2"というidを増やされましたが、そうではなく(7)のように
エラーメッセージをdivタグ（class="error"）で囲むのがベターです。

ちなみにIDとクラスについてですが、機能は似ていますが、その違いは、
IDはページ内で必ずユニークな要素ですが、クラスの方は同じクラスの要素が
複数あっても構わないモノです。
今、"msg"はidで指定していますが、本来はクラスで指定するべきだろうと思います。

以上、よろしくお願いいたします。

7/15の投稿で、
1.メッセージのdivタグに"msg"クラスが指定されていない
は
1.メッセージのdivタグにid="msg"が指定されていない
の間違いでした。

ややこしいことで申し訳ありません。

ご教示ありがとうございます。

すみません。結果、どうなんでしょう？

>拡張フォームブロックは標準フォームブロックをベースに開発されているので
>上記のほとんどはそのままなのですが、独自に拡張された部分がこれらのルールから
>はずれている箇所があります。
>
>それが前回あげさせていただいた、以下の2点です。

これは解決しましたでしょうか？


＞また、今回"msg2"というidを増やされましたが、そうではなく(7)のように
＞エラーメッセージをdivタグ（class="error"）で囲むのがベターです。

msg2は、エラーでなく単なるメッセージなので、エラーと同じにはしなかったのですが、divタグ（class="error"）で囲むほうがいいでしょうか。


＞ちなみにIDとクラスについてですが、機能は似ていますが、その違いは、
＞IDはページ内で必ずユニークな要素ですが、クラスの方は同じクラスの要素が
＞複数あっても構わないモノです。
＞今、"msg"はidで指定していますが、本来はクラスで指定するべきだろうと思います。

classで範囲を限定することで、同じネイ省のID名の重複を避けるということでしょうか。

tomoac様

1.5.7確認をいたしました。
ちなみに修正の観点は、標準フォームブロックの構成に近づけることであって
良い悪いとは別問題だということをご承知ください。

>これは解決しましたでしょうか？
　ありがとうございます、ほぼOKなのですが、ボタンを配置する最下行のtrにtdがひとつになっているのと、
　不要なbrタグがはいっています。
<tr>
<td colspan="2"><input type="hidden" name="state" value="2"><br />
<input class="formBlockSubmitButton" name="Submit" type="submit" value="送信する" />
<input class="formBlockSubmitButton" name="Submit" type="submit" value="戻って修正する" /></td>
</tr>
　　　　　　　　↓
<tr>
<td> </td>
<td>
<input class="formBlockSubmitButton" name="Submit" type="submit" value="送信" />
<input class="formBlockSubmitButton" name="Submit" type="submit" value="戻って修正する" />
</td>
</tr>

>msg2は、エラーでなく単なるメッセージなので、エラーと同じにはしなかったのですが、
>divタグ（class="error"）で囲むほうがいいでしょうか。
　
　メッセージを囲むdivのIDは"msg2"→"msg"に変更して欲しいです。
　そうでないと、id="msg2"へのcssスタイルをテーマに追加する必要が発生します。

　メッセージのhtml構成は以下のように整理されればよろしいかと
　<div id="msg">
　　ここに普通のメッセージ
　　<div class="error">ここにエラーメッセージ</div>
　　<div class="error">ここにエラーメッセージ２</div>
　</div>

>classで範囲を限定することで、同じネイ省のID名の重複を避けるということでしょうか。
　いえ、IDは必ず一意でなければならないのに、"msg"なんてありきたりな名前をつけるのは
　重複する可能性が高いため不適切なID名だと思っています。
　concrete5的には、formのid "miniSurveyView"+bID のように bID を加えたID名にする
　のがベターかなと思います。

＞　ありがとうございます、ほぼOKなのですが、ボタンを配置する最下行のtrにtdがひとつになっているのと、
＞　不要なbrタグがはいっています。

ボタンの行はカラムが１列がいいと思って、colspan=2にしてtdを一つにしました。教えていただいたようにすると、ボタンが右に寄りますが、それがいいという意味でしょうか。

brはとります。

＞　メッセージを囲むdivのIDは"msg2"→"msg"に変更して欲しいです。
＞　そうでないと、id="msg2"へのcssスタイルをテーマに追加する必要が発生します。

評判の悪い、msg ですが、元のソースがmsgだったのでそのままにしています。
変更すると、formとの互換性に問題が出るかと思っていてそのままにしています。

msg2 のことはわかりました。エラーは<div class="error">で見た目が変えられるんですね。msg2, msg3 もmsg にします。


直接関係ありませんが、このさい教えてほしいですが、一口でいえばclassとidはどういう基準で使い分けるんですか？

>ボタンの行はカラムが１列がいいと思って、colspan=2にしてtdを一つにしました。
>教えていただいたようにすると、ボタンが右に寄りますが、それがいいという意味でしょうか。

どちらがよいとかではなく、最初の送信フォームのボタン配置がそうなっているので
統一するならという程度の理由です。

>評判の悪い、msg ですが、元のソースがmsgだったのでそのままにしています。
>変更すると、formとの互換性に問題が出るかと思っていてそのままにしています。

はい、　標準フォームとの互換性のために、そのままにするほうがよいと思います。

>msg2 のことはわかりました。エラーは<div class="error">で見た目が変えられるんですね。

はい、ちなみに私はcssで、クラスがerrorなdivは赤く強調した表示に指定しています。

>直接関係ありませんが、このさい教えてほしいですが、一口でいえばclassとidはどういう基準で使い分けるんですか？

まず、idとクラスの違いは、先に述べたとおりidはページ内で一意でなければなりません。
そのため、idはページ内に必ず一度しか現れない要素に指定します。
例）ヘッダー、フッター、サイドバーなど．．．
複数表れる要素にidを指定する場合は、重複しないシリアル番号を付加したid名にします。
例）msg0001, msg0002...

で、具体的にどのような違い（効果）があるかというと
1.スタイルシートでの優先順位(重み付け)が違い、idでの指定が最優先です。
　局所的にスタイルを変更したいような場合には、idを使うことがよくあります。
2.idを指定することで、javascriptなどで要素を一発で取り出し可能です。
　値の読み書きや、表示のオンオフをしたい要素には、よくidを指定します。
3.idはページ内の位置指定にも使えます。<a href="#header">ページ先頭へ</a>

このような効果が欲しい場合にはidを使います。