アーカイブ

‘PHP’ カテゴリーのアーカイブ

CodeIgniter 2.0.3 index.phpをURLから除去したときの警告(Empty delimiter)を消す

CodeIgniterは、そのまま使うと、全ての呼び出しはindex.phpへの引数ってことになるんだけど、
CodeIgniter ユーザガイド 日本語版に書いてあるように、ApacheのRewrite設定とCodeIgniterの設定(config.php)を組み合せて、これを除去することができる。

このとき、以下のようなPHP警告メッセージが出ることがある。

A PHP Error was encountered

Severity: Warning

Message: strpos() [function.strpos]: Empty delimiter.

Filename: core/URI.php

Line Number: 160

A PHP Error was encountered

Severity: Warning

Message: strpos() [function.strpos]: Empty delimiter.

Filename: core/URI.php

Line Number: 164

以下、対処方法。

修正前。core/URI.phpの160行目あたりはこうなってる。

        /**
         * Detects the URI
         *
         * This function will detect the URI automatically and fix the query string
         * if necessary.
         *
         * @access      private
         * @return      string
         */
        private function _detect_uri()
        {
                if ( ! isset($_SERVER['REQUEST_URI']) OR ! isset($_SERVER['SCRIPT_NAME']))
                {
                        return '';
                }

                $uri = $_SERVER['REQUEST_URI'];
                if (strpos($uri, $_SERVER['SCRIPT_NAME']) === 0)
                {
                        $uri = substr($uri, strlen($_SERVER['SCRIPT_NAME']));
                }
                elseif (strpos($uri, dirname($_SERVER['SCRIPT_NAME'])) === 0)
                {
                        $uri = substr($uri, strlen(dirname($_SERVER['SCRIPT_NAME'])));
                }

$_SERVER['SCRIPT_NAME']をstrposしてるんだけど、何も入ってないことを想定していないっぽい。

修正後。なんか入ってた時だけstrpos&substrをやる。

        private function _detect_uri()
        {
                if ( ! isset($_SERVER['REQUEST_URI']) OR ! isset($_SERVER['SCRIPT_NAME']))
                {
                        return '';
                }

                $uri = $_SERVER['REQUEST_URI'];
                if (strlen($_SERVER['SCRIPT_NAME']))
                {
                        if (strpos($uri, $_SERVER['SCRIPT_NAME']) === 0)
                        {
                                $uri = substr($uri, strlen($_SERVER['SCRIPT_NAME']));
                        }
                        elseif (strpos($uri, dirname($_SERVER['SCRIPT_NAME'])) === 0)
                        {
                                $uri = substr($uri, strlen(dirname($_SERVER['SCRIPT_NAME'])));
                        }
                }

同士はここに。

カテゴリー: PHP タグ:

CodeIgniter

http://codeigniter.com/
最近はこれを使っている。ActiveRecordが発展途上だったり、Helperが書き直しレベルの使いづらさだったりはするが、改造改良はしやすいので結構なじんでくるといい奴になってくる。あと地味だがPHP 5.1系でもつかえるところがいい。

カテゴリー: PHP タグ:

WebARENA SuitePRO v2にPHP5&PEAR(Image_Graph)を入れる

WebARENA SuitePRO v2は最近でこそCentOS5版が出たが、ちょっと前まではCentOS4であったため、PHPはVer.4がデフォルトだったんだが、いろいろなOSSがPHP5前提だったりするし、時代も時代だし、PHP5を入れようと。
ついでに、様々なグラフ画像が生成できちゃう便利PEARモジュールを入れる。

1.まずはyumのリポジトリをいじる

# vi /etc/yum.repos.d/CentOS-Base.repo
--------------------
(Plusリポジトリをenabled=1にする)
additional packages that extend functionality of existing packages
[centosplus]
name=CentOS-$releasever - Plus
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=centosplu
s
#baseurl=http://mirror.centos.org/centos/$releasever/centosplus/$basearch/
gpgcheck=1
enabled=1
gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-centos4
priority=2
protect=1
--------------------

2.PHP4を消す

# yum remove php

3.PEAR(およびPHP)をバージョン指定してインストール

# yum install php-pear-1.4.11

4.php.iniを編集(してhttpdを再起動)

# vi /etc/php.ini
--------------------
(include_pathを設定&有効化)
; UNIX: "/path1:/path2"
include_path = ".:/php/includes:/usr/share/pear"
--------------------
(memory_limitを増やす:少ないとImage_Graphインストール時にメモリ割り当てエラーになる)
;memory_limit = 8M ; Maximum amount of memory a script may consume (8MB)
memory_limit = 32M ; Maximum amount of memory a script may consume (32MB)
--------------------
# service httpd restart

5.PHP-GDライブラリ、PEARライブラリをインストール

# yum install php-gd
# pear install --alldeps Image_Graph-alpha

6.PEAR_Info&PhpDocumentorをインストール

# pear install --force --alldeps PEAR_Info
# pear install --alldeps phpdocumentor

本項は必須ではない。PEAR_InfoはPEAR版のphpinfo()のようなもの。PhpDocumentorはPHPソースのhtmlドキュメント化支援ツール。

カテゴリー: PHP タグ: , ,

さよならPHP4・・・って素直に言えない人達が続出な予感。

PHP4のサポート終了時期がアナウンスされた。

Today it is exactly three years ago since PHP 5 has been released. In those three years it has seen many improvements over PHP 4. PHP 5 is fast, stable & production-ready and as PHP 6 is on the way, PHP 4 will be discontinued.

The PHP development team hereby announces that support for PHP 4 will continue until the end of this year only. After 2007-12-31 there will be no more releases of PHP 4.4. We will continue to make critical security fixes available on a case-by-case basis until 2008-08-08. Please use the rest of this year to make your application suitable to run on PHP 5.

For documentation on migration for PHP 4 to PHP 5, we would like to point you to our migration guide. There is additional information available in the PHP 5.0 to PHP 5.1 and PHP 5.1 to PHP 5.2 migration guides as well.

PHP 4 end of life announcement [13-Jul-2007]

 おい、おまいら!PHP5がリリースされてから3年もたって、PHP6もそろそろ準備ができてんのに、PHP4なんかメンテできっか!セキュリティ問題だけは2008/8/8まで対応してやっから、そのスキにとっととPHP5にしやがれ、とのこと。
(888は洒落だろうきっと)

 既に多くのblogで言及されている通り、これで喉にひっかかった魚の骨のように残存していたPHP4が一掃され、PHP5への移行がより進むであろうから、それはそれで前向きなことなのであろう。

 少し探した限りでは「ふざけんなゴルァ!」という激しい拒絶反応は見当たらない。(まあ拒絶したところでOSSでは「じゃおまえ自分で直せよソースやっから」で終わるのがオチなので、おこぼれをもらっている凡人は諦めるしかないわけだが)

 これを機に、レンタルサーバもPHP5標準装備の方向へ向かってくれるとうれしいが。(PHP4が根強く残る理由の1つは、レンタルサーバだと思う)

 じっさい自分が使っている限り、クラスまわりとXML関係はちょっと辛いけど、PHPの4から5は、移行しやすいほうだと思う。

 が、さすがに仕事で使っている場合は、一通り試験をしなければいけない(はず)なので、仕事が増える人達も多いだろうな。

 ソフトウェアを作ったり売ったりしている側から見ると、いままでは、サポート切れというのは「更改時期ですよ」ということを促すための販促イベントのひとつでもあったのだが、ここ最近では、Windows XP Homeのサポート期間が延長されたり、Visual Basic 6のサポート終了計画に100社以上から抗議があったり、Red Hat Enterprise Linuxもサポート期間を延長したりと、だんだん「システム屋の脅し文句にはのらねーぞ」というユーザの声を飲まざるを得ない状況が見え隠れしてきている。

 あえてソフトウェア開発屋の立場からいうと、サポート期間は短ければ短いほどよいわけだが、ユーザの立場から見れば、家を買ったけど建てた建築業者も売った不動産屋も面倒見てくれない状態になるわけで、ましてやソフトウェアというある意味「売った時点では未完成品かもしれない商品」を売りつけている以上は、一定期間、ユーザが運用できる状態を維持することも、それはそれで義務ではあるとは思ってるんだけど・・・結局は、お金の問題なんだよね。

 ソフトウェア開発を始める時点で、維持していくためのコスト算出と予算確保、こうしたサポート終了というリスクに対する取り決めを、だいたいにおいてしていることが少ないから・・・

 開発ベンダーとして、ユーザからいわれなくても、こうした「開発費用以外にかかるコスト」をふくめて提案できる能力が求められていると思う。

 そして、ユーザ企業側にも、システム概要設計レベルくらいはできて、ミドルウェアもふくめた主なツールの比較や、開発ベンダーが出してくる提案や見積の良し悪しをつっこめるくらいの人を置け、ということになるのだと思う。

 そういった意味で、最近は、ユーザ企業とソフトウェア開発屋にいる人材の配置がおかしい気がしてならない。もっとユーザ企業側に「業務も技術も分かる素養のある人(あえてSEとは呼ばない)」が移動すべきなんじゃあ・・・

 いずれにしても現状では、ユーザ側に「ソフトウェアは買ったその日から何年経っても同じように動きつづけるもの」という感覚があって、上記のような話が通じにくいことが多々ある。

 もしかすると会計上の扱い方(バージョンアップは修繕扱いなのか?固定資産増なのか?など)等も関係があるのかも知れないが、契約の内容と、締結過程にも問題があるのだろう。(双方における、説明と理解の欠如)

 ソフトウェアの契約に関しては、経済産業省も当然ながら問題意識はあって、ずいぶん前からガイドラインを出したりいろんなことをやってくれているが、そもそも開発と運用の契約が分かれていること自体を、ホントにそれでいいか考え直してみるべきかも、なんて思ったりもした・・・話が発散してきたので今日はこの辺で。

カテゴリー: PHP, 記事に反応! タグ:

メールでWikipedia:β版

Wikipediaが引けるメールアドレスをちょこっと手直し。

wp@ookawara.sakura.ne.jp宛で、メール表題に調べたい語句を1つ書いて本文なしメールを送ると、Wikipediaで調べた結果を返します。

日頃の生活のなかでも、ふとしたときに分からない言葉が出てきたりしますよね。その場でWeb(iモード)アクセスしてまで調べるほどの状況でもないし、かといって後で調べるかというと、そのまま忘れたり。

そんなときメールだと、ちょっとだけ送信までの手間が少ない&後でオフラインで読めるので、便利かなと思いまして。

メモ代わりに携帯で自分宛メール送ったりする人もいるみたいなんで、そんなスタイルの使い方を想定しながら作りました。

Googleでも、メール表題にクエリー書いて送ると検索結果を返すメアドとかやってるみたいなんで、それなりにニーズがあると思われるサービス形態なのかな~と思います。

文字化けは、PEAR::Mailに渡す本文データの、改行の間隔が広すぎたみたいです。
それっぽいルールで改行を入れたことによって、だいたい解決したと思います。

あと、検索結果で返ってくるXMLの解析で、部分的にごっそり文章が落ちる鬼バグがあったんで修正しました。

ついでに、H2タグやH3タグの単語に番号をふって、それっぽく整形しました。

HTMLメール使えると、いろいろ装飾ができて、いいのかも知れないですね。でもシンプル勝負なんでとりあえず当面はテキストのままで。
(テキストだとリンクを表現できないのが苦しいが)

関連記事1:オンとオフの中間
関連記事2:メールで辞書:完成
関連記事3:メールでWikipedia:α版
関連記事4:メールで~

記事番号が100。よくまあ戯言を100件も書いたな~。目指せ200件!

カテゴリー: PHP タグ:

メールでWikipedia:α版

Wikipediaを引けるメールアドレスをつくりました。

wp@ookawara.sakura.ne.jp宛で、表題に調べたい語句を1つ書いて本文なしメールを送ると、Wikipediaで調べた結果を返します。

日頃の生活のなかでも、ふとしたときに分からない言葉が出てきたりしますよね。その場でWeb(iモード)アクセスしてまで調べるほどの状況でもないし、かといって後で調べるかというと、そのまま忘れたり。

そんなときメールだと、ちょっとだけ送信までの手間が少ない&後でオフラインで読めるので、便利かなと思いまして。

メモ代わりに携帯で自分宛メール送ったりする人もいるみたいなんで、そんなスタイルの使い方を想定しながら作りました。

Wikipediaでは指定した語句に直接説明が紐付いておらず、類似語にリダイレクトされている場合がありますが、それも一応対応しました。

が、文字エンコードの問題があって、文字化けを起こしたりしています。追って調査。

関連記事1:オンとオフの中間
関連記事2:メールで辞書:完成

カテゴリー: PHP タグ:

メールで辞書:完成

前回の続き。意地で実現しました。

目的達成手段の1つである .mailfilter が利用者に開放されている、さくらインターネットのサーバーを使うことにした。
この際なので、今後、サービス自体についても、XREA.COMと比較などをしていこうと思う。

さて目的のスクリプトは、すんなりいくと思いきや、PHP5の環境で作ってしまったにも関わらず、さくらインターネットはPHP4しか使えず、http通信やらXML解析やらすべてPEARで書き直したり、さらにPEARで提供されるXML/TreeはUTF-8が通らないため、XML_Tree_Exを探してくるなど、それなりに紆余曲折して実現。

e2j@ookawara.sakura.ne.jp 宛に、タイトルに日本語の意味を知りたい英単語を半角スペース区切りで並べた本文なしメールを送ってもらうと、本文に意味が書かれたメールを返信します。

例外やエラーの処理など超甘ですが、よろしければご活用ください。

この辞書を提供してくれている会社、Wikipediaの検索サービスもあるので、辞書がよさげだったらそれも頑張ってみようかなあ。

カテゴリー: PHP タグ:

オンとオフの中間

メールI/Fで、Webサービスのゲートウェイを作ろうとしてみた。

というのも、携帯で辞書を引きたい時などは、けっこう電車(しかも地下鉄)移動中だったりするので、オフラインでクエリー入力して、常時接続ではないやり取りで結果を受け取れたら、小便利な気がしたので。

このようなオンとオフの中間みたいなところで、意外と便利サービスがほかにも考えられるかも。

で、辞書で試してみる。

イーストという会社が辞書Webサービスを非商用フリーで提供してくれちゃったりするので、メールSubjectに引きたい英単語をスペース区切りで書いてメールするとサーバー側で辞書を引いて結果をメール返信するゴミプロを作ってみた。

PEAR::Net_POP3とPEAR::Mailと以前作ったhttpクラスを使って2時間もあれば完成!だったのだが、定期受信監視手段でアテにしていたcron設定が、XREA.COMでは最短1時間おきらしいので、ほぼリアルタイムが実現できず!
しまった前提条件の確認を怠った。
(まあそれでもレンタルサーバでcronまで使えるのはありがたいことですが)

というわけで、一応、完成させるも、現在の環境では実用レベルの定期動作環境が作れず。
(Web-CGIで動かす版は作ったのだが、それならフツーに辞書サイト行けばいいじゃん、てことで本末転倒)

XREA.COMさまにはprocmailを使えるようにしてほしいな、と我侭をつぶやいてみる今日この頃。

カテゴリー: PHP タグ:

SQL Designer

自サーバに「SQL Designer」をたてる

JavaScript全開で、ERDができるスグレものだ。
こうして、どんどんWeb上で出来ることが増えていくんだね。

全てがWeb上で完結する日も、近いな。

カテゴリー: JavaScript, PHP, すごい奴ら タグ:

これって

404 Blog Not Found(2007年05月21日 04:00)「そろそろPHPに関して一言いっとくか

半分「釣り」だよね?そうだよね?そうだって言ってお願い。

確かに「使える」けど「作りにくい」言語であることは認める。けど、それはみんな分かって使ってると思いたい。

やっぱり、これだけメジャー化して、レンタルサーバなんかにも絶対のっていて、おそらく多くの人がWebプログラミング事始めとして使う処理系なのに、PHP4,5がいつまでも併存してしまっている複雑な状況が、いろいろ困った事態をひきおこしているんだろうなあ。

カテゴリー: PHP, 記事に反応! タグ: