PHP、MYSQL和WordPress编程散记

为了解决StatPress存在的中文乱码问题并清除无效spider信息,me下功夫K了不少php、mysql以及WordPress的编程信息。怕下次再重新学习一道,记录一下知识点,聊以备忘。

一、PHP

  1. 连接字符串使用.,比如$nome.”|”.urldecode($tab[1])。
  2. 调用变量用$,函数则直接调用。
  3. 字符串处理的一些常用函数。strpos寻找字符串中某字符最先出现处,strrpos寻找字符串中某字符最后出现处,这两个函数都反馈整数值,如果没有找到则返回false;strrchar则返回字符最后出现处至结尾的子字符串,strstr则返回搜索字符串最后出现处至末尾的子字符串;substr取部分字符串,string substr(string string, int start, int [length]);start和length如果是负数则从末尾算起;ereg用正则表达式对字符串进行比较或返回拆分后的数组,eregi同ereg,只是大小写无关,ereg_replace和eregi_replace按照一定的规则进行替换;str_replace替换特定的子字符串,str_replace(“%body%”, “black”, “<body text=%body%>”);
  4. 处理url的函数有urlencode和urldecode,前者把”为什么”转为%CE%AA%CA%B2%C3%B4,后者再把它转回来。编码是为了适应浏览器对url的处理规则, 对字符串多解码一次也没什么影响,还是原样。还有个函数是parse_url,返回数组,可以通过component调用处理结果,支持的component有scheme、host、port、user、pass、query、fragment。
  5. iconv可以把字符串在不同的字符集间进行转换,比如iconv(“gb2312″,”utf-8”,$str)。
  6. gb2312的字符encode后占两位,也就是有两个%,而utf-8则是三位,每个字有三个%,示例:为什么如何使utf-8则encode后为%E4%B8%BA%E4%BB%80%E4%B9%88,共9位,如果是gb2312则为%CE%AA%CA%B2%C3%B4,只有6位。
  7. if中的条件判断语句不能用=而是==,否则就直接赋值了,比如$nome == “Baidu”。
  8. explode函数把由特定间隔符分割的字符串拆解成数组,比如$str = “wd=home”,$array = explode(“=”,$str)后得到array,其中array[0]=wd,array[1]=home。
  9. count则统计数组中元素的个数,count($array)的话就是2。
  10. 调试函数在,怎么忽然就该页为空了(在浏览器中啥都不显示),试了几次都不行。想想刚才都做了什么,也就是更改了页面的charset,从gb2312到utf-8,另外就是增加了两行代码。把代码删除,问题依旧;把charset改回去,还是不行。于是就怀疑是不是服务器不稳定,坏了。重新启动,问题居然依旧。这时候才想到去查服务器的log。一看不打紧,全是500,呵呵,标准的服务器内部错误,并且提示PHP Parse error: syntax error, unexpected T_STRING 在某个文件中云云。Google了下,还是没啥概念。在搜索结果中转来转去,忽然有点感觉了,还是代码出了问题,php无法解析导致的。再次检查,晕,还真是,后面加的两行代码导致的。调用函数居然没有用括号括住参数,具体如此println iconv(“gb2312″,”utf-8”,$stem);呵呵晕死。加上应该的括号后变成了这样println(iconv(“gb2312″,”utf-8”,$stem));搞定!
  11. date是用来输出时间日期为特定形式的函数,具体的时间日期值通过mktime获得。date_default_timezone_set(‘Asia/Shanghai’);居然只支持Shanghai、Chongqing等,但没有北京。$startday = mktime(0,0,0,2,30,2008);居然也有效,不过生成的日期是2008年3月1日,自动处理了。(strtotime(“now”)-$startday)/86400;获得从某特定日期到现在的所过天数。


二、MYSQL
(一)不知道PHP的函数是否可以直接用在SQL语句中,只好把要处理的记录全查出来后根据id一条条进行处理,示例代码如下:
$qry = $wpdb->get_results(“SELECT id, urlrequested FROM $table_name WHERE (urlrequested is not null) and (urlrequested != ”)”);
print “…”.count($qry).” select-ed; “;
foreach ($qry as $rk) {
$tmpstr = urldecode($rk->urlrequested);
$q=”UPDATE $table_name SET urlrequested = ‘$tmpstr’ WHERE id=”.$rk->id;
$wpdb->query($q);
}
print “”.__(‘done’,’statpress’).”
>”;
me非常担心这样的语句如果不能按照本意进行,会毁掉所有记录的那一栏数据:
update $table_name set urlrequested = urldecode(urlrequested);
(二)在本地安装的php、mysql和wordpress组合中导入网站导出的数据(为后缀名为sql的文本文件),命令语句:

mysql -uroot dataname < dataname_wp_20080427_287.sql

(三)创建数据库并授权以及添加用户。

用root登陆后 create database db_name;

grant all on db_name.* to db_user@host identified by ‘password’;

(四)update语句影响的set数目。为了使statpress在update时能精确显示信息,me增加了setcount参数进行统计,点击statpressUpdate时结果如下:

Updating OSes: 2006 sets are set to blank. 2006 sets are updated. done
Updating Browsers: 2009 sets are set to blank. 2009 sets are updated. done
Updating Spiders: 0 sets are set to blank. 0 sets are updated. done
Updating Feeds: 0 sets is set to blank. All is done.
Updating Search engines: 458 sets is set to blank!
2284 are select-ed, 458 are updated!

可以看出,在每个项目中被置空的数据记录居然数量不一样(OS中是2006个,Browser中则是2009个)。按道理像这样的语句 UPDATE $table_name SET spider = ”; 应该是更新数据库中的所有记录数才对啊。Google了半天,总算搞清楚了原因。那就是MYSQL在更新数据时如果该数据和将被更新的数据一致的话则不会发生作用,这样的话上面语句仅仅更新了那些不是”的记录。仔细想想,这种处理确实有理,可以提高sql语句运行效率,在数据库很大的时候当然会显得非常有必要。

(五)清除某些插件的残留物。插件启用后有些时候感觉不好用,总是要放弃的,但有些不友好的会留下一些东西,像创建的数据库啊以及在options中的记录等。用下面语句清除:feed_statistics、wp-poll、tantan的ga。

$str = ”;
foreach($wpdb->get_col(“show tables like ‘%wp_feed_%'”) as $db_name){
$str .= $db_name.”|”;
$wpdb->query(“drop table $db_name”);
}
$str .= $wpdb->query(“delete from wp_options where option_name like ‘%poll_%'”).”|”;
$str .= $wpdb->query(“delete from wp_options where option_name like ‘%feed_statistics_%'”).”|”;
$str .= $wpdb->query(“delete from wp_options where option_name like ‘%tantan_ga%'”).”|”;

三、WordPress
(一)、查看StatPress统计的记录,居然有这样访问的:
/2006/05/23/javascript:void($(‘akst_form’).style.display=’none’);
是不是有人想黑me啊。

又发现了怪怪的urlrequest,这次是¤§??? and 1=1,me把它敲入地址栏后就转换成了 http://heart5.com/%A1%E8%A1%EC???%20and%201=1,页面结果是Error 404,Not Found。

(二)、rss类的url跟随wordpress的permalink设置情况变化:如果是默认的?p=123则get_bloginfo(‘rss2_url’)得到形如http://host/?feed=rss2;如果permalink设置为/%year%/%month%/,则get_bloginfo(‘rss2_url’)得到形如http://host/feed/rss2。statpress对这种情况没有做特殊处理。此种关联也提醒我们不要随便改变wordpress的permalink,因为会影响很多事情。

(三)、在wordpress中所有插件中的函数可以互相调用,并且还可以用在模板中。强,不过,避免函数名称冲突就显得非常非常重要了。

作者: heart5

生命如歌,我自徜徉。

发表评论

电子邮件地址不会被公开。 必填项已用*标注