スタッフブログ
xelfinderで画像をUPしてブログ記事を書こうとしたらアップロードした画像が表示できずに"No input file specified."になって困ってたんですが、coreserverでの有名な問題みたいですね。
No input file specified.と出たら ≫ 運営堂
上記ページにあるとおり、.htaccessに
mod_gzip_on Off
を追加したら画像が表示されるようになりました。
あけましておめでとうございます。昨年末に高尾に引っ越した龍司です。
せっかく周りにハイキングコースがたくさんあるので、トレイルランでもやってみようかなぁと思っていろいろ検索してたら「ヤマレコ」というサイトを発見しました。
ヤマレコ - 登山やハイキング、クライミングなどの記録を共有できる、登山の総合コミュニティサイト
細部まで良くデザインされてて気がつくのが遅れましたが、このサイトもXOOPSで構築されてるんですね。
ちょっと記憶を頼りに他にXOOPSでできた趣味コミュニティサイトをリストアップすると下記のようなサイトもあります。
ランニングサークルWindRun(ウィンドラン） - 風のように走る
趣味活動では活動記録を残したり、ハウツーの情報交換があり、イベントでの交流などがありますが、XOOPSにそれらの活動に対応した拡張モジュールがあるから趣味コミュニティサイトで良く採用されるのでしょうね。
いろんなXOOPSサイトを見ていると「あ、これは今考えてる○○に応用できそうだな」って発見もあって楽しいものですね。
そうそう発見といえば、勉強会で他の方が作られてるサイトを見せてもらうのも良い刺激がえられますね。
1月は1月11日（土）にXOOPS Cube初心者勉強会が新宿で、1月16日に神戸でもくもく会が予定されてるので、時間のある方は参加しては？
NetCommons2のmaple/nccore/db/DbObjectAdodbをみてたら
StartTrans(), FailTrans(), CompleteTrans()なんてメソッドがあって、トランザクションに対応してそうな雰囲気だが、これは罠。
NetCommon2で使ってるのはAdodbのmysqlドライバで、このmysqlドライバが残念ながらトランザクションに対応してない。
なので、Innodb使っててトランザクション処理したいときは自前でexecute('BEGIN')とかするしかないようだ。
NetCommons2はSmartyのdefault_modifiersを利用して自動で全変数にエスケープかかるようになってるが、これが罠。
このdefault_modifiesって表示だけでなく、変数を使うところ全てで適用されるので、下記の様なコードで問題になる。
<{foreach from=$arrayList item=item}>
<{$item}>
<{/foreach}>
from=$arrayList で$arrayListの中身をSmarty::_run_mod_handlerでエスケープかけようします。
_rum_mod_handlerで、配列の中身すべてにdefault_modifiersで指定されたmodifireがかかります。
NetCommons2の場合、escapeです。さらに<{$item}>を表示するときにもdefault_modifiersで指定されたescapeがかかります。
結果、二重にエスケープされるわけです。
これを避けるにはsmarty:nodefaultsを利用してdefault_modifiersが適用されないように、下記の様なコードにします。
<{foreach from=$arrayList|smarty:nodefaults item=item}>
<{$item}>
<{/foreach}>
Smartyのバグ ～default_modifiers～ : アシアルブログも参考にしたんですが、
<{if isset($foo)}>
みたいなときもエスケープかけようとするので、これも下記みたいにしないとダメなようです。
<{if isset($foo|smarty:nodefaults)}>
ブログに書いたつもりが下書きのままパソコン内に記事が眠ってて焦った龍司です。
2013年10月22日にEngineYardさんで開催されたSendGrid Nightに参加してきました。
EnginYardさんでは、定期的に1つのPaaSを掘り下げた勉強会を開催していこうと考えてるそうで、その取り組みが「○○ Night」みたいです。
1回目はサーバ監視サービスの「NewReric」をとりあげた「NewReric Night」を開催、2回目はメール配信サービスの「SendGrid」をとりあげる「SendGrid Night」ってことでした。（今後どんな○○Nightが開催されるか楽しみですね。）
以前EngineYardの安藤さんにSendGridの存在を教えてもらっていて興味をもったんですが、今回の勉強会に参加してみるまで自分がなんでSendGridに興味もったのかをすっかり忘れてました(^^;
それが参加してみてやっと何故興味をもったか思いだすことができました。
何故興味をもったか？
それは「メールの大量配信をちゃんと行うのはすんごいめんどくさいこと」だったからです。
会員制のWebシステム開発を何度もやってると中にはメールを大量配信するケースも出てきます。これをまともに実行できるようにするのがとてもめんどくさかったんですね。
メール配信をちゃんとやろうとすると、なにがめんどくさいか
SendGridNightでも話しがあったのですが、今やメールの9割が迷惑メール。各プロバイダや携帯キャリア、メールソフトそれぞれが迷惑メール対策をあれこれ実施しています。
そのおかげで迷惑メールに触れる機会が減ってるんですが、ちゃんとしたメール配信をしようとすると、この各種の迷惑メール対策でフィルタリングされないように、送信側もあれこれ設定したり、配信ペースを押さえたりと面倒なことがいっぱいでてきます。
さらにサーバのスペックの問題も発生します。メール送信って他のサーバとの通信が発生するのでサーバにけっこう負担かけるんですよね。それにあわせてサーバスペックあげると、メール配信以外の普段ではオーバースペックでハイコストの原因になっちゃうし、スペックさげるとメール配信がいつまでも終わらないなんてことが起こったり、けっこうムキーーーってなったりします。
エラーメールの対処をどうするかってのも頭の痛い問題です…
ほんと、送ったメールがちゃんと届くようにする って結構大変なことだったのを勉強会を通してよーーーーっっっく思いだしましたよ…
で、SendGrid。
SendGridはWebサービス、Webサイトをつくってるときに発生するこういう「めんどくせーーー！！」と叫びたくなるメール配信系をうまいことやってくれるサービスなわけですね。
というわけで基本的なメール配信はもちろん問題なくできるようになってますが、それだけでなくプラスアルファでいろいろ便利そうなサービスになってます。
SendGridが便利そうなポイント
自分でメールサーバをたてる大変さから解放されるのが一番のポイント。
他の便利ポイントとしては
- 送信ログの確認ができる
- 配信されたか拒否されたかちゃんとわかります。
- ParseAPI使うと受信メールをきっかけにWebへメール内容をPOSTなんてこともしてくれる
- SMTP API使うと一度に1000通ぐらい送信とか宛名の置換とかもできるそうです
- 無料で毎月6000通まで送信OKらしいので、メール送信テスト時にコストかからんのもいいです
ってあたりが個人的にはヒットでした。
最近ちょっとWindowsAzureをうまいこと利用できないか試行錯誤してるんですが、WindowsAzureはメール送信できないってことで早速SendGridの無料プランをちょっと使わせてもらいました。
これをきっかけにちょこちょこ利用できたらなぁと思ってます。
XCL2.1からXCL2.2にしたときにXCL2.1付属のPM（PrivateMessage）をやめてMessageモジュールを導入された方も多いかと思います
このMessageモジュールはインストール時にPMのデータを移行する仕組みが備わってたのですが、ちょっとしたバグがあって移行できませんでした。
というわけで、元からあった移行コードにちょっと手をいれて、後からでもpmモジュールのデータをmessageモジュールに移行できるようにしてみました。
こちらからダウンロードできます。
XOOPS_ROOT_PATH直下にアップロードしたら、XOOPS_URL/pm2message.phpにアクセスしてください。
pmにあるメッセージがmessageモジュールに移行されます。
2度3度起動してもいいように、from, to, subject, bodyが全く同じメッセージがすでにmessageモジュールにあったら、そのメッセージは移行しないようになってます。
messageモジュールの自動削除で消えてしまったメッセージがpmに残ってるときにサルベージするのにも使えると思います。
htmlを書く感覚で作れるので、通常のページであまり書き換えが行われない固定的なページにはpicoを使うことが多いです。
私の場合、以前から使ってきて必ずカスタマイズする部分や必ずデフォルトの一般設定から変更するという作業が発生していました。
今回それらについてデフォルトのままインストールしてもカスタマイズやデフォルトの一般設定を変えなくてもそのまま使えるようにpicoをカスタマイズしてみました。
いつものカスタマイズではなく、picoの本体自体にカスタマイズをして再配布可能なように作りました。コアチームにpullリクエストをしてありますので、もし賛同が得られて、取り入れてもらえれば今後のpicoがこのように変わると思います。
RYUSの場合、実績ページなどをpicoで作っています。そのコンテンツを元に改造前と後を見比べてみましょう。
実績ページは3つのカテゴリに分け、その中にコンテンツを置いています。
今現在ですとこのような構成になっています
実績・事例←モジュール名をこのように変更してある
└社内システム開発←カテゴリー名
└社内システム開発事例←コンテンツ
└WEBシステム開発←カテゴリー名
└WEBシステム開発事例←コンテンツ
└その他の事例←カテゴリー名
└お客様事例 -デジタルハリウッド大学大学院教授 三淵啓自先生 ←コンテンツ
└お客様の声 株式会社ノード様 ←コンテンツ
これをデフォルトのpicoで表示したものと、pico自体にカスタマイズをしたもので見比べてみます。
まずはモジュールのトップページ
【改造前】
上記の ピンク色の文字 で書いた部分をいつもカスタマイズしていましたが、新しく改造したpicoで表示するとデフォルトでこのようになります。
【改造後】
これらは一般設定で選択することで、今までの表示のようにも出来るようになります。
一般設定
同様にカテゴリーのトップページも変更しました
【改造前】
【改造後】
メニュー、RSSのリンクはデフォルトでは出さないようにして、トップという表示もモジュール名にしました。
コンテンツページです。一番よく修正するのが表題を表示することでしたのでそのようにしてみました。
【改造前】
【改造後】
一般設定で以前と同じ表示にも出来ます。
その他、今までデフォルトで「はい」になっているけれど大概の場合「いいえ」としていた項目を最初から「いいえ」にしてみました。それらの項目は以下のものです。
ページナビゲーションを表示する
印刷画面へのリンクを表示する
友達に紹介するリンクを表示する
tellafriendモジュールを利用する
投票機能を利用する
今時点でこのpicoのソースはこちらに置いてあります。
このページの右下の方にある Download ZIP をクリックするとzipファイルでダウンロードすることが出来ますので、試してみたい方は是非どうぞ♪
PHPでファイルアップロードサイズの上限値は upload_max_filesizeで設定します。 .htaccessなら下記の様な感じですね。
php_value upload_max_filesize 256M
この数値を変更したときに合わせて見直しておきたい設定項目が2つあります。
memory_limit と post_max_sizeです。
この3つの設定項目の数値はそれぞれ下記のような関係である必要があります。
memory_limit > post_max_size > upload_max_filesize
ここ、気をつけてないと、upload_max_filesizeは増やしたけど他のサイズが小さくてファイルアップロードがうまくいかないということが発生します。
私がはまったパターンでは、post_max_sizeが小さくて大きなファイルをアップロードしようとすると、$_POSTが空っぽになってしまい、いきなり別ページに飛ばされるなんてことがありました（^^； # 最近のフロントコントローラ方式だとまずこうなりますね
xupdateで"SSL certificate problem: unable to get local issuer certificate"となった時の対処法
Ryuji : XOOPS » モジュール 2013/10/3 10:06
XOOPS X(ten)では、xupdateというモジュールやテーマのダウンロードとアップデートをしてくれるモジュールがあります。（次期XOOPS Cube Legacyコアにも取り込まれる予定です）
このxupdateでモジュール等をダウンロードしようとしたときに、サーバによっては次のように"SSL certificate problem: unable to get local issuer certificate"というエラーがでてダウンロードに失敗することがあります。
このときは、xupdateの一般設定で「cURL: SSLホスト認証をしない」を「はい」に変更すると正常にダウンロードできるようになります。
さくらのレンタルサーバスタンダードでこの症状に遭遇しましたので、さくらのレンタルサーバご利用の肩は設定変更して試してみてください。
PHP5.4対応の一番の問題として htmlspecialchars関数 の問題があります。この関数はXSS対策に良く用いられる関数なので、Webシステムで利用されないことはまずありえません。
そのhtmlspecialchars関数がPHP5.4以降、文字コードの指定がないとデフォルトで文字コード「UTF-8」だと判断して動作するようになりました。
これが問題になるのはかつてPHPプログラムで文字コード「EUC-JP」をメインに使ってた頃のプログラムです。（UTF-8以外だとダメなのでSJISとかももちろんダメですけどね）
XOOPSもかつてはEUC-JPを使うのが主流でしたので、その頃に構築したサイトはPHP5.4へ移行するとこの問題にぶちあたります。
この問題が発症すると症状として何が起きるかというと文字列の抜け落ちが発生します。XSS対策でサニタイズしている文字列なんかはまるごと抜け落ちるので、たとえば、掲示板とかで枠線とか外観は正常に表示されるのに書き込みメッセージが全く表示されないというような症状になります。
対処法としては、XOOPSなら全般設定で言語を「japanese」から「ja_utf8」へ変更することで回避できます。
他のシステムでも内部エンコードをutf-8にしてあげればほぼ回避できると思います。.htaccessで設定変更できるなら下記の様にします。
php_value mbstring.internal_encoding UTF-8
ちょっとしたプログラムであれば、これだけで問題解決することもあると思います。
# もちろんDBとの接続やファイルの読み書きがある場合は、そのやりとりの文字コード変換をあわせていく必要はありますけどね。
