虽然php手册上说fopen和file_get_contents都可以直接给url参数获取内容,但总是会报如下这个错误

Warning: fopen(http://leoncom.org/) [function.readfile]: failed to open stream: HTTP request failed!

采用curl获取url数据就可以避免这种时不时的错误了

[code language="php"]
function geturldata($url)
{
$ch = curl_init();
curl_setopt ($ch, CURLOPT_URL, $url);
curl_setopt ($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt ($ch, CURLOPT_CONNECTTIMEOUT,10);
$content = curl_exec($ch);
return $content;
}
[/code]

, ,

没事在公司想换个主题,以前的主题太单调了,看到了iblog,结果刚一点启用,整个网页就HTTP  500了,在公司又不能ssh…网络访问各种严格

回到家ssh到主机上一看error_log

Call to undefined function register_nav_menus 以及 Call to undefined function get_template_part

查wp手册,这两个函数都是wp3.0开始支持的,俺还2.9……google了下,还有个wp_nav_menu函数也是since 3.0.0

直接屏蔽调用register_nav_menus的代码就可以进wp-admin了,懒得折腾的就直接别的主题吧。

, ,

bom和上面的?>后有trailing whitespaces都有可能是页面出现异常,导致空白的原因,应该在程序中尽量杜绝,因为这两个错误很难调试,而不像动作未定义之类的访问accesslog会有日志。

为了做检查代码库中php的trailing whitespace,用正则表达式

\?>\s+$

来验证,应该是可以匹配到的,在?>后还有空白,但是跑出来的结果总是明明没有尾部空白也会报告,原来是unix下用vi查看文件的时候会有0d0a(fileformat = doc),或者0a(fileformat = unix),在win没这个问题,那个正则就可以正确匹配php尾部空白。但当这个文件上传到unix下用vi查看的时候就会带上LF,同一个文件用UE在win下看16进制和上传到unix后用vi的xxd模式。

阅读全文…

php文件省略尾端的 ?> 是可选的,但是可能的话,省略它是一个好方法,如果?>后续有空白,就会被当作内容输出,就可能会引起各种错误。。和bom的效果差不多,特别是header之类的。

Note: The closing tag of a PHP block at the end of a file is optional, and in some cases omitting it is helpful when using include() or require(), so unwanted whitespace will not occur at the end of files, and you will still be able to add headers to the response later. It is also handy if you use output buffering, and would not like to see added unwanted whitespace at the end of the parts generated by the included files.

BOM——Byte Order Mark,就是字节序标记。在UCS 编码中有一个叫做”ZERO WIDTH NO-BREAK SPACE”的字符,它的编码是FEFF。而FFFE在UCS中是不存在的字符,所以不应该出现在实际传输中。UCS规范建议我们在传输字节流前,先传输字符”ZERO WIDTH NO-BREAK SPACE”。这样如果接收者收到FEFF,就表明这个字节流是Big-Endian的;如果收到FFFE,就表明这个字节流是Little- Endian的。因此字符”ZERO WIDTH NO-BREAK SPACE”又被称作BOM。   
UTF-8不需要BOM来表明字节顺序,但可以用BOM来表明编码方式。字符”ZERO WIDTH NO-BREAK SPACE”的UTF-8编码是EF BB BF。所以如果接收者收到以EF BB BF开头的字节流,就知道这是UTF-8编码了。Windows就是使用BOM来标记文本文件的编码方式的。

PHP对BOM是不会进行特别处理,只会被原原本本输出的,这就造成比如header之类的函数会报warning–”header has already sent”,session cookie 失效,页面却是一片空白或者在页顶处有一行空白导致页面乱套等各种莫名问题。

因此需要对代码库中的检查并替换bom标记,避免系统不出现异常

function checkBOM ($filename) {
	global $auto;
	$contents=file_get_contents($filename);
	$charset[1]=substr($contents, 0, 1);
	$charset[2]=substr($contents, 1, 1);
	$charset[3]=substr($contents, 2, 1);

	if (ord($charset[1])==239 && ord($charset[2])==187 && ord($charset[3])==191) {
			$rest=substr($contents, 3);
			file_put_contents($filename,$rest);
			echo 'WITHBOM,REMOVED';
	}
	else
	{
		echo 'WITHOUT BOM';
	}
}

第一次写一个面对海量用户的写操作函数,各种无意或者故意的非法输入是常态,各种心虚。

为了保持用户的良好体验,给表单的提交添加了用户提交失败返回时还能保持用户输入的特性。

<textarea></textarea> 中间的任何html字符都会被当作普通文本处理,测试时用<b></b>,<script>alert();</script>都没问题,就没用htmlspecialchars进行转义。

突然想到用户输入</textarea><script>…</script>,不就悲剧了。。。果然。。。

htmlspecialcharsaddslashes ,  Magic Quotes

说的是php manual中的这几个dba_*系列函数,照顾到手册的情绪,查起来也方便就安装本身的dba系列的扩展吧,php的dba系列就是一个berkeleyDB的本地key-value存储,就是本地存点啥之类的方便用,如果调用memcache就划不来了,一般规模专用的memcache机器都是一组服务器,又是分布式又是网络通信的,代价大了。

php manual :  dba_open: The database is created in BTree mode, other modes (like Hash or Queue) are not supported.

安装过程跟普通php的扩展安装没区别

 cd php_src_xxx/ext/dba

 phpize

./configure –enable-dba=shared -with-db4  –with-php-config=/usr/local/php/bin/php-config

这里的-with-db4的db4是dba系列函数的那个string参数handler,  即dba_open(“dbfile”,”n”,”db4″)第三个参数

cp dba.so 到 extension_dir

echo ‘extension=dba.so’  >> php.ini

如果需要安装BerkeleyDB4可以参考这个,使用的时候就是new Db4()对象,不能使用dba_系列的函数,ref这里