March 2nd, 2010 by 张磊
前几天HipHop着实火了一把，我也第一时间参照Guide在Ubuntu Server上编译好了HipHop。 之后，又打算把我的blog使用的wordpress编译出来，历经艰难险阻，终于编译成功。在此把一些心得分享出来。 HipHop是什么？ HipHop是Facebook新近开源的一款软件，它可以把php代码转换成c++代码，并将其编译。据称，编译后在性能上会得到较大提升。 一、编译HipHop 建议使用ubuntu，参照这个文档，可以非常快地装好依赖的库。 别拿Linode去折腾，内存太小，吃不消的。如果手头没有合适的环境，建议在RackspaceCloud开一个Cloud Server来做。用完就关掉，估计也就一两块钱的事儿。我是在一个虚拟机上编的。 运行完make之后，可执行文件藏在 $HPHP_HOME/src/hphp下面，一开始我居然没找到。 二、编译PHP项目 编译过程中遇到错误，只要进入/tmp/hphp_xxx这个临时目录，解决掉相应问题，在该目录重新运行make即可。 如果牵涉到修改php文件，则需要从头开始先生成cpp代码，再编译。 如果php项目中有重复的类定义，可能遇到“No rule to make target `cls/atomentry$1.h’,” 这样的错误。WordPress中就有好几处（>=3）。我的解决办法是，把重复定义的类去掉。 编译还会遇到类似“undefined variable eo_1”的错误。要解决此问题，可打开相应的cpp文件，在报错行的前一行加入： Variant eo_1; 编译时的参数–cluster-count建议开大点，如果太小，会导致生成少数个大cpp文件，编译时非常占内存。 WordPress中不需要的主题、插件都可以删掉。惭愧的是，很早以前我写的一个插件，会导致编译出错。 编译WordPress这个大玩意很需要耐心，我连续战斗了三个晚上，修改了多处代码，重编了无数次，终于泪流满面地看到编译成功的信息。 三、运行PHP项目 如果打算放到服务器上运行，还需要参考编译hiphop的教程把依赖的库先装好。可以用 ldd 命令查看依赖的库是否都满足了。 scp到服务器之前，建议先压缩一下。我把WordPress编完将近80M，压缩之后只剩20M。 程序作为服务器启动后会有50多个线程，占用100M以上的内存。我没找到线程数这东西在哪里设置，小小一个blog，根本用不着这么多。 若打算长期使用而不是玩玩，可以参照这篇文章，使用nginx做一个反向代理。 值得一提的是，hiphop生成的中间代码（cpp代码），可读性相当好。
February 17th, 2010 by 张磊
昨晚不小心点了blog中某文章的“Compare Revisions”功能，深夜把我吓出一身冷汗。 Wake up, 张磊… The Matrix has you… Follow the white rabbit. 把这消息发到Twitter(@blogkid)，大家都和我说“Knock Knock”。 我想我是遇到彩蛋了（若不是就惨了），于是今天打算寻找一下出处。在目录中grep Matrix、wake up、rabbit都未果，猜到可能是做了加密，于是去翻代码。在Wordpress 2.92版本的wp-admin/revision.php中找到了线索： 54 if ( $left_revision->ID == $right_revision->ID ) { 55 $redirect = get_edit_post_link( $left_revision->ID ); 56 include( ‘js/revisions-js.php’ ); 57 break; 58 } 大意是，如果两个相比较的文章ID一致，就会包含js/revision-js.php这个文件。 而wp-admin/js/revisions-js.php文件中，有一堆加密过的字符串。粗略判断，就是看到的这几行字了。下面可以自己触发这个彩蛋，只要构造一个这样的url： http://you_blog_address/wp-admin/revision.php?action=diff&left=2414&right=2414 把后面的“2414”替换为blog上随便一个已有的文章ID，就能看到彩蛋出现啦。 PS：不知道是不是自己太没娱乐细胞了，初看到震惊了半晌。都是被逼的啊。 PS2：据说早在2.6版本就发现了这彩蛋。
July 13th, 2009 by 张磊
更换域名更多时候是体力活儿，但是用法得当，可以省力不少。所以我打算写几篇文章，写写自己迁移域名（从blogkid.cn到blogkid.net）的全程。先写迁移wordpress。 迁移wordpress主要涉及到3步： 1、数据备份 如果服务器上装有phpmyadmin，可以直接导出一下。使用shell的朋友，可以用如下命令来备份数据： mysqldump -u dbuser -pdbpass -h dbhost dbname | gzip > backup.sql.gz 把相应位置的dbuser, dbpass, dbhost和dbname替换为数据库用户名、密码、数据库服务器以及要备份的库名。最后得到的backup.sql.gz，就是一份完整备份。 插一句，我把备份的文件解压一看，居然有12M之巨。如果10%是有效内容的话，我这4年已经写了1.2M字节，相当于60万汉字了。 2、配置Web服务器 在这里需要牢记一点：使用301跳转，而不要用默认的302（refer）。 配置Web服务器的目的是，将访问原有域名的请求引导到新的域名。301跳转是永久重定向，而302跳转是暂时重定向。前者对搜索引擎更为友好。 以我从blogkid.cn迁移到blogkid.net为例，在nginx中做如下配置： server { listen 80; server_name blogkid.cn blogkid.net www.blogkid.cn; rewrite ^/(.*) http://www.blogkid.net/$1 permanent; } server{ listen 80; server_name www.blogkid.net; …… } 第一段的配置是将blogkid.cn，blogkid.net以及www.blogkid.cn的请求都重定向到www.blogkid.net下面。而第二段是用www.blogkid.net替换原有的www.blogkid.cn，其他部分不用改变。注意到在使用rewrite时，加入了permanent关键字，可以使nginx发送301重定向。 如果使用apache，配置也类似，在rewrite时可加入参数R=301。 保存之后重启web服务器，使配置生效。 3、修改数据库 这也是对wordpress进行迁移的最后一步。需要注意，在完成第二步之后，wordpress会暂时无法打开，原因大家可以自己考虑一下。如果觉得不太好，把这一步提到前面也可以。或者可以先修改好配置文件，等第三步完成了再重启web服务器。 修改数据库主要修改3部分，语句可以在phpmyadmin或者mysql命令行中进行，整理自此处。 （1）修改站点地址、主页地址： UPDATE wp_options SET option_value = [...]
November 24th, 2008 by 张磊
上周支付宝UED blog发表了一篇《浅谈眼动仪在可用性测试中的应用》，我在Reader读的时候发现文章的排版相当差：段内文字没有行距，首行缩进只有一格半，整体看着非常不舒服。我直接访问那篇文章的地址，看起来不算太丑，不过查看源代码时就发现，太多垃圾代码，显然是从word中写好直接贴上去的。 如果你不知道从word中写好粘贴到wp与直接在wp编辑器里写有多大的区别，可以打开word试一下：写两段文字，然后复制；接着打开一个wordpress后台撰写文章页面，在可视化编辑器中粘贴进来。点一下“HTML源代码”，看，有多少垃圾代码。 应当承认word是个好用的工具，但是在一篇blog里夹杂着大量word产生的代码，不是一件好事情。因为你的文章不只是会出现在你的网站上，也会出现在GReader、鲜果、抓虾这些阅读器上。如果用Word中的代码在这些地方继续约束格式，就可能变得很难看，支付宝UEDblog的那篇文章就是个例子。 我平时写blog，从来都不多考虑排版。因为我用过的每一款Wordpress皮肤，都可以很好地呈现我写的内容。查看一下源代码，一篇文章往往只有一些<P> <a> <img>标签，可能还会有<blockquote> <ul>以及<li>，没有任何多余成分——这样的plainHTML是优美的，我平日也很习惯直接用HTML来写blog。 我认为最好的排版就是只要你按照某种习惯写，不需要任何多余设置，也可以让文章看起来舒服。幸运的是，wordpress可以帮你做到，从word里先排好再复制过来根本就是庸人自扰。 话说回来，其实WP内置的tinyMCE是可以粘贴来自word的文本，在编辑器工具栏中有一个带有”W”字样的按钮，从这里粘贴，可以让文章少一些垃圾代码。UEDblog上那篇文章，在我的协助下，已经删掉了那些垃圾代码。 PS：我把文章的显示改成段首缩进两格了，只在CSS中增加了一句”text-incident:2em”就搞定了。
October 9th, 2008 by 张磊
这标题是在实在写得太痛苦，其实就是一个小问题。新版的Wordpress自带了插件自动升级的功能。每次安装的插件有了新版本，只要点一个链接，就自动完成下载、解压、禁用插件、升级、重新启用这一系列步骤。我用起来觉得非常方便。但昨天发现公司内部用WP搭建的一个blog，没法自动升级。选择升级时会提示需要主机的FTP用户名和密码。 这个blog安装在linux系统上，第一感觉可能是权限的问题，反正是内部的服务器，随便折腾，就都设置成777。结果还是不行，就仔细地跟进去查了一下，发现问题在一个叫做“get_filesystem_method”的函数上。找到这样一个解释： (FTP) it only uses this when it detects that files it creates have the wrong owner name 一下得到了提醒，可能是因为跑PHP进程的用户名和WP文件夹的所有者不同。于是用chown命令更改了文件所有者，命令用法如下： chown -R www * 就是把目录下所有文件和文件夹的所有者改成叫做www的用户。这样再去尝试WP的自动升级，一键升级就能顺利进行了。
July 15th, 2008 by 张磊
下午看到后台的提示，WP有新版本了，马上就到服务器上升了级。比起以前的谨慎(还会去备份)，现在越来越信赖WP，也许是我越来越懒了。 升级的过程只要把新文件覆盖进去，然后去一下后台，会提示数据库需要升级。点升级，闪电一般就搞定了。No more steps。 暂时还没感觉到多大的变化——兴许是我太缺乏DIY精神，用MT4的经历实在不堪回首。WP这个强大的blog系统，越来越完善，越来越好用，希望它不要变得越来越微软。 插入图片时，居然发现有了变化。
May 14th, 2008 by 张磊
blog的服务器搬家之后我就尝试了WP-Cache和WP-SuperCache，它们的共同问题是启用插件后，我在后台打开它们的管理界面，只能看到空白，某个函数可能在执行过程中被终止了。 可是WP生成一个页面要查询几十次数据库，这个着实很汗颜。后来我用了Cos-HTML-Cache，但一味地生成HTML，虽然负载低了，灵活性降低很多。今天脑袋里灵光一闪，想自己写一个基于memcached的WP插件（服务器上有memcached）。于是打开WP-SuperCache想看看他的实现，顺手调试了一下。没想到这一下就发现了问题，不出所料，确实是程序莫名终止了。 if ( !wp_cache_check_link() || !wp_cache_verify_config_file() || !wp_cache_verify_cache_dir() ) { echo “<br>Cannot continue… fix previous problems and retry.<br />”; echo “</div>\n”; return; } 里面有这么一段，看样子是用来验证一些东西。我直接把这段注释掉，WP-SuperCache后台就可以打开了。后面都很顺利，现在WP-SuperCache工作很正常。 大致浏览了一下，程序里很多判断都可以去掉（前提是你很了解它的原理了）。阉割之后，应该还会快一些呢。
May 10th, 2008 by 张磊
昨晚就把Blog成功搬迁到国内的服务器上了，不过给子宁搬家的过程颇为痛苦。说来奇怪，同样地导出，同样地导入，我的blog一切正常，子宁的blog却全是乱码。使出浑身解数，还是没弄好，最后只好使用WordPress内置的“导出”，然后把内容全部导入到一个新安装的WordPress上，算是没有乱码了，但一些额外的信息（比如给文章加的Tag）就没了。 过程痛苦了点，但是用上了崭新的WordPress2.5，还是觉得很爽。之后看了一下blog的负载情况，生成一个页面要查询40+次数据库，实在有点心疼俺的宝贝服务器。想使用缓存，但安装Wp-Cache又出了问题，后来只好用了一个Cos-html-cache，其实就是生成html，虽然丑陋了点，但效果很不错。 接到家里的电话，心情舒畅很多。以后就不喊累了，好好做手头的事。
February 9th, 2008 by 张磊
我在更新的另一个blogE店评，当时用了MT而没用WP，主要是为了体验一下。可是一年下来，实在用着不舒服。想换到WP去了。今天就写写为啥不想用MT了。 模板复杂。其实我觉得MT很少有好看的中文模板，也许是我没发掘过。Fenng设计的模板被很多人（包括我）拿来用，也从一个侧面反映出模板的缺乏。不过好看与否不是我说了算的，但MT的模板实在很复杂——用WP时我可以随便修改模板，可是换了MT，一不小心，模板就被我搞坏了。E店评的模板，现在都没修复回来。 编辑器不好使。很多人可能写blog都直接用HTML的，这样更直接。我不是不会，今晚我还花了些时间给GF写了个简单网页呢。可是用HTML有时看起来也很繁琐，所以我在WP里还开着富文本编辑，用的MCEEditor很不错。MT里就实在不好了，给文字加链接时出来的居然是个模态的inputbox。话说回来，就是直接用HTML来撰写，MT里做得也没有WP好。 强制生成HTML并不科学。对于流量很大的网站，用静态页面可以很显著地降低服务器的压力，可是哪怕不用任何缓存的WP系统，在DH的Shared Server上，一天支持个数百IP还是没问题的。有多少人写blog有大规模流量呢？而用MT时，假如想把阿里妈妈广告位或是Adsense广告放在所有页面上，就只得重新生成一次所有页面；改了个页面上的东西，如果不重新生成，对以前那些文章就没用；改了一篇文章，会牵连很多页面一起重新生成。细节的东西就不说了，很麻烦。 别的也没了，这3个理由，也足够说服我以后都不用MT了。可能还是因为我不够厉害，所以才驾驭不了MT——我订阅的一些牛人，貌似都用着MT。
November 24th, 2007 by 张磊
给某人改了一下blog的地址格式，用了”archives/123.html”这样的结构。后来的几天，流量有了极大的进步，现在的流量是原来的两倍了。我看着心痒，于是也想改成这种格式。我现在用的格式是”archives/123″。 有人说，直接去后台修改不就可以了么。用自定义链接地址，填进去”archives/%post_id%.html”，就可以工作了。没错，但是这么做原来的地址会无法访问。想象一下从百度搜东西来到我blog上得到404提示时那兄弟的沮丧吧，所以，还得想办法把原来的链接给转过来。 想到什么了？对，301跳转。 先照上面第二段的做法改好链接格式，不出意外的话打开你的首页就能看到链接地址已经变了。打开服务器上blog根目录下的.htaccess文件，在Rewrite Base那行之后，第一个RewriteCond之前，加入一行： RewriteRule ^archives/([0-9]*)$ http://yourdomain/archives/$1.html [L,R=301] 把yourdomain改成你的域名。上面这一行做的工作就是，把原来对archives/123的请求，用301重定向到archives/123.html。保存这个.htaccess文件，试着访问下archives/123，是不是已经安全“转移”到archives/123.html了 当然，让搜索引擎那边改起来需要一个相当长的过程，我的1100多篇文章，估计地址在短时间内不会都改掉。但搜索引擎对301是很友善的（这个是大家的看法，我的一个小站就因为301被Google封了）。 上面对于.htaccess的操作，也可以用于别的需要301转向的场合。
