关于这个插件,大家已经讨论的差不多了,我汇总一下,然后添加一下个人的理解。
当时开发这个插件,主要是由于我用的国外的共享服务器,共享服务器对于CPU和内存共享上都有比较苛刻的限制,
而Joomla在安装了比较多的Plugins和Modules之后,可能要访问十多次甚至更多次数的数据库。即便是很多Plugin和Module所取的数据相同,也不能共享数据,都要去数据库里面取一次(Joomla机制所致,方便的扩展,但数据却是不能共享,只能自己取自己的数据,如果数据可以共享,又可能导致安全方面的问题)。
虽然Joomla Cache可以解决问题,但是每次请求还是要执行不少的Php代码,当时就想能否将之存为静态页面,使得以后用户来取的时候,使得服务器直接将之作为静态页面返回给用户。
做法很简单,就是按照请求路径,在服务器端生成相应的html文件。使得下次同样的请求,apache服务器可以直接定位到这个html文件,而不用调用mod_rewrite,再重新调用index.php文件。
下面解释一下插件的几个局限性:
1.为什么Url必须以html来结尾。
Apache返回给浏览器中的每一个文件都包含一个Header叫Type,从而浏览器知道如何解析这个文件。
而Apache内部定义了根据文件后缀来生成这个Type Header信息,如果想让浏览器正确的显示页面,这个Type Header 必须是 text/html。如果url是以html为后缀,Apache就自动将文件的type定义成text/html类型,如果url没有任何后缀,Apache就将Type定义为text/plain。我不知道如何让Apache将文件类型自动定义为text/html,只好要求url以html为结尾。
如果不以html为结尾,浏览器会直接显示html的source code.
更多细节:
www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
2.为什么Windows下不好用。
Windows下面不支持url rewrite,使得url像下面:
www.xxx.com/index.php/hello/word.html
如果想让IIS服务器直接定位到word.html,就必须在Joomla根目录下生成下面结构的目录和文件
index.php/hello/word.html
其中index.php是目录,而我们知道在Joomla根目录下已经存在了index.php文件。
我们没有办法生成一个同名字的文件和目录。
3.为什么要手动清除文件。
程序可以每次生成文件后,将生成文件的路径记录到数据库中,同时记录一下时间戳,定时或者一次更新所有时间过期的文件。如此做跟cache就没有什么本质的差别,并且还每次更增加了1次数据库的访问。
所以就没有添加这个功能。
4.不能跟comments,hits,vote等动态功能并存。
这是这个插件的弱点,没有办法。
当然这也不是一个不可能问题,只是需要用ajax去调用,然后动态显示这些内容,不但要考虑修改原来的com_content还要考虑可能的其它可能的插件组件,这样搞太复杂,可能效率还不如不静态化的好。
对于不需要动态功能的,这个插件才有作用。
用content static的最大目的,就是利用joomla的发布功能和模版功能,来发布静态文章。