- 全站访问日志见 ActionLog 页面(需密码)。
- 反垃圾信息的自动封禁设置见 Blocklist 页面。
- 全站所有页面的权限设置情况见 AuthTable 页面。
- Wiki 系统组件的版本升级检查见 Recipe status 页面(需密码)。
- 服务器配置方式和参数记录在 ServerSet 页面(需密码)。
==待处理==
- cron 自动运行的 duplicity 虽然完成了工作,但是却没有通过 exim4 记录邮件日志。可能原因在于 Exim 没能对 root 账号的邮件正确投递。
gmail 作为 smtp 邮件中转,可能存在每天发送邮件总量限制,需要进一步明确(目前看大约每天支持发几百封的样子)。(所托管的 SNS 系统流量降低,已经不需要很多的邮件流量了。)
2023-12-24
- 还原 Joomla 系统中的数据库数据,重置为 2017 年 3 月 8 日的版本。
- 关闭 Joomla 系统的评论功能(k2 comments);关闭链接重定向功能。这样避免在数据库中产生海量垃圾信息。
- 稍微调小 lighttpd 的并发连接数限制,以避免资源过度消耗。
2023-01-03
- 改为使用 snapcraft 环境下的 duplicity 版本,更新更及时、依赖包冲突也更少。
2023-01-02
- 安装了 MarkDown 语法解析插件 MarkdownMarkupExtension,于是现在可以像下面这样在页面中使用 MarkDown 语法了(语法可参考 Markdown’s formatting):
(:markdown:) ## 这是一个二级标题 (:markdownend:) |
这是一个二级标题 |
- 由于 PHP 版本太低,因此使用的是 PHP Markdown Extra (classic) 实现。
- 此时有个很奇怪的 Bug,插件硬说 markdown.php 文件不存在,注释掉 markdownpmw.php 文件中与“Classic parser not available.”提示信息相关的 if-return 那两行就一切正常了。
- 由于 PHP 版本太低,因此使用的是 PHP Markdown Extra (classic) 实现。
- 将来如果涉及页面在 PmWiki 语法与 MarkDown 语法之间做转换,可以考虑使用 PmDown - PmWiki to Markdown Converter 来处理。
2022-09-20
- 改为使用 NGINX 作为反向代理封装 Lighttpd 提供的所有 cgi 服务,以绕过 Lighttpd 的反向代理不支持 https 的问题。(为避免应用版本兼容性的麻烦,所以沿用了 Lighttpd 配置好的 PHP 服务。这样多包了一层可能会浪费点资源。)
- 禁用 dr4ft 服务的自动启动,以节省内存资源。
2022-08-10
- 基于 Let's Encrypt 证书(利用 snapcraft 环境下的 certbot 工具来自动维护),启用本站 https 服务。
2022-08-05
- 基于 python3 环境通过源码手工安装,更新 Duplicity 版本到 0.8.23。
- 数据定时备份脚本改为使用东京大区的 S3,以改善数据备份速度。
- 删除了 gcc、g++、make 软件包,以稍微加强服务器安全。
2020-04-16
- 清空已下线的 blog.elias.cn 站点中的垃圾评论,以降低数据库备份负荷。其他站点中的垃圾信息似乎不严重。
2020-04-13
- 把 Debian 主系统从 Jessie 升级到 Buster 。
- 重新整理了 lighttpd 的配置文件,因新版本跟旧配置文件内容不兼容……
- 让 lighttpd 强制使用 PHP5 而不是 PHP7 ,以便让老网站代码可以无修改运行。
- 在 lighttpd 配置文件中禁用了老版本的几个博客站点。
- MySQL 被系统强制替换成了 MariaDB。
- 重新整理了 lighttpd 的配置文件,因新版本跟旧配置文件内容不兼容……
- PmWiki 主程序升级到 2.2.127,以应对阿里云的安全警报。
- PmWiki 的 CookBook 组件 To Do 无法在当前 PHP7 下正常工作,因而禁用之。
- 升级 servatrice 到 2.7.4 版本。
- 升级了 dr4ft 到最新版本。
- 重置 duplicity 的备份状态为首次全量备份,以保存操作系统升级的最终成果。
2020-01-02
部署了 CachedNumberOfArticles CookBook 解决方案,替换了原来函数式实现的 (:numberofarticles:) 标记解析。
2019-12-04
因安全警报,升级 PmWiki 主程序到 2.2.96 。其他组件和设置未作改动。
2017-06-15
- 参考 LimitNewPagesInWikiGroups ,禁用了未登陆用户创建新 Wiki 页面的权限,以抑制猖獗的自动 Spam 情况。使用的具体代码见下:
# Only allow login user creating new pages:
array_unshift($EditFunctions, 'CreateDisallowed');
function CreateDisallowed($pagename, $page, $new) {
global $EnableCreatePages, $EnablePost, $MessagesFmt;
if (IsEnabled($EnableCreatePages, 1)) return;
if (PageExists($pagename)) return;
Redirect('Main.PageCreationError'); #or some other page,
# or use next two code lines instead of the Redirect above
# $EnablePost = 0;
# $MessagesFmt[] = 'Creation of new page blocked';
}
if (!$AuthId) $EnableCreatePages = 0;
2017-03-20
2017-02-21
手工检查配置文件,更新所有 Wiki 扩展组件到最新版本:
- 更新 PageTableOfContents 组件到最新版本(20150814),解决了通过目录跳转时定位不准的问题。
- 更新 Footnotes 组件到最新版本(1.0.0),以兼容 PHP 5.5。
- 更新 Blocklist2 组件到改为 PmWiki 高版本内置的 Blocklist 机制,以获得与官方版本更好的兼容性。
2017-02-14
为了兼容 PHP 5.5,升级了 Wiki 系统及主要 CookBook 组件,具体升级内容如下:
- PmWiki 主程序升级到 2.2.94 。
- 中文环境同步升级至最新版本。
- 升级外观皮肤 Glossy Hue 至 2.2.3 (31-Mar-2016) 版本,并手工再次进行针对上一版所做的外观定制(使用 git 工具对比发现具体的修改内容)。
- 升级 CookBook 组件:
- 升级 Cookbook:SourceBlock 组件到 2014-09-08 版本,所依赖的 GeSHi 版本仍然是 1.0 ,无需更新。
- SourceBlock 能支持的高亮语言见 GeSHi 支持的语言。
- 升级 Cookbook:Captcha 组件到 20151002 版本。
- 升级 Cookbook:SectionEdit 到 2015-05-21 - v2.3 版本,并参考 2008-10-09 的维护记录 进行了 CSS 设置的修改,以便改善 Toc 目录自动生成组件的版式。与 SourceBlock 组件出现断行处理冲突的问题可能随着这次升级被自动解决了。
- 升级 Cookbook:SourceBlock 组件到 2014-09-08 版本,所依赖的 GeSHi 版本仍然是 1.0 ,无需更新。
- 兼容性处理:
- 重新编辑 Site.SiteNav 和 Site.SiteFooter 内容,修正乱码(可能是由于 PmWiki 主程序升级导致的不兼容造成的)。
- 重新编辑 Site.PageActions、Site.EditForm 两个页面的内容,把对当前页面的引用代码由 {$FullName} 改为 {*$FullName} ,以便兼容 PmWiki 新版本的默认设置。目前网站没有使用 Site.PageNotFound 页面,而各个 SideBar 页面的内容都是写死的,也无需修改 。
- 部署 SiteAnalyzer 失败,改为部署 RecipeCheck 来检查过期组件,检查结果的访问页面是 Recipe status (需密码)。
2015-09-21
调整 Joomla 系统的 Session 存储位置为“无”(也即使用 PHP 默认设置),而不是“数据库”,以避免攻击者频繁更新 session 信息时生成巨量 mysql 日志占满磁盘空间。
调整 Wiki 设置,在调用 cookbook/captcha.php 脚本前先延长 Session 保存时间设置,以此尝试修复编辑提交验证码只有在二次尝试提交时才有效的问题。
2015-08-07
升级了服务器的 php 等软件包,结果 SectionEdit 插件在编辑时自动吃掉章节末尾空行的 bug 神奇地消失了。。(明确一下,似乎是点“编辑”链接后,二级章节末尾的空行会被吃掉,如果手动加上,倒是可以正确保存的。一级章节一切工作正常。)
2014-12-29
由于 Gmail 彻底被墙,exim 改为使用 sohu 服务器进行中继。具体配置要点参见 ServerSet#exim 。
2013-07-26
为了便于备份数据,用 vsftpd 架设了服务,但怀疑目录权限方面有不够安全的配置内容。
2013-05-22
受虚拟机内核版本限制,无法升级到 wheezy ,只好升级到了最新版本的 squeeze 。
下载并备份了本站的 Site.ActionLog 记录(07年到13年5月22日),并把原始记录移出站点,以节省服务器空间。
trac.elias.cn 中的 wiki 内容迁移到了 Wiki 的待办事项中,原 trac 网站已经做下线处理。
2013-04-25
WordPress 升级到了 3.5.1 ,安装了 NextGen 图片库管理插件,配合 iOS 上的 TinyDesk Writer 客户端使用。
验证码功能修复正常后,出现了为数不少的瞎改着玩的匿名编辑:)
2012-11-17
使用 WordPress 3.4.2 配置了 home.elias.cn 站点。
Captcha 在本站有个问题——编辑一会儿文章之后再保存文章时,经常会提示验证码错误。其实这是验证码超时造成的(源头是本站 php.ini 里面默认的 session.gc_maxlifetime 太短),可以在 config.php 里头在
2012-03-29
升级 beautifulcn.org 到 joomla 1.5.26 ,以及 JomSocial 2.6.0 。
2012-02-27
清除不再使用的网站文件,包括 anycare 以及 ftp.elias.cn 。
2012-01-29
手工修改 pmwiki/scipts/pagelist.php 文件,处理 2.2.35 版本修正的安全漏洞(参考 pmwiki-announce 邮件组中 2011年11月12日 下午6点20 的通知邮件“How to patch an older version of PmWiki”)。
2011-12-27
修改Blocklist,增加对“eval”和“base64_decode”两个关键字的过滤,以防止服务器被黑。。
2011-12-20
发现在 12月4日 晚上8点左右,Wiki 被黑掉了,被上传了 info.php 后门脚本, pmwiki.php 核心代码被改掉了。看 IP 来自伊朗(2.138.*.*),但具体利用的什么后门还没弄清。。
2011-10-26
再次修改Glossy Hue模板:
- 让模板先输出左侧侧边栏内容,方便页面之间导航。
2011-05-03
继续修改Glossy Hue模板:
- 将侧边栏调整到左侧,并稍微加大了侧边栏和正文内容之间的左右间距。
- 加大页头 Logo 位置字体。
2011-03-21
配置 exim4 通过 gmail 等发送服务器端邮件,防止邮件通知被其他邮件服务器当作垃圾邮件屏蔽。配置方法参考Exim 配置方法简要笔记。
2011-03-13
调整 PHP 的 post_max_size 和 upload_max_filesize 到 16M 。
2011-02-21
感谢 Arthur.Chen 老兄的提示,解决了 2009-04-07 维护记录中提到的ActionLog 插件的 Site.ActionLog 页面显示为空白的问题。
其原因在于和 SectionEdit 插件的冲突。因此在 config.php 文件中改为按如下方式引入 SectionEdit 插件,仅在 Site.ActionLog 页面禁用 SectionEdit 即可(写法参照 GroupCustomizations 中“Per-page customizations”一节的说明):
if ($page!='Site.ActionLog') include_once("$FarmD/cookbook/sectionedit.php");
2011-02-04
修复恶意编辑,并调整En.Resume页面编辑权限为“@admin”作为保护。
2010-11-26
激活了 php5 的 XCache 加速模块,但没有进行参数调优,启用后系统有能够感觉到的性能提升。
为 Wiki 应用了Glossy Hue模板,并对模板的页面宽度、背景图尺寸、字体大小、段落间距、 Action 栏位置和颜色、 Title 标签中信息的显示格式等方面进行了修改。并相应调整了Site.SideBar、Site.SiteNav、Site.SiteFooter的内容以配合全站模板;另外创建了En.SiteNav页面使英文页面有自己的英文页头导航。
为 Joomla! 安装了Update Manager for Joomla!扩展,并通过它升级了 Joomla! 主系统,解决了升级 php 版本之后报错的问题。
2010-11-23
更新服务器系统到 Debian Squeeze ,原有各种服务在新系统下的稳定性还没有检查。
更新SourceBlock以及它依赖的GeSHI到目前的最新版本,解决其与 php 5.3 版本兼容性的问题。
- 手工修正页面中的 GeSHi Error: GeSHi could not find the language 问题,也即手工修复原先指定的错误的 SourceBlock 语言参数。
- GeSHI 目前支持的语言种类可以通过 (: source langs :) 指令列出来。
2010-11-09
在新购买的 BuyVM 主机上利用 Lighttpd 的 proxy 模块建立了 Twitter 代理,专用于 WordPress 的 Twitter Widget Pro 插件(需要修改此插件的源代码,将对 twitter.com 的调用改为对 BuyVM 的调用。这一修改需要在每次更新 Twitter Widget Pro 插件时手工进行。)。
2010-11-05
调整了 PmWikiZhCn 页面组的权限,允许所有用户读取,但只允许 @admin 编辑和修改页面权限设置(修改页面组权限设置的办法是调整组内 GroupAttributes 页面的权限即可,参考Passwords文档中“Protect a wiki group of pages”一节的详细说明)。
根据Track Changes文档中“Shorter RecentChanges”一节的说明建立了最近所有更新(简洁)页面,并将此页面链接增补到了Site.SideBar侧边栏中。
另外修复了 PmWikiZhCn.SideBar 页面的坏链接。
2010-10-25
根据 Cookbook.Backlinks 在 Site.PageActions 中增加了页面反向链接,具体采用的是站内搜索风格。
经检查, local/config.php 中的 $EnablePageIndex
已经开启(能够提高站内搜索和 Backlinks 的性能,参见 PagelistVariables#EnableLinkIndex )。
为丰富 Backlinks 的显示内容,根据 Page List Templates 调整了 pagelist 和搜索功能的 #default 显示风格,除原先已有的页面名称之外,还添加了页面标题和页面 summary 的显示。具体参考了 pmwiki.org 官网当前的 Site.PageListTemplates 和 Site.LocalTemplates 设置。而对本站,只修改了 Site.LocalTemplates 而没调整 Site.PageListTemplates (因为 PmWiki 更新时,会默认修改自带的 Site.PageListTemplates )。
2010-09-06
准备启用 (:keywords word1, word2, ...:) 语法为各个页面标记关键字,以便改善站点 SEO 效果。(除 (:keywords:) 外, (:description:) 标记也是有价值的,完整的标记列表参考PageDirectives。)
手工修改了 pub/skins/pmwiki/pmwiki.tmpl 模板文件的 <title> 标签内容,调换了页面标题中站点名称和页面名称的位置。
关于 PmWiki 完整的 SEO 操作建议参考A set of best practices to Search Engine Optimization。
2010-08-19
PmWiki 支持 (:redirect:) 语法,实现页面间的重定向,用于移动页面后原页面向新页面的自动跳转。具体用法参考:PageDirectives#redirect
2010-03-17
参考CustomWikiStyles,添加了新的风格标签“ %note% ”用于强调。使用效果参考Wiki风格使用。
2010-02-25
安装了AuthUserCookie (实际上这个插件是我写的,里头代码倒是没几行,可是读懂 PmWiki 本身的处理逻辑花了好多时间……),可以利用 Cookie 实现“免登陆”功能。因为组件用到了 Cookie ,因此不得不在“/etc/php5/cgi/php.ini”里头打开了“output_buffering”选项,来避免出现“Warning: Cannot modify header information - headers already sent by ......”错误。
2010-01-22
按照WebFeeds的说明启用了RSS、Atom、RDF、DC格式的订阅支持。在侧边栏“最近更新”附近添加了RSS链接,并分别设置了全站和英文页面组(En组)的RSS自动发现。
2010-01-05
VPS 迁移到了另一个机房的主机,从头重新配置所有服务。发现新配好的邮件发送服务不可靠,只能发送到 gmail ,但会被 163.com 拒收。一个解决的办法是参照Exim4 配置让本机的 Exim 连接到远端 SMTP 服务器让它代发。不过目前需要发邮件的情况不多,暂时没有调整这个配置。
2009-07-05
修改了Site.PageActions,使登入、登出按钮能够随当前登陆状态自动切换,并且将对应的快捷键手工设置为“L”(也即在Mac下的FireFox中,可以用快捷键Ctrl+l访问登入、登出功能)。
2009-04-07
将PmWiki版本升级为2.1.27。发现ActionLog插件可以正常记录信息,但无法显示记录的信息(只能通过“编辑”行为来查看),目前原因不明。
2009-01-06
参考PageActions-Draft页面的说明修改了Site.PageActions的设置,给页面的Action栏增加了登陆链接,以方便认证。
另外发现Mac下的FireFox中,PmWiki默认模板的访问快捷键是Ctrl,于是Ctrl+e就是编辑页面,Ctrl+h就是查看页面历史。更详细的说明可参照官方网站上Access Keys页面的说明。
2008-12-14
减少了FastCGI的PHP线程数,以降低无谓内存消耗。
给Limbo安装了Cumulative patch v8,以提高系统安全性。
2008-11-09
把eAccelerator禁用了,这样PHP运行速度确实慢了(WordPress大致要比原先有eAccelerator的时候多消耗一倍运行时间),但省掉存储优化代码的共享内存,可以节省一些内存使用(本服务器内存实在紧张),并且网站的速度瓶颈目前不在PHP上,而是数据库和网络传输速度。
2008-11-01
给服务器cron内覆盖的指令添加“nice -n 20”的前缀,降低系统维护任务的cpu占用烈度,来测试是否能够减少/var/log/lighttpd/error.log中记录的PHP程序错误数量。结果证明,不会有任何改善。因为error.log中记录的主要问题是备份过程中有一段时间MySQL数据库拒绝访问,估计是因为导出MySQL数据的过程会造成MySQL暂时离线造成的,因而不会因为降低进程优先级而改善这种状况。
后来发现MySQL数据库拒绝访问主要是在备份时间段内存不足系统自动杀进程造成的,因而在11月9日禁用了eAccelerator来节省内存。如果仍然效果不佳,则考虑在备份系统时暂时停止httpd和php服务。
2008-10-25
启用了lighttpd服务的gzip压缩支持(mod_compress)。
2008-10-21
调整PmWiki设置,将上传文件大小限制由1.5M放宽到15M;另外增加对.tar格式文件上传的支持。
2008-10-15
为方便在Wiki与博客间转帖内容,安装了MarkdownOutput插件,从而可以在Wiki的页面最后加“?action=markdown”参数来输出对应Wiki页面的Markdown表示。
2008-10-13
发现SimplePhpBlog的防垃圾评论的机制被突破,并且已经被垃圾发送者盯上了。加上已经对SimplePhpBlog简陋的功能不满有一段时间了。干脆把博客程序换成WordPress 2.6。原先的blog.elias.cn和kolias.elias.cn继续维护花费精力会比较大,只好打包收起来了。
SimplePhpBlog向WordPress的转换过程及工具参考博客转换SimplePhpBlog到WordPress。
导入SimplePhpBlog中的上传图片时用了“ update wp_posts set post_content = replace(post_content,’src=images/’,’src=http://www.YOURSITE.cn/YOUR_BLOG/wp-content/uploads/images/’) ”这个sql语句来修改图片路径。但是可恶的WordPress的内嵌媒体管理器总是用绝对路径来进行管理,以后万一调整博客网址,恐怕还得再修改一次。以后博客路径改变时,大概得用类似下面这两个sql语句:
UPDATE wp_posts SET guid = REPLACE(guid,'http://www.elias.cn/blog/wp-content/uploads/','http://blog.elias.cn/wp-content/uploads/');
WordPress中使用的模板和插件设置见关于本站。本来想顺便美化Wiki,但是仍然没有找到合适的模板,只好先不动了。
2008-10-09
安装了SectionEdit插件,来方便长页面的编辑。为正常运行,修改了SectionEdit的css定义,去掉了“clear:both;”,修改对齐方式为“float:right;”,并且注释掉了“if (!CondAuth($pagename
, 'edit'))”这段代码块。
2008-09-23
利用SearchPatterns机制限制默认搜索忽略Site页面组,从而避免了每次搜索都便利大量ActionLog的内容,从而提高搜索速度。
此外,FastSearch这个解决方案也能够极大加速搜索速度和PageList标记的显示速度,但暂时觉得没有必要在本站启用。
2008-09-11
启用了WebsiteIcon,使网站拥有了一个标签栏小图标。在具体制作这个小图标时,参考了Favicon页面的说明,并使用Favicon Generator来转换生成这个ico文件。
2008-07-07
启用了Captcha数字码验证机制来保护页面编辑(防止使用脚本发布垃圾信息)。但有用户名密码并且已登陆的用户不需输入此数字验证码就可以保存页面编辑结果,因此启用了AuthUser基于用户名密码的权限控制。并且通过修改XLPage页面,汉化了Captcha插件输出的反馈信息。
启用了AuthTable来显示全站的页面权限设置情况,并去掉了对部分页面Edit权限的不必要保护。
修改了PmWiki默认模板的CSS文件(pub/skins/pmwiki/pmwiki.css)中的.wikimessage类设置,使PmWiki反馈的提示信息都显示为红色,更为醒目一些。
发现了一个可以在服务器端加密存储页面内容的插件Edit Crypt,不过没有启用也还没有仔细测试。
2008-03-10
部署了DownloadManager组件0.5版本,用于对文件下载项计数。在声明需要进行计数的下载项时,要用标签“ Download:filename.ext ”,显示对应的下载数统计,可使用标签“ DownloadCount:filename.ext”。
2008-02-05
在访问本站Blog的RSS页面时,系统会在Blog根目录下的错误日志文件记录类似“PHP Warning: cannot yet handle MBCS in html_entity_decode()!”这样的错误信息。经查,这是一个php 4.3.2版本的Bug,需要升级php引擎版本才能解决。因此只好将本站所在空间的php5支持打开了,于是错误消失。
2008-01-29
部署了To Do组件,用于记录代办事项等。并调整Elias页面组和XToDoElias页面组的读写权限为“@admin”。
2007-10-27
Wiki被搜索引擎优化者用垃圾信息攻击的问题日益严重,PmWiki可以参考官方提供的解决办法列表
2007-10-10
根据UTF-8、PerGroupCustomizations、Internationalizations中的指点配置了专门的英文页面组(仍然使用UTF-8编码)En,并且修改站点根目录下的.htaccess文件,使小写的en能够被重定向到大写的En页面组首页。
比较新的PmWiki版本允许将一部分站点全局配置放到Site组的页面中完成,从而降低config.php文件的压力,方便管理员修改网站设置。具体信息可以参考Website configuration
2007-10-03
迁移服务器到LunarPages;利用新服务器上的服务,按照CleanUrls启用了搜索引擎友好的站点地址。
由于服务器PHP版本大于4.4.6,因此根据Troubleshooting页面的提示,在config.php文件中添加了
Wiki中所有页面都可以浏览,但是有些页面一保存或者预览就会出现403错误。最后发现是apache的mod_security模块认为提交的请求中有像是攻击脚本的东西,因而不允许PHP继续处理。解决的办法是把“SecFilterEngine off”添加到.htaccess文件中来禁用mod_security(这个问题搞了我差不多3个小时……主要系统给出的提示信息太少了)。这个问题同样是在Troubleshooting找到的解决方法。
在SimplePhpBlog和PmWiki中试着设置了时差参数,调整服务器和中国之间的时差。但是没有成功……
2007-09-16
部署了Footnotes插件,可以用 [^一条脚注信息^] 和 [^#^] 来在页面中书写脚注了。这样一些文中不大重要的内容可以放在脚注中描述,从而避免影响对页面主要内容的阅读。
2007-09-12
本来打算利用SimplePhpBlog的仿WordPress主题美化一下Blog的外观,但是后来还是换回SimplePhpBlog默认的了。但通过修改模版源代码,加大了SimplePhpBlog自带Classic模版的文字字体,从而使页面在Firefox下看起来舒服一些。
2007-03-07
忽然Blog上的上传图片都无法显示,检查后发现是网站空间服务商忽然启用了.htaccess控制机制,造成Blog的图片存储目录无法被浏览器访问到。删了图片存储目录下的.htaccess文件就好了,不过这样可能有安全隐患,也许应该考虑重新编写一个既安全又好用的.htaccess文件。
2006-12-28
安装了ActionLog插件使Wiki系统自行记录全站访问情况,并将日志页面读写权限设置密码保护。
2006-11-16
http://www.giuntoli.com/ 这个站点对“某某某Powered”图标的使用、多语言支持、计数器的使用可以在SourceForge的Wiki站点上参考一下,多语言支持的解决方案参考MultiLanguage(该多语言支持方案目前还不算特别完善……)。
另外Flash这个插件可以在发布用InstantDemo制作的Flash演示教程的时候利用一下。
2006-11-14
SlideShow是基于S5的PmWiki在线幻灯片解决方案,我觉得是一个很有意思的组件,正在考虑安装一下。
2006-11-08
计划整理网站中的页面,标记内容过时而且不打算更新的内容为“不再维护”。
2006-09-03
计划替换页面左上角的Logo以及整理“生活和娱乐”页面的内容分类。
2006-07-31
经测试发现27号的修改造成sphpblog运行很诡异,没法对帖子进行编辑,只能跳转回首页。使用替换法发现对汉化文件的修改有点问题。恢复使用旧版的汉化文件使系统恢复了正常。
2006-07-27
用比较不干净但简单直接的办法解决了用作Blog的simplephpblog 0.4.4版本,通过“联系我”页面发送的邮件会乱码的问题。问题的根源在于该版本的simplephpblog不管当前页面的编码设置,统一使用ISO-8859编码发送电子邮件,针对我网站使用了UTF-8编码的现状,我直接修改了scripts/sb_communicate.php文件的sb_mail函数实现,为其中的邮件标题(subject)和邮件正文设置了UTF-8编码的默认声明标记,这样我的网站上邮件通知的乱码问题算是解决了。
但我觉得更好的做法是应当由simplephpblog到当前使用的多语言设置中查询目前编码,再将邮件内容标记为该编码格式,才是比较好的做法。以上内容我发步到了simplephpblog在SourceForge上的官方Bug汇集论坛中,希望在以后的官方版本中能够完美地解决这个问题。说实话,这次提交问题懒了一下,没有去确认高版本是否存在同样问题,就直接图省事提交了,以后还是应该尽量把工作做细。
后来又修改了contact_cgi.php文件中的第21行左右,将网友填写的联系表单的主题补放在通知邮件的主题部分,以方便邮件阅读和处理;并且修改了目前使用的中文语言包,翻译了'contactsent'字段,以使邮件主题看起来短一些。
2006-04-04
修改了官方网站的 PmWikiZhCn/EditQuickReference ,并在中文页面提示了汉化方法。没有在本站进行汉化,因等待官方网站汉化更新。
2006-03-20
更新主程序到2.1.3,GeSHi到1.0.7.7,Source Block和PageTableOfContents(pagetoc)到2006年3月版本。可能还有部分目录权限没有正确设置。
2005-09-17
昨天帮助pm先生测试了与xlpage-utf-8.php文件相关的内容,最终pm先生完成了不依赖于mbstring的UTF-8模块,加上其他一些更新,形成了2.0.6版本,并进行了发布。不过不知为什么,pm先生在发布说明中没提我帮助进行了测试以及提出部分解决建议的事,或许pm先生觉得我的这部分工作不重要吧,管他呢。
添加了代码显示、垃圾过滤以及自动生成标题目录的组件,逐步学习pmwiki2的新标签中,修改了部分原始页面的写法。省下要修改的页面还有好多,只好随着使用慢慢来了。
2005-09-16
查看了pmwiki与utf-8有关的代码,发现目前只是在处理WikiWord的时候调用了mbstring组件,因此修改xlpage-utf-8.php文件,把2.0.5所带版本中第36行处的变量置为空字符串,先用着。我在邮件列表中说明了这一做法,pm先生说打算处理这个问题,但要求我帮助测试,看来一个彻底的解决方案有盼头了:)
将pmwiki1上的所有页面转换到了pmwiki2.0.5中。
2005-09-03
昨天看到pmwiki放出了2.0正式版,本来开开心心打算升级版本,结果发现pmwiki2.0的utf-8支持脚本用到了mbstring,我的虚拟空间不支持……只好泡汤了。pm先生号称会解决这个问题,但又认为此问题不够紧急,这样也不知道要等到猴年马月了……
2005-07-12
更换了新的域名,删除了原空间所有内容,改为重定向到新域名上的同样内容。固定链接基本修改完毕,但可能有遗漏。
转移到新域名后,发现blog系统的日历功能出现少量乱码,还没有解决。打算使用Xenu软件来检查新域名上的所有内容,排除死链接。另外还得修改大量我的个人主页信息,指向新域名。
2005-07-10
SimplePhpBlog也是用了一段时间了,感觉功能有点简单,不过它的卖点也就是简单易用。我的不满主要在于这个软件有快一年没有实质上的更新了,好在也没发现有什么重大的安全问题;另外的不爽在于默认页面的设计,明显是基于800x600的显示模式设计的,在1024x768下会在两侧留下空白浪费不少空间,其实这个问题可以自己修改页面样式解决,不过偶实在是不想折腾界面这种东西——不擅长啊……
Pivot目前在开发1.3版本,号称最大的改进是完全支持Unicode和i18n,目前还在Alpha阶段,如果完成以后或许会成为一个比较完美的基于文本数据库的Blog程序(当时用Pivot觉得功能以及十分强大了,就是中文支持太糟糕)。问题在于,到时候我是不是要再换回Pivot呢?还是到时候再说吧,Pivot还是有点复杂啊,曾经读过他的代码,完全就不懂,想必维护起来也会有点困难吧。也许不动才是好主意。
2005-02-15
pm先生居然给我误报的bug回帖了,非常感谢他~随后在pmwiki.org上特别仔细地查询,发现了pm先生给出的一个cookbook解决方案,可以过滤ip和文本内容,叫做blocklist.php,试验了一下,这个脚本和sessionauth可以很好地兼容,pmwiki.org即是使用的这种解决方案,而且这个脚本可以完美工作在pmwiki 1.x上,且使用方便。于是我更新了主页,去掉了blockedit,加上了blocklist,因而搞定了与sessionauth和页面权限相关的一些奇怪的bug。另外还顺手在pmwiki.org的blockedit和blocklist页面上补充了一些关于我这次经验信息。
2005-02-12
发现当启用了不同的read和edit密码时,如果使用sessionauth.php认证,那么提交的页面内容会在被保存之前丢失。我已经把这个bug提交到pmiwki.org上了,编号00329。但后来又在本地试验,发现这是一个误报,不存在这个问题……所以打算删除这个页面。。
2005-02-11
发现blockedit.php脚本与sessionauth.php脚本有冲突,而且没有想出一般性的解决办法,因此只好手动用DirtyWork的办法修改了两个脚本的内容和配置方法,却还是不能完全解决问题,也许只好暂时放弃blockedit脚本了。为了抵御垃圾信息,或许只能暂时把这个wiki变成封闭wiki了。。
2005-01-17
启用了blockedit.php 脚本,禁止了部分IP。
2005-01-16
发现总有人破坏Wiki页面,加入无用的链接。因此打算启用黑名单机制。参考资料如下:
- http://www.pmwiki.org/wiki/Cookbook-V1/RestrictingEdits
- http://www.pmwiki.org/wiki/Cookbook-V1/BlackList
2004-10-16
发现PmWiki 1.0.11 内置的phpdiff的主要问题在于把空行也列入比较的范围,而我们平时使用PmWiki常常需要使用空行来分隔两自然段,这样就很容易造成phpdiff输出很难阅读的页面历史。一个临时的解决办法是让phpdiff函数不负责比较空行,这样的办法只是能够让diff函数在大多数情况下正常工作,但仍不能保证diff输出最优结果(要得到最优结果,必须从算法上进行修改,比如phpdiffnm就能得到更好的输出结果,但计算量也大一些)。我已经将这个问题提交到PmWiki的PITS错误追踪系统上了,编号00096。
现在PITS上优先级最高的条目是00028,关于把blog功能集成入PmWiki的计划。看来,我完全不用考虑对CookBook中提到的WikiCalender办法进行测试了,我可以等待PmWiki2提供的blog集成了。
2004-10-15
改为使用phpdiffnm而不是phpdiff引擎,这样产生的历史记录更干净。从算法实现上分析据说这样会慢、占用更多内存,但似乎由于历史记录更干净了,所以diff过程反而可以更顺畅地进行,从而占用更少内存和更少CPU。1.0.11版本的PmWiki集成了内置的phpdiff函数,但是此函数是基于phpdiff engine的diff而不是diffnm,所以仍然存在历史记录不干净的情形,所以在PmWiki进一步更新内置的diff引擎之前还是使用外挂的phpdiffnm。
本来因为1.0.8版本的PmWiki修正了sessionauth.php教本的一个小Bug(但具体是什么Bug不明),想要升级一下我的Wiki的。可是一直以来使用也没发现有什么问题,所以干脆多一事不如少一事,先不折腾了。
更离谱的是:今天发现pm正在开发PmWiki的第二版——一个从头重写的版本,将提供更友好的Mode开发界面以及更容易的标签定制。那么干脆,我所有改动PmWiki的设想都先放一放,等第二版出来再说。特别是把Blog集成进Wiki的想法,也暂时放一放吧。
2004-10-14
考虑把Blog的功能合并进PmWiki里面,CookBook中提供了一个解决办法,网址为:http://www.pmwiki.org/wiki/Cookbook/WikiCalendar 。回头试试。
2004-10-07
改为使用PmWiki管理我的整个个人网站,不再维护html页面了。
修改config.php文件时,当使用记事本保存为UTF-8格式时,有可能会破坏文件开头的“<?php”标签,需要使用ANSI编码打开这个文件,将此文件的首行改写为“<?php”,否则PmWiki运行可能会报错。
2004-09-28
忽然觉得MoinMoin的彩色文本背景框(ColorBlock)不错,适合显示代码,找到了如下链结可能有用:
- http://www.pmwiki.org/wiki/Development/ColorBlock
- http://www.pmwiki.org/wiki/PmWiki/WikiStylesAdmin
- http://eliascn.org/wiki/pmwiki.php?pagename=PmWiki.CustomMarkup
- http://eliascn.org/wiki/pmwiki.php?pagename=PmWiki.WikiStylesAdmin
- http://eliascn.org/wiki/pmwiki.php?pagename=PmWiki.WikiStyleColors
- http://eliascn.org/wiki/pmwiki.php?pagename=PmWiki.WikiStyles
2004-09-06
发现本网页空间的php服务器运行于cgi模式,影响了本wiki程序密码认证部分的正常工作,故启用脚本sessionauth.php,密码部分恢复正常。另外顺道增加了本wiki更改页面属性、文件上传时的默认密码。
这样,我可以在本wiki上上传一些文件了(考虑到我的服务器空间有限,所以上传文件功能不得不用密码限制一下,没法开放给所有的用户了)。
2004-09-03
发现本网页空间禁用了php的popen函数,原来的diff功能不能用了,更改设置为使用 PHPDiffEngine ,diff功能回复正常。
启动了本wiki的上传附件功能,但对上传时的密码验证测试失败。