昨天drupal又出问题了，一个原因是文章误操作，另外就是我想清空缓存数据的时候，执行到一半出了一个mysql超时的错误。于是所有的页面都打不开了，都是说“你访问的页面不存在”。
然后去truncate掉所有的cache*表，没有效果。
折腾了半天，想起还有cron.php这个程序，运行了一遍，还是没有用，最后是再运行一次update.php，执行了就恢复正常了。
虽然drupal的缓存机制很强大很有效，然而一旦出了这样的事故还是挺麻烦的。
在之前的一篇日志中提及，由于某个利用book模块建立的手册过于臃肿，导致，生成手册纲要的时候耗费很多服务器资源，包括mysql的内存。
内容上的整改：
1.把深度大于4的节点都上移了，由于只有一些深度为5的节点，因此在后台用一个update语句处理了：
update menu_links set plid=p3,depth=4,p4=mlid,p5=0 where depth=5;
2.刷新页面的时候发现节点链接并没有显示在原节点的父节点的父节点的页面中，到
代码上的修改：
drupal/include/menu.inc
define(’MENU_MAX_DEPTH’, 9);
改为
define(’MENU_MAX_DEPTH’, 4);
这样，生成手册纲要的时候就只有节点深度3及以上的了。手册纲要在服务器上生成的时间实际上减少得不多，减少的是传输的数据，页面形成的时间也缩短了。再看看怎么改module/book/book.module吧。
昨天在做内容录入的小兄弟告诉我，drupal好像内存不够了。
我一看提示信息，确实是内存不足了，目前这个book手册上的node已经接近一万条了。看上去真是壮观。
查了一下貌似没什么解决办法，于是在php.ini中加大了内存允许，原来是128m，改成256m了。然而词条还会陆续增加，我想这也不是办法。
查了一下问题所在，大概是在生成条目的地方会递归多次，就先把depth深度比较大的node做一些处理，提上来或者删掉。
然后再考虑做深度限制。
另外由于条目本身很有规律和层次感，可以考虑在生成条目表的时候省略掉那些叶结点。
drupal是个不错的系统，然而做大了之后需要底层干涉太多了。
几个月前为财富同道会搭了一个drupal平台，供财经人士编辑中国股市的投资词条：财富投资手册。
建了几个角色，有内部编辑，普通编辑等等。
drupal在大多数情况下都是很好用的，时间一长会出现有编辑权限的人却提交不了编辑页面的问题。刚碰到这个问题的时候，我尝试的各种办法，包括重启web service，重启web server，重新设置用户权限，都解决不了这个问题。
后来总算在一个drupal的讨论区上找到答案。
Administer->Content Management->Post Setting下，如果发现有Rebuild Permission的链接的话，点击该链接，那么权限的缓存就会重新设置，一切恢复正常。
这种问题一般出现在自定义node type比较多的站点中，而自定义node type确实又是drupal吸引人的地方。
假如上述办法仍不奏效，可以到drupal的数据库中，检查node_access表是否只有那标准的一行。
如果Rebuild Permission链接找不到，而node的访问权限确实出现了问题，可以直接在node_access表中加入一行任意的内容，触发它显示Rebuild Permission的链接。