Plone-4.3.18 的内容有四个比较重要的日期
创建日期:'creation_date'
修改日期:'modification_date'
发布日期:'effectiveDate'
失效日期:'expirationDate'
其中发布日期和失效日期可以登录后进行修改,另两个没有提供修改功能。我的页面ZPT中列出内容时用的修改时间进行排序,出现了两个问题:一是修改或新建内容后的日期总是比实际时间晚13个小时,上午上传的就显示日期为前一天;二是如果修改了以前创建的内容,自动在排序中变为最靠前,但有时这并不是自己想要的效果。
我的页面ZPT中每个栏目只取出排序最前十几项显示,对于成百上千的内容,分类和排序意义很小,还是必须依靠搜索进行定位。所以感觉这都不是什么大问题,之前一直没有想去解决,前一段时间在网上看到了一篇文章:
http://www.315ok.org/blogfolder/658/@@base_view
设置调整内容创建、修改时间的脚本
通过ZMI将下面的python脚本文件添加到站点根:
#set creationDate and effectiveDate to a given
datedate="-".join(traverse_subpath)
try:
d= DateTime(date)
except:
return "problem with subpath '%s'. usage: setdate/YYYY/MM/DD" % date
context.setModificationDate(date)
context.setCreationDate(date)
context.setEffectiveDate(date)
context.reindexObject()
return "date on '%s' successfully set to %s." % (context.title_or_id(), date)
如果是dexterity内容类型,将没用setCreationDate方法,应该直接设置creation_date属性。
看起来方法并不复杂,就起心来试着解决那两个问题,结果居然断断续续花了十几天的业余时间才解决。还是再次证明了我以前的结论“Zope/Plone中一点点小问题的解决都要大费周折”,下面将方法记录下来,怕以后又忘记了,哈哈
一、安装collective.datehacker用于设定Archetypes类内容的创建和修改时间
按315ok.org那篇博文提供的思路在ZMI中/Plone目录下新建 Script (Python),然后登录试用,无论context.setModificationDate(‘2020-02-02‘)或context.modification_date = DateTime('2020-02-02')怎么写都不行,设定发布日期的确可以生效(但是Plone已经提供了修改界面,没意义),修改日期要么不变,要么就变为当前日期,就是不能改成设定日期,在网上搜了一堆文章,试了又试,基本上准备放弃了,还好及时搜索到了https://github.com/PloneGov-IT/collective.datehacker,文本介绍正是想要的功能,但是一看版本,2011年后就再没有更新了,再一看介绍中,居然连Plone 4.0下都没测试,WTF
TODO
====
* Register someway, somewhere, the hacking operation
* Test on Plone 4 (it must work, but is untested)
好歹作者还蛮有信心地写了句:it must work,试一试还是有必要的,我的Plone-4.3.18是用zeo模式安装的,在buildout.cfg的[buildout]、[client1]、[client2]三段中的eggs 和 zcml 序列后都加一行 collective.datehacker,停止正在运行的服务,重新buildout,完成后显示的版本是collective.datehacker = 0.1.0a0,看来pypi中的和github中的还有点儿不一样github中的是0.1.0a
启动plone,用浏览器连接出错,服务根本没起来,在buildout的世界里这太正常了,出错是常态,一次成功才是偶然。“如果一个Pythoner疯掉了,一定是被buildout给害的”,哈哈,停止正在运行的服务时发现client1和client2根本就没真正运行起来,只好用调试模式,开两个终端,
第一个:
root@mydebian204:/opt/plone/zeocluster# bin/zeoserver fg
启动正常
第二个:
root@mydebian204:/opt/plone/zeocluster# bin/client1 fg
有错误提示,没拷贝下来,大概是以下的意思
/opt/plone/buildout-cache/eggs/collective.datehacker-0.1.0a0-py2.7.egg/collective/datehacker/browser/configure.zcml中引用的Products.Archetypes.interfaces._base.IBaseObject不存在
进行修正
将文件configure.zcml中的
Products.Archetypes.interfaces._base.IBaseObject
去掉base前的下划线,改为
Products.Archetypes.interfaces.base.IBaseObject
保存,在第二个终端再次尝试
root@mydebian204:/opt/plone/zeocluster# bin/client1 fg
人品暴发,居然没有出错,用浏览器进入也正常,说明服务启动了。用管理员权限登录,找一个 文档,在浏览器地址栏URL后加/@@hackdates,举例
原网址是一个页面
http://10.16.97.204:9080/Plone/doc_public/technotes
则直接加/@@hackdates
http://10.16.97.204:9080/Plone/doc_public/technotes/@@hackdates
原网址是一个文件
http://10.16.97.204:9080/Plone/doc_public/95.pdf/view
则只在文件后加/@@hackdates
http://10.16.97.204:9080/Plone/doc_public/95.pdf/@@hackdates
在表单中修改,保存,发现问题一解决了。当然只针对Archetypes类内容,不要指望对Dexterity类内容有效,Plone5就别想了
二、采用TZ Asia/Singapore设置解决时区问题
前文提到Plone-4.3.18修改或新建内容后的日期总是比实际时间晚13个小时,但我的debian-7.11.0-amd64的时间是对的
root@mydebian204:/opt/plone/zeocluster# date
2020年 06月 12日 星期五 23:57:30 CST
在网上搜索到了以下文章
https://stackoverflow.com/questions/14983923/plone-4-2-4-shows-incorrect-local-time-3-5-hours-ahead
说明在buildout.cfg的environment-vars环境变量中设定TZ就可以解决问题,但是Zope/Plone中问题的解决不可能这么简单,不整点儿幺蛾子出来才怪呢~!@#¥%……&*()——+
我先在buildout.cfg的client1、client2两个段中environment-vars环境变量中设定TZ为Asia/Shanghai,运行buildout,测试时间还是不对,只是从晚13小时变为晚8小时
不必每次都buildout,太费时间,buildout只运行一次,之后可以直接改以下配置文件中TZ所在行
/opt/plone/zeocluster/parts/client1/etc/zope.conf
<environment>
zope_i18n_compile_mo_files true
PYTHON_EGG_CACHE /opt/plone/zeocluster/var/.python-eggs
TZ Asia/Shanghai
</environment>
/opt/plone/zeocluster/parts/client2/etc/zope.conf
<environment>
zope_i18n_compile_mo_files true
PYTHON_EGG_CACHE /opt/plone/zeocluster/var/.python-eggs
TZ Asia/Shanghai
</environment>
然后就是一通乱改,以下都试过了,就是不行
TZ CST
TZ GMT+8
TZ Asia/Hong_Kong
TZ Asia/Taipei
TZ Asia/Chongqing
TZ Asia/Shanghai
自己的强迫症得改,Asia/Shanghai还是晚了8个小时,于是我想不设在东8区,再向东试试,时差只两三个小时就无所谓了,
https://24timezones.com/time-zone/gmt+14
找到了最东面的 Pacific/Kiritimati,这样就是晚2个小时了,结果服务都没有起来,说是无效的TimeZone,我去,明明pytz是有的
root@mydebian204:/opt/plone/zeocluster# bin/zopepy
>>> import pytz
>>> pytz.all_timezones
略
>>> 'Pacific/Kiritimati' in pytz.all_timezones
True
>>> ^D
root@mydebian204:/opt/plone/zeocluster#
然后漫无目的的乱填TZ,结果试到东9区的东京 Asia/Tokyo,发现时间由设定为东8区的上海晚8小时变成了早1小时,而不是想像中的晚7小时,这就是Zope/Plone,就问你服不服,能不能理解,反正我是不能理解为什么。东京可以,那就在东8区不局限在大陆和港澳台,试了一下 Asia/Singapore 完美解决了第二个问题。就这样误打误撞地折腾出来的结果,对也不知道为什么对,错也不知道错在哪里,对Zope/Plone可以说是旧仇未雪又添新恨,哎。~!@#¥%……&*()——+