由于我系统里的 php session save path 是由当初 apache 创建的，改用 nginx 后就变成不可写了。但是，症状并不直观，php 照样能运行，phpMyAdmin 也能 login，还能查看各库各表的数据，但就是不能更新、删除，也无法 logout。无法 logout phpMyAdmin 的具体症状也不是其他人描述的那样（logout 时提示输入用户名和密码），就是点了没效果，仍在管理界面（还有人说启用 http basic auth login 的话就是无法 logout 的，只能关闭浏览器才 logout，这纯属无稽之谈）。
我一直认为是 phpMyAdmin 或 mysql 设置出问题的，根本没往 php session save path 是否可写这方面想，我想当然地以为如果 php session save path 不可写，在 php 里启用 session 就会出错，别想进入 phpMyAdmin。
Long time ago, I read an article about moving from Windows to Linux, the top differences a system administrator should keep in mind. I still remember one of the difference is reboot in Linux does not cure the problem as it does for Windows in 99% occasions.
However, today I tried to fix a problem after I manually compiled php 5.2.9 (phpMyAdmin stop working, server response 500 error). I lack of knowledge of configure, make install, so I decided to remove php 5.2.9 and reverse to php 5.2.6 came with Fedora. I like yum install. Yum make my life so easy and it can also install packages perfect for me.
php 5.2.9 executables was installed to /usr/local/bin (as php’s default), but php 5.2.6 was installed to /usr/bin (as fedora yum default). After I yum reinstalled php 5.2.6, I found
If I typed “php-cgi -v”, Fedora could find php-cgi in /usr/bin
If I typed “php -v”, Fedora still looked for php in /usr/local/bin
I did not know why Fedora behave so strangely. After hours trying to correct Fedora mis-behavior without success, I reboot Fedora hopelessly. Then what? Fedora now is willing to load php executable in /usr/bin.
Use fedora yum install to install php is very easy. But, there is no yum install available to install php-fpm. I have to download php source and compile it from source.
I do not know why Fedora configures its php this way, but it works fine for me. So I want to configure my php source the same way as Fedora did. I only add –enable-fpm to the configure.
./configure --build=i386-redhat-linux-gnu --host=i386-redhat-linux-gnu --target=i386-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --cache-file=../config.cache --with-libdir=lib --with-config-file-path=/etc --with-config-file-scan-dir=/etc/php.d --disable-debug --with-pic --disable-rpath --without-pear --with-bz2 --with-curl --with-exec-dir=/usr/bin --with-freetype-dir=/usr --with-png-dir=/usr --with-xpm-dir=/usr --enable-gd-native-ttf --with-t1lib=/usr --without-gdbm --with-gettext --with-gmp --with-iconv --with-jpeg-dir=/usr --with-openssl --with-png --with-expat-dir=/usr --with-pcre-regex=/usr --with-zlib --with-layout=GNU --enable-exif --enable-ftp --enable-magic-quotes --enable-sockets --enable-sysvsem --enable-sysvshm --enable-sysvmsg --enable-track-vars --enable-trans-sid --enable-yp --enable-wddx --with-kerberos --enable-ucd-snmp-hack --with-unixODBC=shared,/usr --enable-memory-limit --enable-shmop --enable-calendar --enable-dbx --enable-dio --without-mime-magic --without-sqlite --with-libxml-dir=/usr --with-xml --with-system-tzdata --enable-force-cgi-redirect --enable-pcntl --with-imap=shared --with-imap-ssl --enable-mbstring=shared --enable-mbstr-enc-trans --enable-mbregex --with-ncurses=shared --with-gd=shared --enable-bcmath=shared --enable-dba=shared --with-db4=/usr --with-xmlrpc=shared --with-ldap=shared --with-ldap-sasl --with-mysql=shared,/usr --with-mysqli=shared,/usr/bin/mysql_config --enable-dom=shared --with-dom-xslt=/usr --with-dom-exslt=/usr --with-pgsql=shared --with-snmp=shared,/usr --enable-soap=shared --with-xsl=shared,/usr --enable-xmlreader=shared --enable-xmlwriter=shared --enable-fastcgi --enable-fpm --enable-pdo=shared --with-pdo-odbc=shared,unixODBC,/usr --with-pdo-mysql=shared,/usr --with-pdo-pgsql=shared,/usr --with-pdo-sqlite=shared,/usr --enable-json=shared --enable-zip=shared --with-readline --enable-dbase=shared --with-pspell=shared --with-mcrypt=shared,/usr --with-mhash=shared,/usr --with-tidy=shared,/usr --with-mssql=shared,/usr
I had several errors when run ./configure
checking for BZip2 in default path… not found
configure: error: Please reinstall the BZip2 distribution
solution: yum install bzip-devel bzip-libs
configure: error: DBA: Could not find necessary header file(s).
solution: yum install gdbm-devel
Well, someone suggests that, I did that, but error still exists. Then under my own decision, I run
yum install php-dba
Error still exists.
yum install qdbm*
Error still exists.
yum install db4*
Pass!
configure: error: libjpeg.(a|so) not found.
solution: yum install libjpeg libjpeg-devel
Configure: error: libpng.(also) not found.
solution: yum install libpng libpng-devel
configure: error: libXpm.(a|so) not found.
solution: yum install libXpm*
Configure: error: freetype.h not found.
solution: yum install freetype-devel
configure: error: Unable to locate gmp.h
solution: yum install mysql-devel
configure: error: utf8_mime2text() has new signature, but U8T_CANONICAL is missing. This should not happen. Check config.log for additional information.
solution: yum install libc-client-devel
configure: error: Cannot find ldap.h
solution: yum install openldap-devel
configure: error: mcrypt.h not found. Please reinstall libmcrypt.
solution: yum install libmcrypt-devel
configure: error: Please reinstall libmhash – I cannot find mhash.h
solution: yum install mhash-devel
configure: error: Directory /usr is not a FreeTDS installation directory
solution: yum install freetds-devel
Configure: error: Please reinstall the ncurses distribution
solution: yum install ncurses-devel
checking for unixODBC support… configure: error: ODBC header file ‘/usr/include/sqlext.h’ not found!
solution: yum install unixODBC-devel
configure: error: Cannot find libpq-fe.h. Please specify correct PostgreSQL installation path
solution: yum install postgresql-devel
configure: error: Please reinstall the sqlite3 distribution
solution: yun install sqlite-devel
Configure: error: Cannot find pspell
solution: yum install pspell-devel
configure: error: Please reinstall readline – I cannot find readline.h
solution: yum install readline-devel
configure: error: SNMP sanity check failed. Please check config.log for more information.
solution: yum install net-snmp-devel
configure: error: Cannot find libtidy
solution: yum install libtidy-devel
configure: error: xslt-config not found. Please reinstall the libxslt >= 1.1.0 distribution
solution: yum install libxslt-devel
While I set my Mysql database default character set as UTF-8, Zend_Db_Adapter does not pick up the setting. Zend_Db write to Mysql using its own default character set (I guess it’s ISO-8859-1), unless it is specifically told by
$dbAdapter->query(“SET NAMES ‘utf8′”);
before
Zend_Db_Table::setDefaultAdapter($dbAdapter);
Google App Engine 不久前开始支持第二种语言 Java，我当时听到这个消息马上开始期盼什么时候 GAE 支持 PHP。
今天看到 Quercus 项目，它可以让 PHP 运行在 Java 环境，我才意识到不用再期盼在 GAE 跑 PHP 程序，这已成为现实。这下我有事情做了——怎么把 Magento 跑在 GAE 上？
我尝试着用 Zend Framework 重写了一个程序。在 Zend_Form 上徘徊了好久，研读了 Programmer’s Reference Guide N 遍，还是没有融会贯通。比如说，我想去掉默认的DtDdWrapper，用
$element->removeDecorator(‘DtDdWrapper’);
只对某些element起作用，对 Zend_Form_Element_Text 怎么也不起作用，最后发现用
$element->removeDecorator(‘HtmlTag’);
倒可行。
问题是解决了，但还是没摸清 Zend Framework 设计思路。很累。
续：
其实，用$element->removeDecorator(‘HtmlTag’); 问题并没有完全解决。后来我用
var_dump($element->getDecorators());
查看了默认加载的装饰器以及装饰器的参数，发现对于 Zend_Form_Element_Text 来说，它的 dt 和 dd 并不是由 DtDdWrapper 加载的，事实上 Zend_Form_Element_Text 默认不加载 DtDdWrapper，难怪
$element->removeDecorator(‘DtDdWrapper’);
是不起作用的。
那么，Zend_Form_Element_Text 的 dt 和 dd 是哪里来的呢？我仔细看了 var_dump 的结果，发现
如果想要 Zend_Form_Element_Text 不套用 dt 和 dd，应该对症下药，修改 Label 和 ViewHelper 默认参数。
上次用 $element->removeDecorator(‘HtmlTag’); 并没有去除 dt 和 dd，只是误打误撞让页面呈现出视同没有 dt 和 dd 时的效果。
I don’t like the way of Actinic tackle the problem. For example, if the web server set default charset as UTF-8, it will cause page rendering issue for Actinic. Especially for the pound sign. All the support knowledge from Actinic is redirecting people set the server using default chareset as ISO-8859-1. Then, my question is – why should I use ISO-8859-1 while UTF-8 has far better applicability, especially for multi-national sites?
Nevertheless, can Actinic generate an UTF-8 encoded site? The answer is yes and no.
Yes is because I have already achieved it; No is because Actinic can not make it happen for you (at least I won’t know how to control it), so you must do something outside Actinic. Here below is my detailed steps.
The most tricky part is actinic upload its files in iso-8859-1 encoding, but bootscript is utf-8 encoded. A normal include or require by php will not render pound sign correctly. I use output buffer to hack the problem.
<?php ... ob_start(); include($actinic); $utf8out = utf8_encode(ob_get_contents()); ob_end_clean(); echo $utf8out; ?>
Zend Framework is evolving quickly. Some while ago, it did not have Zend_Paginator, but now it’s there. But a component of paginator is enough for me. I want something like Zend_Datagrid. It’s not there yet.
pao.fresco has developed Datagrid for Zend Framework. It looks good, but I am not confident using unofficial code.
Magento also implement its own datagrid, but I do not know how to utilise as part of code outside of Magento.
ngnix 0.6.35 没有实现 path_info。不知道 nginx 开发者是疏忽了，还是觉得没必要在 http server 层实现 path_info。我印象中有很多 php 程序的运行都依赖 $_SERVER[‘PATH_INFO’]，所以在 ngnix proxy pass 给 php-cgi 之前，必须设置好正确的 path_info 参数。
我认为最好的办法还是用正则表达式在 $fastcgi_script_name 里隔离出 script_name 和 path_info，但这样计算出的 path_info 用起来不如 ngnix variable 方便，而且得在脚本的安装位置或扩展名确定时才能写出相应的正则表达式。我是 nginx 新手，在 path_info 上折腾了三天才总结出一个相对满意的方案。如果 nginx 能给我一个 in-built variable $path_info，那会省事很多。
当然我并不想责怪 nginx（apache 已经够令人称赞了，nginx 能超越它实属不易），说不定 nginx 不搞 path_info 有它的道理。 既然这样，php 编程时就应该考虑到 path_info 是不可靠的。以前我不太注意环境参数的获得性，如今审视了一下，除了 $_SERVER[‘PATH_INFO’]以外，$_SERVER[’PHP_SELF’] 和 $_SERVER[’SCRIPT_NAME’] 也是不可靠的。
$_SERVER[‘REQUEST_URI’] 和 $_SERVER[’SCRIPT_FILENAME’] 相对可靠。
这可能是一个不可能实现的任务。
Actinic 的动态部分是 perl 写的，我不想触及 perl，陆陆续续做了很多 extensions，都是 php 写的。Actinic perl 有很多漏洞，其中一个就是会把我的 php 源码暴露。可能 Actinic 的目标用户都是 htmler，根本没指望 phper 会给它写 extensions（我也是没办法，早就不想干了）。我能做的，就是尽可能地调整 php 的代码方式，做到即使源码暴露了，也不包含机要信息。
我也不打算在 Actinic 浪费时间去研究怎么修改漏洞，只是最近把 apache module 研究了一遍，突然想重提这个历史遗留问题是否可以从 apache 方面给予弥补。漏洞的源头是 Actinic perl 读入我的 php script，当成 html 直接输出。如果能把 handler 再交给 php-cgi，那么 php tag 之间的内容就可以得到解析。
可是 apache 是以后缀推定 handler 的，那么某个后缀怎么可以有两个 cgi handlers?