THE MOMENT, THE MEMENTO

昨天修改一个网站使其能在Chrome下正常显示，其中很多要改的是Javascript的代码。修改的过程中才充分意识到IE提供了太多的非标准的功能调用了，最严重的就是.click()方法了。

在一个功能里要程序能自动点击一些链接，原先的设计是找到a元素，然后执行元素的.click()方法，这个方法在Chrome下不能执行，而且也找不到标准的相对应的方法。试图从jQuery的源码里找到它的click()方法的实现，但是代码太复杂看不懂。

在Google上搜索了好多条目后，终于在一个网页（最原始的出处已经无从分辨了，只好贴第一个找到的）里找到了解决方案：

if(document.all)
{
document.getElementById(name).click();
}
else
{
var evt = document.createEvent(”MouseEvents”);
evt.initEvent(”click”, true, true);
document.getElementById(name).dispatchEvent(evt);
}

有用的就是else下面那三行哈，相信以后还会经常用到，先记到这里。

前情提要：最近开始好好的学习Zend Framework(zf)。其实以前也学了一阵子zf（再之前学的就是FleaPHP了），那还是1.5版本的时候，可惜忙着其它事情，就没有学下去，一个项目也就扔了一个半成品在那里。暑假开始做一个单位的项目，就重新把zf捡了起来，当然现在用的是1.8.4了（虽然zf版本已经到了1.9.1，可是zend-ce用的还是1.8.4，它什么时候才更新呢？）。

项目是还一边学着一边做的，同时看着的有快速入门（也是Zend Studio上的example项目），参考手册，入门教程（从1.5.2到1.6.3），以及www.phpchina.com上多模块应用程序的相关文章（如：用Zend_Application实现多模块(modules)及多模板(templates)应用程序）。本来是希望多学些东西，然后直接写出理想的程序雏形，可惜这些从简单到复杂的教程内容混杂在一起，自己的代码也就不在纯洁了，开始互相干扰了。

经过几天的努力建立了简单的MVC雏形，主要是写了一个统一通用的EntityManager（我的目标是能像Java的EJB 3.0一样管理Entity，只是不明白Zend为什么没有提供这样的结构）花了比较长的时间。

Layout是参考着入门教程来写的，当写完Bootstrap的_initViewHelpers()时，我想为什么不把view的一些设定放在application.ini中去呢？于是便参考了phpchina.com上面的文章设置了resources.view.*的内容，其中包括resources.view.encoding=”UTF-8″。

这样问题就来了。

开始往layout.phtml中写入$this->baseUrl()时，发现系统不能正常显示：

Fatal error: Uncaught exception ‘Zend_Loader_PluginLoader_Exception’ with message ‘Plugin by name ‘BaseUrl’ was not found in the registry; used paths: Zend_View_Helper_: Zend/View/Helper/:./views/helpers/’

虽然路径是对的但是就是找不到BaseUrl助手；与此同时，在Controller中设定的title变量也不显示。然后，这两个内容在views/scripts/index.phtml中是可以正常显示的。

开始以为是入门教程有问题，认为可能是Layout和View的调用顺序不一样，有些东西在layout中没有初始化。于是到处查Layout和View的差别，甚至试图在layout和view script中分别把$this变量打印出来比较差别，最终还是徒劳，还在想是不是该好好将参考手册乃至于API精读一下。

今天下午，不知怎的，突然开窍了。心想，既然人家的入门教程写了这么多人看都没有问题，那么上面的东西应该是对的，为什么不放弃自己项目中杂七杂八的想法，老老实实的遵循教程中简单的思路试试看行不行呢？

于是重新新建一个项目，遵照入门教程的步骤一步步进行（当然由于是测试layout，数据库以及Model就没有建立了），发现这样就不存在之前的问题。这说明问题是我自己项目中混乱的代码引起的，就开始排查。

最后，发现问题就出在resources.view.encoding=”UTF-8″这句话上面，即便是我将值改成默认的ISO-8859-1，错误依旧。解决办法就是将这句话去掉。

至于为什么这句话会引起这么大的问题，暂时先不管了，以后深入使用View的时候应该就会了解了吧。

思考：

这次错误虽然只是短短的一句话，但是却让项目陷入了停顿状态，让我近一个礼拜都心神不宁。写下这篇文章目的一个是让其它人遇到相同问题的时候，能搜到解决方案；此外，也在此审视一下自己的一些态度方法。

首先，是自己贪快、贪多。一开始就没有好好遵照某一个教程完成一个项目，很多方法只是看了文章还没有实践，就想着开始改进它。教程看到一半，就想依照心中实际项目的需要，又从其它教程中拉入自己还不是很熟悉的内容进来，最终让代码失去了控制。就好像，一种内功连到一半还不熟练，就想把另一种不熟练的内功融合进来，这样轻则神志大乱，重则吐血而亡。这个似乎是我性格中的毛病，在很多方面都有类似的例子，以后一定要切记、切记呀。

其次，当发生错误的时候，始终在自己的思路中钻牛角尖。老是想在一团混乱中找到一丝线索，乃至于把简单的事情复杂化，要去追寻事物的原理。事实上，这样一个简单的东西，人家教程里的东西就已经是一种经验（模式），不会错的，就是大家该遵循的。如果我及早放弃自己的思路，老老实实按照人家经验的做法，问题就能提早解决。其实我也经常说别人不肯放弃自己的思路而遵循别人的思路去解决问题，只是没想到自己也犯了这样的毛病，以后切记、切记呀。

前面说到我去年开始接管一个ASP的网站，让我接管最主要的目的就是让我重新设计页面。

当我拿到这个网站，登录管理平台后才发现这个网站用的是动易的系统，但具体是哪个版本就不清楚了，显然不是最新版也不是2006版。问了之前的管理员，也得不到答复，曰忘记了。

设计或者应用一个新的网站系统很容易，可是数据才是网站最核心的东西，如何把原先网站的数据给迁移过来，过年前就一直困扰着我。在网上有搜索过，答案是可以升级，但是要一个版本一个版本的升。我的神呀，一个个版本的升那会要多少个步骤呀，而且还要每个步骤都很顺利，最重要的是现在这个是哪个版本还不晓得呢。

昨天在PowerEasy.net上面的下载页面里发现了一些升级程序，接着又发现了动力文章系统从1.0版本以来的主要版本：1.0、2.0、3.0、3.51、4.03、2005、2006、SiteWeaver（这个目前的开源版本，也是最新版）。其中3.0版到3.51版要做数据库升级，3.51版到4.03版要做数据库升级，4.03版到2005版要做数据库升级，2005版到2006版要做数据库升级，2006版到SiteWeaver版要做数据库升级。这样也就是说可能要执行5步的升级，等等，2005版可以直接升级到SiteWeaver版，那么又可以少一步了。

幸好能找全所有的版本，对比了一下目录结构和数据库结构以后，基本上可以确定现有的系统是3.51版本或者是这个系列的。现在就是看看怎么一层层的给它往上升了。想到这里我心里又忍不住要把过去的管理员责骂一顿，太懒了，怎么一次升级都没有做过呢。。。。。

想来，像我这样从这么低版本升级上来的估计很少数了，就把这个过程记录下来，作为纪念吧。

以前没有做过动易系统的升级工作，所以只能摸着石头过河。幸好，主要的升级方法基本都类似。先说前面的方法，从版本A升级到版本B需要在B的ASP代码环境下进行，所以要升级到新版本，就得先安装新版本的ASP代码。如果你有测试网站，那就好办了，升级完一个把代码清除就好了；如果没有测试网站而且希望升级不会对原网站有很大影响的话，那就只好建一个子目录如PE4、PE5、PE6，把新版的ASP代码放在里面，然后进行升级了。

下面说一下基本的升级步骤：

1. 将新版ASP代码上传到测试环境（测试网站或者目录）中，要确保新版的数据库是新的
2. 修改conn.asp中数据库文件的地址后，再上传
3. 将旧版本的数据库上传到测试环境的根目录下
4. 将升级程序上传到测试环境目录下
5. 在浏览器上访问升级程序，记录下第一页显示的操作步骤，然后根据它的提示进行后续的操作
6. 如果自己有测试网站，可以安装相应新版本的组件，然后登录测试。（根据上一步的提示可能会需要执行install.asp）
7. 为了安全起见，将升级好的数据库下载下来，备份在一个地方（最好是压缩包，这样可以避免意外打开的修改）
8. 将测试环境里的ASP代码清除

就这样每升级一个版本就重复操作一次。

完全升级完以后，现在发现几个问题。一个是原先的首页是自己修改index.asp（设计+代码函数）出来的，现在2006版的首页是从模板里生成出来的，所以首页就没法用了，要重新设计。其次是原先3.51版的动力文章系统没有频道的概念，所有的文章包括栏目都是在一起的，到了2006版以后，要根据功能划分出不同频道，同时还要把相应的文章移动到相应的频道去——事实上只有频道确定了，首页才好设计，所以栏目划分很重要。还有就是原先3.51版的动力文章系统里管理员和用户是独立的，即管理员可以没有前台的用户名。而2006版的系统里，除了超级管理员，普通管理员都还必须有一个前台用户名，因此还要给各个普通管理员建立前台用户。

这次升级测试只能想到这么多问题，也许要真正进行升级以后才能发现更多问题。

去年开始接管一个单位的网站，是用ASP制作的，其数据库为了防止别人下载命名成了abc.asp的形式。

管理网站首要的任务就是备份、恢复了，尤其是数据库。通常都是用FTP下载下来， 在本地进行备份。

FTP一直都用图形化工具FileZilla，文件的传输类型（文本或者是二进制）默认都已经设定好了，所以也就基本上都忘记这回事了。

刚接管这个ASP网站的时候，用FTP下载下数据库，然后再传到一个新建的网站上做修改测试。可新网站提示说数据库格式无法识别。开始我还想是不是下载下来的数据库被我的Access 2003打开修改以后被保存成2003格式，所以机器上的旧ASP程序认不出来。此后，就一直小小心心不敢在本地直接修改数据库，只能通过管理界面提供的接口。有一次为了删除所有的垃圾留言，还特地修改asp源代码把删除一条的按钮改成删除全部。

过了一个年以后，就把这个约束给忘了。这次在无法登录的情况下想要修改数据库复制一个管理员出来，最后在回传数据库文件的时候又出问题了。理所当然的，我又以为是数据库格式问题。可是后来的发现证明的我想法是错的。一个发现是Access（不论是2003或者是2007）在打开数据库的时候会显示此数据库是什么格式，是2000或者2003，即便修改过以后，格式不会改变；另一个发现是我将未修改过的数据库回传会网站的时候也遇到这个问题。这就说明不是Access格式的问题了，而纯粹是FTP传输过程中改变文件内容了。当想到FTP传输过程的问题是，我突然想到自己传的是一个ASP文件，而FTP工具肯定将其作为文本文来传输了，文件内容自然就被改变了。

想到这点，赶紧在设置里将文本类型的ASP扩展名删除，再进行回传。这下就没有问题了。嗯，这下终于松了口气 ，以后可以随便修改数据库文件了。只是不知道以后再过多久我会不会又忘记这个设置的问题，而且那个时候会不会记得来看这篇文章。但愿是不要忘记的好。

最近出了一批Web的新书，有很多是开始遵循Web Standard。现在想想一些新技术新思想要进入国内还真的是慢呀，从形成文档，到写成各种书（权威指南，手册），到翻译成中文，基本上要一年的时间。而国内要开始普及这些标准教材也要现在才能开始，这还能指望学校里的老师及时更新自己的知识，给学生讲这些新的东西。

嗯，废话少说，先把最近要看到书列出来吧： (全文…)

“The Web is Agreement”其实是一张来自Flickr的手绘地图，被Solidot戏称为魔戒风格的“Web技术冒险地图”。它的确很有意思，一张图上摆满了好多Web技术，有趣的是还被设计成善良阵营、邪恶阵营。

地图从左到右是作者心目中的善良阵营和邪恶阵营……开源社区、创作共用协议、web2.0里的blog圈,tag,mashup技术，RDF, RSS之类的开放架构都在左边……而微软的FUD，DRM技术，病毒，垃圾邮件，SOA之类的企业架构被放在右边……出人意料的是“google的全知全能之眼”也在邪恶一边，是因为google的平台不够开放还是因为用户隐私问题？中间的圣山顶端是W3C组织和IETF，很多人在下面争吵和游说…… 地图从下到上的象征意义比较复杂，有点像web技术从简单到复杂，也像是从前端到后端的关系……最下面是最简单的URL地址和REST/HTTP架构的设计者Fielding博士……往上是各种前端技术，javascript/ajax是一座跨越“富用户体验”的桥梁……最上面的终点是一片混沌，叫做“不兼容的大漩涡”，右边的魔多软件（微软）往里面排入ie，activex之类的私有技术，左边的开源社区往里面排入更多的技术，产品和代码……从perl, php，java到linux……

当然对于我来说，对这些技术是不会分那么清楚的，只是这张图可以让学习者了解Web世界的技术，不过Flickr上注释基本上都看不懂。

想给Wordpress添加上Tag的功能，于是找到Simple Tags的插件。安装不成功，阅读了readme后，发现1.1.1版本的Simple Tags需要Wordpress 2.3的支持。

于是乎，只好下载了新版的Wordpress，进行升级安装。将新版文件替换好以后，执行Upgrade.php一直不成功，不解。开始一直以为升级中途中断造成数据库不一致。后来在终端下执行php upgrade.php，得到错误Allowed memory size of 8388608 bytes exhausted。

Google，阅读了中国IT技术论坛的一篇文章后得知原来是PHP对script使用内存的限制，默认是设定为8MB，而如果script要求使用超过8MB的内存，就会发生错误。解决这个问题的办法就是加大或者这个内存使用限制就可以了。

加大 8MB 記憶體使用限制，有兩個方法擇其一即可：
在最上層的 PHP script，加入一行
ini_set(”memory_limit”,”12M”);
修改 php.ini 裡的 memory_limit 的設置值 8M 改為 12M
memory_limit = 12M

如果擴大到 12M 仍然相同的錯誤發生，則再加大 12M 限制。但是請注意，應該還是要去寫出好的程式；而不是加大記憶體限制，不管coding 好不好。

三，最后，经过咨询杨波兄弟，修改wp服务器根目录下wp-config.php文件。

办法是：在该文件中第一行加入：ini_set(”memory_limit”, “-1″);

于是我在wp-config.php的所有设置前面添加了ini_set('memory_limit', '12M');之后就好了，升级顺利完成。

一直以来想找符合Web Standard的教材或者书籍，可是中文的实在太少了，到处充斥着的都是HTML 4.0的东西。甚至有些2007年7月出版的书还继续使用着HTML 4.0，足见很多作者自身知识都还没有更新，就开始写书，纯粹是为了赚钱，非常的不厚道呀。
最近终于在书店看到了一系列的关于CSS2.1, XHTML的书籍，先挑了一本比较值得买的《精通CSS-高级Web标准解决方案》看了起来。这个本书是Andy Budd, Cameron Moll, Simon Collison三个人写的，中文译本由人民邮电出版社了。
阅读到快最后面了，想起来有些常用到的东西还是记在这里的好，便于查找，毕竟书是不可能经常带的，甚至有可能丢失（我原先的Ajax基础教程现在就已经不知道借给谁了）。

这里是关于写CSS的时候遇到浏览器bug或者不是bug，但是CSS不生效，该到什么地方寻求帮助。 (全文…)