伊藤清徳の垂直落下式ムーンサルトプレス

PerlとかPHPとかMySQLとか...がんばっても8割だ。

Category: 個人的備忘録 (page 1 of 2)

WP3のマルチサイト化1歩目

wordpress3.0日本語版がリリースになって、
このブログも3.0にバージョンアップしてみました。
 
今のところ、テーマやプラグインは問題なく動いているっぽいです。

3.0の目玉は、2.xまでMUと呼ばれていた、マルチサイト運営に対応したバージョンが統合されて、
通常のWPでもマルチサイト運営ができるようになったことですね。
 
ってことで、ちょっと試してみました。
 


最初、デフォルトの状態で、ボタンをポチっとすればサイトがいっこできるんだー!
とか思ってたんですが、そうはいかないようです。
 
基本的な設定方法は、
このあたりを見ればOKでしょう。
(リリース候補版の頃に書いた記事のようですが、同じです。)
 


 
以下は私の行った設定です。
 


 
サブサイトは、サブドメインかサブディレクトリが選択できます。
サブドメを選択してしまうと、DNSの設定が大変ですし、このブログの場合、Pleskを導入してるので、ますます面倒だということで、とりあえず、サブディレクトリでやってみました。
 
WPネットーワークを作成したときwp-cron.phpの手動変更をしろと指示されますが、
ここに表示される設定はサブドメ利用を前提としたものなので、

 
define( 'SUBDOMAIN_INSTALL', true );
 

これを

 
define( 'SUBDOMAIN_INSTALL', false );
 

と変更します。これでサブディレクトリでのサブサイト作成が可能です。
 


 
次に、.htaccessの設定しろとも指示されます。
これが、そのまんま貼っつけたらやられました。
 
通常の設定においてパーマリンク設定を変更していると、
そのまんま貼っつけたら、全ページがないことになっちまいましたー!
 
ってことで、一旦管理画面でパーマリンクを設定し直して、
作られた.htaccessと、WPネットワーク作成時作れと指示された.htaccessの違いをじーっと見ると、
何行か増えているのがわかるので、そいつを追加したらうまくいきました。
 


 
ここまでやれば、あとはボタンぽちっ!でサイトが追加されますー。
 
とりあえず、作ったってとこまでの報告でございます。

imagick手始め

PHPのImagickで四角形とか描画とかしなきゃいけなくなったので、調べたら、うわぁ。。。全然参考になるところないね・・・。

ということで今日まで分かったことをメモメモ。


線を描いたりフォントで文字書いたりするのは、ImagickDrawオブジェクトを利用

このImagickDrawオブジェクトをImagickオブジェクトへはっつける。

出力

という手順を踏むらしい。

どうやらファイルに出力しなくても直接バイナリを得てPHPで出力も可能ということ。


じゃあやってみよう!

<?php

//四角形を描く
$draw = new ImagickDraw();#ImagickDrawを作って... $draw->line( 0, 0, 250, 0);#右
$draw->line( 250, 0, 250, 120);#下 $draw->line( 250, 120, 0, 120);#左 $draw->line( 0, 120, 0, 0);#上 #↑このように線を引く。多角形を描く「polygon」メソッドもあり、こっちでもいいじゃないかなぁと... //Imagickオブジェクトを作成。実際の出力とかはこっちでやる! $image = new Imagick(); $image->newImage(252, 122, new ImagickPixel('#FFFFFF')); #↑新しい画像(キャンバスみたいなもの??)を作成 # 線の幅分を加算しなきゃいけないことに注意。 $image->setImageFormat('gif');#画像フォーマットをgifに設定します。 $image->drawImage( $draw );#描画した四角形を画像に貼り付け! header('Content-type: image/gif');#適切にMIMEタイプを設定して... echo( $image->getimageblob() );#「getimageblob」メソッドを使うとバイナリを得ることができるのでそのまま出力。 ?>

↑こんな感じ。。。うーむ・・・理屈は理解したが、、、慣れが必要だ・・・。

とりあえず第一関門突破。ここにあとは文字を流し込まなきゃならないので、それはまた後日。

IEでsubmit()

IEでJSからsubmit()できないことがある件。


<a href="javascript:;" onclick="doSubmit();">送信!</a>

<form action="test.php" method="POST" id="testForm" name="testForm">

<input name="testVal" type="hidden" value="テストだよ">

</form>

上記のようなHTMLがあるとして、

function doSubmit(){

	document.getElementById('testForm').submit();

}

上記のようなJS関数を実行してフォームを送信しようとすると、

Firefoxでは問題なく送信できるが、IEでは送信できない(>_<)


まず、HTMLを

<a href="javascript:void(0);" onclick="return doSubmit();">送信!</a>

<form action="test.php" method="POST" id="testForm" name="testForm">

<input name="testVal" type="hidden" value="テストだよ">

</form>

と修正して、

function doSubmit(){

	document.getElementById('testForm').submit();

	return false;

}

JSはこのように変更。

何をしたかというと、<a>のhrefをvoid(0)で無効化して、さらに、onclickはfalseを返すようにする。IEではどうやら、JS関数の中のsubmit()より、<a>の働きが優先されるようで、これらをすべて無効化する必要があるよう。

これで半日悩んだ。
ある意味正しいような、でも、なんか納得いかない(>_<)

IEはツンデレだ・・・いやツンツンしてるだけか(爆


ちなみに、

<a href="javascript:void(0);" onclick="return doSubmit();">送信!</a>

<form action="test.php" method="POST" id="testForm" name="testForm">

<input name="testVal" type="hidden" value="テストだよ">
<input type="submit" name="submit" id="submit" value="送信" />

</form>

こんな風に<form>タグの中に「submit」という名前の要素が入ると、submit()ができなくなる。これも注意。

JSは何でもかんでもオブジェクトなので、同じ名前のものがあれば、当然そちらで上書きされる。

迂闊な名前をつけるのはやめよう。

EC用CMSメモメモ

オープンソースECシステムをメモメモ

・osCommerce
だいぶ古くからあるシステム。
今開発やコミュニティがどうなってるのか不明・・・。
選択肢には入らない・・・かな。

・ZenCart http://zen-cart.jp/
osCommerceからの派生プロジェクト
安定度は高いが、環境によってインストールにかなり苦労する。
ZenCartインストールを公式に保障している
ホスティングサービスを利用したほうがいい。
いかんせん、設計が古いので、それなりの見た目にはなってしまう。

・EC-CUBE http://www.ec-cube.net/
近頃よく使われるEC用CMS。
日本製なので、決済モジュールなどが充実しているのがいいところ。
こちらも環境によってはインストールに苦労する。
バグが多くて困る。。。
MySQLを使えるようにはなっているが、使わないほうがいい。
PHPの知識がない人は・・・使わないほうがいいかも。
それでも無難に使えるから、まぁ合格点。

・ONE/DEPO http://www.onedepo.jp/index.html
ダウンロード販売の機能やら、簡易的なショッピングモール機能など、
他にない機能満載のECシステム。
データベースがPostgreSQLを使っているので、商品数もかなりいける。
決済モジュールがないので、
独自に決済方法を組み込まなければならないのが難点。

・Magento http://www.magento-jp.com/
MySQLを使いながらかなりの商品数を扱えるというすばらしいECCMS。
実績では、10万点を越える商品を扱ったサイトもにも耐えられたとのこと。
画像処理システムなどかなり多くの機能を抱え込んだシステムなので、
環境を選ぶのが難点で、
基本的にVPSか占有利用サーバーでの利用を考えたほうが良い。
海外製で、まだ日本コミュニティは成長途中なので、資料が少ない。
決済モジュールはいくつかあります。
個人的に、日本コミュニティの中心の方とお話させてもらったことがありますが、
非常に人当たりが良かったので、
Magentoは今後何某かの形で関わっていきたいなと思っています。

他にも沢山ありますが、使えそうなのはこれくらいですかね。
私はEC-CUBEとMagentoを案件に合わせて選択という感じでいくことになりそうです。

SET NAMESはダメなんだ

近頃はトランザクションを使いたいので、データベースエンジンの選択はもっぱらSQLiteかPostgreSQL。(別にMySQLがトランザクションないわけじゃないけど)
そんな話はまぁどうでもよくて。
久しぶりにPHPでMySQL使ったら文字化け起こしたので、
「SET NAMES」
を使おうとしたら、どうもPHPからSET NAMESを使うのはご法度っぽいΣ( ̄□ ̄;

こちらのサイトに良くまとめられている。

なるほど。

早速対策しなくちゃ。

要するに、MySQLが悪いわけじゃなくて、PHPがアレなのねと。。。

ちょっと前には当たり前のノウハウも、今やバッドノウハウ。
毎日勉強しないと置いていかれるわい。

ajaxライブラリのライセンス

ajaxライブラリを含んだソフトの販売をすることになりそうだったので、これまであんまり気にしたことがなかったライセンスを確認した覚書。

prototype.jsとjQueryはMITライセンス。
YUIはやっぱりYahoo!が大好きなBSDライセンス。

主要なところは全部緩いライセンスだ(^-^)/

ソースはオープンである必要があるけど、自分が開発したWEBアプリに組み込んで売る分には問題なし!

EC-CUBEをPostgresqlにするときの注意。

先日までMySQLでEC-CUBEサイトを構築中。

だったのだけれど、商品数1,000を越えたあたりでサイトが激重に。
調べたらMySQLでEC-CUBEつかうのはアレなんですね・・・。

EC-CUBEが使っているMySQL用のクエリがダメダメみたい。
一つ一つSQL文を書き直せばいいのだろうけれど、
そんなのあまりにムダな作業だ!!!

ってことで、PostgreSQLに変更し、
EC-CUBEを意気揚々と再インストールっ♪

でも、接続できないみたいなことを言ってくる?

はぁ?


MySQLにイージーさに慣れすぎて色々忘れてた。
ポスグレってpostgresql.confとpg_hba.confの設定が必須だっけ?
でググったらありましたよ。

http://www.dotconf.com/modules/dev/content0001.html

弊社はクララオンラインさんのPlesk導入サーバーを愛用させてもらっていますが、こちらの記事も同様のサーバー構成(OSは違いますが)のようですから、このままやれば良いだろうーーー。という希望的観測で今日はここまで。眠い。なんか頭イタイ。深夜0時。

ネタ元の記事の方。多謝です。

成功後、この記事に追記します。

【追記&結論】

あれこれ設定を変えてもうまくいかない(>_<)
と12時間近く悩んだあと発見。

クララオンラインのサーバーでPHP→ポスグレ接続するときは、
ホスト名を指定すると接続できません(>_<)

で、EC-CUBEのデータベース接続はどうなってるかと言うと、
PEAR_DBを使ってポスグレやらMySQLに接続をしてますが、
デフォルトの接続文字列が、

pgsql://username:password@hostname:port/dbname

という書式が使われています。ホスト名が見事に設定されています。
ってことで、これを

pgsql://username:password@unix()/dbname

となるように、install.phpとSC_Initial.phpを変更すると接続できるようになりました。
install.phpの方は書き換えなければならない箇所が複数あるので、
見落とさないように注意。

なぜ、このようにしなければならないのか・・・。
まさかこんなところで丸半日悩むとは思いもよりませんでした。

IE8のレンダリングモード

IE8のレンダリングモードについて。

用意されたレンダリングモードは全部で3つ。

・IE8標準モード
・IE7標準準拠モード
・互換モード

2つ目までは、まんま。
「互換モード」はIE5系統と「互換」モード。(←IE7までもあった。)

3つもあるのか・・・。
IE9の話がそろそろ出てきているけど、
そのときはIE8互換モードというのができているのかな・・・。
制作者泣かせ。
(そういえば、8の次はIEシリーズをやめて、
 C#で開発した新ブラウザになるなんていう話もありましたね)

ちがいはCSSのプロパティのサポート範囲だと思うのですが、
IE8については、リリースされたばっかなのでまだ特有の不具合とかあるかもしれないです。

(IE7のときは、SJISで書かれたサイトが真っ白になるという妙な不具合がありましたね。
 最近は不具合の多いSJISでサイト作ることは少なくなったのでいいと思いますが。)



レンダリングモードの選択は、METAタグでやります。

DOCTYPE宣言で切替もできるみたいなんですが、

大体、レンダリングモードに関わらず同じDOCTYPE宣言すると思います。
(ちなみに、DOCTYPE宣言をつけないと勝手に互換モードになるので、
 つけたほうがいいですね。)

で、書くMETAタグは、

<meta http-equiv="X-UA-Compatible" content="値" />

です。
「値」のところへ採用するレンダリングモードを書きます。

IE=8 IE8レンダリングモード
IE=7 IE7レンダリングモード
IE=5 互換モード。
IE=EmulateIE8 DOCTYPE宣言に基づいて、
IE8モードか互換モードでレンダリング
IE=EmulateIE7 DOCTYPE宣言に基づいて、
IE7モードか互換モードでレンダリング

「IE=8」や「IE=7」にすると、柔軟性がなくなってしまうので、
「IE=EmulateIE8」「IE=EmulateIE7」にするのが妥当でしょうか。

2009年6月現在では、
HTMLなら

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

XHTMLなら

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

あたりで、DOCTYPE宣言した上で、

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />

としておいて方が無難かなと思います。

error_reporting

PHPはphp.iniなどの設定により同じプログラムを書いても挙動がかなり異なるのがイヤだ。
(がゆえに脆弱性のあるコードを書いちゃったりするし。)

配布プログラムやサーバー環境の条件によっては、
「Notice: Undefined index: … 」
というようなエラーが吐き出されて、そのまま続けて正常な動作の結果が表示される場合がある。

こういう場合は、php.iniだったり、.htaccessだったりで、
「error_reporting」の設定が「E_NOTICE」レベルの警告まで発するレベルの設定がされていることが多い。
PHPが利用できるほとんどの環境はそうなっていないようだが、
一部LinuxOSのデフォルトの設定をそのまま使うと、
「E_NOTICE」レベルの警告を発するようになるらしい。

ってことで、上記のようなエラーが吐き出される場合は、
php.iniなり、.htaccessなりで、
「error_reporting」の値を「E_ALL & ~E_NOTICE」に設定しましょう。

「display_errors」をオフにしちゃうとかするともっとラク?
でも、PHPの旨みであるトライ&エラーがやりにくくなるので、
そんなことするくらいなら、PerlやRubyでも使うしね。

って調べたら、各スクリプトからも「error_reporting()」関数で指定できるんだね。
▼詳しくはこの辺を
http://jp.php.net/manual/ja/function.error-reporting.php

ちなみに、「Blogn+」というブログツールでよく起きてるみたいこのエラー。
おそらく、このサイトで配布しているPHPシステムでも発生するはずですから、
設定やスクリプトを修正したうえで利用してください。


【2009年5月28日追記】
.htaccessに書くなら
php_flag display_errors 1
php_value error_reporting 2039

こんな感じ。

【2009年6月2日追記】
まちがってた。

php_flag display_errors 1
php_value error_reporting 6135

こっちが正解だ。

なでしこプラグインでFilemakerのスクリプト実行(できるといいな編)

この記事でやろうとしていることは、なでしこプラグイン自体が対応しちゃいました(^-^;
クジラ飛行机さんのパワーには圧倒されるばかり…

なでしこはWindowハンドルを使ってメッセージ送信などができる機能をばっちりそろえているので、
Filemakerのメニューバーの「スクリプト」に配置したスクリプトを実行できるといいな。と思う

まずは、本家なでしこで挑戦。


!WM_COMMAND = $00000111。
TARGETSCRIPT = 0。
TARGETSCRIPT = 32768 + TARGETSCRIPT。
TARGETWINDOWは、「ターゲットのウィンドウ」。
HANDLEは、「FMPRO7APP」を窓ハンドル検索。
TARGETHANDLEは、HANDLEのTARGETWINDOWを窓ハンドル内検索。
//PostMessage(TARGETHANDLE,WM_COMMAND,SETCOMMAND,0)。//←間違えていました!!
PostMessage(TARGETHANDLE,WM_COMMAND,TARGETSCRIPT,0)。//←こちらが正しいです。


●1行目
WindowsAPIで使う定数を定義します。

●2行目・3行目
メニューのスクリプトに割り当てられたスクリプトは、
上から順に「32768」「32769」「32770」…と「32768」から昇順にIDが振られています。
このIDを利用して、WindowMessageをPostMessageかSendMessageで送ってやればいいわけです。

●3行目~5行目
Filemakerのスクリプトは、データベースファイルごとに設定できます。
したがって、Filemakerのメインウインドウにメッセージを送ってしまうと、
別のファイルのサブウインドウがアクティブになるなどして、
期待していないスクリプトが起動してしまう可能性があります。
そこで、まず、「FMPRO7APP」でメインウインドウのハンドルを検索し、
その中の指定したタイトルを持つウインドウのハンドルを検索します。

●6行目
あとはこれまでのデータをもとにPostMessageしてやればOK。

ってわけで、本家なでしこでは問題なく動きました。
cnakoでは、PostMessage関数をDLLから先に呼び出しておく必要があります。


●PostMessage(hWnd,Msg,wParam,lParam) = dll("USER32.DLL",
"BOOL PostMessageA(
HWND hWnd,
UINT Msg,
WPARAM wParam,
LPARAM lParam
)")

大体こんな感じですかね。

さて、では早速これをなでしこプラグインで。。。。

と思ったら、、、、問題発生。

たとえば、これら命令をファイルメーカーのスクリプト中の計算式から呼び出すとします。
すると、スクリプトは現在起動中なのですから、
ウインドウメッセージを送ったところで、スクリプトの実行を受け付けてくれないみたいです。
「秒待つ」とかやっても、すべての命令が終わるまで、
NAKO_eval()関数は待ってくれる偉い子なので、意味がありません。
(いやイヤミではなく、本当に偉いと思う)

一番いいのは、1秒程度の間隔を設定し、1回だけ動作が行われるタイマーをつくり、
そのタイマーを起動してNAKO_eval()を抜けるのがラクそうなのですが、、、
(スクリプト終了後、タイマーが働いて指定したスクリプトを起動する。)
現在のバージョンではNAKO_eval()においてVNAKOが使えないので、
WIN32APIのSetTimer関数と、なでしこのイベント登録関数で切り抜けるしかなさそう。。。
(WM_TIMERを使うってことね。)

あれ?ちょっと待てよ。。。
もしかしたら、タイマー起動したら、Filemakerの動作がまずくなる???
そのまえにNAKO_eval()抜けられない罠とか????
しかし今日はもう時間切れ。。。(T_T)
週末にでもいじります。

タイマーが正常に動けば、
指定時間にダイアログ表示とか、スクリプト実行とかできるのになぁ。。。

ここまで書いて気づいた。
一番ラクなのは、なでしこで不可視のGUIアプリケーションを作って、
それをランタイム?ターミナル??サーバー???みたいにして、
COPYDATAとか使ってやり取りすればとりあえず切り抜けれるか。。。

Older posts