CMS漂流

我们开发的心得是： 1. joomla1.0从mambo过来，当时算是不错，轻便，扩展丰富； 2. 升级到1.5后，有一套完整的仿java的框架（或者，搞一套完整的语言层级之上的框架是所有程序员的梦想），但这个框架太过庞大，已经失去了php的敏捷开发的天然优势，画虎不成反类犬； 3. 1.5性能奇差（1.5.1时默认首页，经过优化后时间大概在80ms，1.5.10时，已经需要花1000ms甚至更多了）——做了完整的优化，比如eacc等全开等等， 4. 模板系统不直观，1.5有所好转，但实际上事情更复杂了。
优势在： 1. 扩展众多，大概有3000+组件、模块、插件等，虽然大量的扩展代码混乱，但还是有些好东西的； 2. 如果用户仅仅要求一个能自主管理的网站，对色系和风格有点要求，这个最快，但一旦涉及到模板制作就慢了。
我们在其中做了较多的工作，并与目前国内的社群有所接触。
但我们已经逐步放弃以joomla为基础的深层次二次开发——仍然可能做一些模板、组件或者是模块或者直接全部使用既有组件来构建。

这是10月底至11月上旬在公司内部发起的一个系列讨论，有同事觉得这种讨论思路应该有借鉴意义，沟通后公开发布于此。
讨论发起：kolidon
日程计划：2008-11-1日起，每次1.5小时，计划4-5次
第一次讨论：开源 Vs 专有
1. 开源的特质：开源是一种社会运动，发韧于技术人以提升个人技能为初衷而进行的自发交流；非赢利组织如何影响开源；社会的开源心态；
2. 开源对商业机构和非独立程序员的影响：我们如何利用开源软件改善公司产品，程序员如何利用开源技术提升个人技能、构筑个人基本开发框架；
3. 专有系统在PHP平台所遭遇的困境（反编译、非企业化平台——架构算法让位于可扩展性可维护性及时效性），招募开发人员的难题；
4. PHP典型开源软件：PHP扩展（EACC\XCACHE\MEMCACHE…新浪的开源）、框架（ZF\CAKEPHP\SYMFONY…）、CMS系统+框架（JOOMLA\DRUPAL）、基础平台（SMARTY\ADODB\PHPTEMPLATE）、应用软件（相册、留言簿、论坛、博客、维基百科、商城系统）；
5. 一至两种系统的程序框架和执行流程简介（Joomla、Drupal、HDWIKI）。
第二次讨论：程序中的整合和桥接造就了集成开源平台（一至两个案例）
1． 应用程序规模的扩展化需求（bbs- xspace-blog- shop-wiki-/other languages--ucenter）；
2． 结构约定（设计模式），代码约定（编码规范）；
3． 数据层约定（数据库存取类、数据库范式—数据表名及字段名约定）；
4． 功能化约定（共有功能），开源平台中的组件、模块如何受益于单一系统框架；
5． 表现层约定（通用模板类、模板设计方式），ASP.NET中的控件思维到php中的面向对象的代码区块/模块；
6． 介绍两个下载组件（功能齐全，主要做减法和加法，而并非全部做加法）。
第三次讨论：开源系统分析和学习的方法论
1． 快速修改系统；
2． 基于系统发布自有功能产品；
3． 系统调试和性能优化，系统框架再认识；
4． 成为系统专家，参与并影响开源系统发展；
5． 以专业人员眼光挖掘开源系统中的商业机会。
第四/五次讨论：兴趣交流——每人主持介绍任意一种系统（可介绍自有系统）
1． 从框架层面（可从：安全性、可扩展性、框架稳定性）；
2． 从代码层面（可从：可读性、可维护性、代码重用及PHP多版本的兼容性）；
3． 从与当前项目结合的优劣和改进方案层面；
4． 其他可能的内容。

kolidon于 2008年10月
目前常用的WEB应用平台有PHP/ASP.NET(C# and VB.NET)/Java/Perl, Python and Ruby
根据wikipedia.org资料（词条Web_content_management_system）、Google趋势分析、每年举办的全球开源CMS评比及本公司相关专业WEB开发人员反馈，计有如下开源产品受到较多关注：
windows+.NET Framework平台，IIS+ASP.NET（不建议运行于Linux的mono平台）
* DotNetNuke （请参照其官方站点dotnetnuke功能http://www.dotnetnuke.com ）
* mojoPortal
* dotCMS
* Umbraco
windows/linux平台，IIS/APACHE/LIGHTTPD/NGINX + PHP
* Drupal (请参照其官方站及中文站http://drupal.org及http://drupalchina.org )
* Joomla! (请参照http://joomla.org及http://maycode.com及http://www.joomlart.com )
* XOOPS
* ImpressCMS
windows/linux平台，python语言+zope应用服务器
* Plone
我们最终选出Dotnetnuke、Joomla及Drupal用于在不同环境下使用。理由为：这三个应用有足够的成熟度、众多的原生功能/第三方组件与模块支持，较好的可扩展性及普适性。能适用于从小型内容展示站到需求复杂多变的网站群构建，重要的是，这三者在中国大陆地区的普及程度及社区大小均相对强大，这有利于吸引更多爱好者和专业开发人士，使开发工作可以持续延续和深入。
我们并不打算完全重新构造在企业门户站点或网站群中的一些基础的功能应用，例如文章展示、评论、图库系统、用户系统、多媒体展示系统、商城和购物车、论坛、留言和咨询、投票统计与调查、广告、邮件列表、表单、社区功能等等，我们不建议选用Microsoft ASP.NET MVC、及ZEND FRAMEWORK、CakePHP等纯框架产品，因为这与我们快速开发WEB应用及利用既有应用的目标相违背。当然，我们更不建议脱离参照而完全独立设计构造用于企业的门户网站和内容管理系统。
有足够技术实力及相应需求、预算充足的用户，可考虑选用基于python语言的应用服务器zope，或基于IBM WEBSPHERE应用服务器进行JAVA开发，或在Microsoft SHAREPOINT PORTAL SERVER基础上进行开发，前者有较好的社群支持，后两者商业支持足够可靠。
综述，针对企业内联站点及外部门户、网站群的需求，Drupal/Joomla/Dotnetnuke完全能够满足需求，初中高各级程序人员/制作者/设计者，即可按需订制扩展实现功能，快速制作模块、模板，自由实现任何所需效果。
而作为开发框架，其代码复杂程度亦可使普通中、高级程序员得以深入系统核心，由此而借框架之便且能不受限于框架本身，在此基础上开发出完全不同于传统应用的功能如SNS、Web Service应用等。
（请跟踪此链接获得第三方比较报告http://www.digitalartsonline.co.uk/news/index.cfm?NewsID=8854）
基本术语或特性（kolidon制表）

 

Drupal6.x

Joomla1.5.x

dotnetnuke

完成功能

模块

组件

模块

页面外观

模板theme

模板template

模板theme

外观辅助

区域＋容器（包装模块）

位置（包装模块）

区域

节点

节点（文章、博客、书）

 
 

插件或其他辅助

钩子hook（模块相关）

插件plug-in

Provider、component

页面各组成部分

区块，稍弱

组件主体＋模块，强大

模块，稍弱

页面

建页面放置区块和模块

新建菜单，模块菜单对应

建页面，模块与页面对应

扩展安装

手工（FTP上传）

半自动，自动(1.6功能)

半自动（管理界面上传）

缓存系统

有，多级缓存

有，核心开发实现全静态

有，多级缓存

搜索引擎友好

完美

组件，二次开发更完美

完美

数据库

MYSQL，PGSql，可更多

MYSQL，可支持更多

SQLSERVER，可支持更多

开发者友好

好

好

好

用户友好

一般

好

较好

功能比较（kolidon制表）

 

Drupal6.x

Joomla1.5.x

dotnetnuke

权限管理

完善，成员角色分离

完善，前后台均多级

角色系统，成员角色分离

个性化

既有模块

既有组件

未知

群组

既有模块

既有组件

未知

站内信

既有模块

既有组件

未知

其他 SNS功能

组件支持（中）

组件支持（强）

组件支持（？）

应用系统

模块数百种

组件千余种

模块百余种

文章

模块

组件

模块

博客

模块、桥接其他

组件、桥接其他

模块、桥接其他

投票统计

模块

组件

模块

下载

模块

组件

模块

邮件列表

模块

组件

模块

咨询

模块

组件

模块

多媒体

模块

组件

模块

图库

模块

组件

模块

表单

模块

组件

开发

整合其他应用难度

简单

简单

中等

检索系统

检索所有内容

检索所有内容

检索所有内容

网站群

原生支持

安装扩展或简单开发

原生支持

远程控制开发难度

中等

简单，或采既有系统

中等

简评
Drupal:为开发者提供更大自由度和更少依赖。框架简洁但扩展尚算方便，代码完美。目前未见丰富模板；
Joomla:框架优秀，社区支持强。各水平程序员均可参与模块、组件或核心开发。完全释放设计人员灵感；
Dotnetnuke:桥接既有.NET Framework应用方便，模块均为“可用”水准，亦有优秀，功能基本合规。

我们从来没有像今天这样喜欢框架。
我们从来没有像今天这样在每一个应用中使用某个知名JS框架中的至少一部分。
注意，根据需要，合理进行框架核心组件的选择、合并及分割。
以及框架插件的适度引入。

kolidon曾试用过几个据称享有盛名的Joomla Sef组件，如sh404SEF、OpenSEF、Artio Joomsef，当然可行，但链接样式非常怪异且毫无规则（指对中文标题而言），几个组件其他的共同的特点有臃肿、性能以及配置困难等——如一个承载十万数据的FAQ问答系统，若依赖组件至数据表查询，则每次查询耗时相当可观。而此时组件的单一文件缓存所有记录映射又显得如此脆弱——考虑将十万条记录提取到一个数组的情形？
恐怖！
那么，来个另类的——无需增加数据库查询，全靠id识别呢？
如/file会指向下载组件，而/video指向视频组件，而/file_1会指向id为1的文件页面，而/content_323会指向id为323的文章项？
这个主意的结果如下，事实证明，运行良好且对性能无任何损害。
如下给出修改办法（当前只做了几个常用组织如content文章、remository下载、seyret视频、ponygallery图库、search查询的映射，其他组件类同）
httpd.ini转向配置如下（类APACHE url_rewrite语法，在IIS上测试通过，在apache下应基本无需改动）：
########主要功能url缩略
RewriteCond %{HTTP:Host} ^zhonghuayixue.com|www.zhonghuayixue.com$ [NC] #
RewriteRule ^/picture$ /index.php?option=com_ponygallery&Itemid=151 [NC,L] #图片首页
RewriteRule ^/picture_c_([\d]+)$ /index.php?option=com_ponygallery&Itemid=151&func=viewcategory&catid=$1 [NC,L] #分类
RewriteRule ^/picture_c_([\d]+)_([\d]+)$ /index.php?option=com_ponygallery&Itemid=151&func=viewcategory&catid=$1&startpage=$2 [NC,L] #分类-分页
RewriteRule ^/picture_watermark_([\d]+)$ /index.php?option=com_ponygallery&func=watermark&id=$1&Itemid=151 [NC,L] #图片
RewriteRule ^/picture_([\d]+)$ /index.php?option=com_ponygallery&func=detail&id=$1&Itemid=151 [NC,L] #图片
RewriteRule ^/picture_special_(.*)$ /index.php?option=com_ponygallery&Itemid=151&func=special&sorting=$1 #特殊功能
RewriteRule ^/picture_special$ /index.php?option=com_ponygallery&Itemid=151&func=special #特殊功能
RewriteRule ^/picture_userpanel$ /index.php?option=com_ponygallery&Itemid=151&func=userpannel [...]