Joomla!新闻

文章來源：CMS漂流 http://blog.treeber.com/

最初是MAMBO，在若干年前——大概是mambo3.5时代，我就迷上了这个开源系统。
曾做过些苦力的工作，比如翻译MAMBO4.4.x的发布公告，比如翻译它的语言文件，但水准仅限于此，因此无法明确判断当时的代码质量。而从知名度为看，这个系统当时即已频繁获奖，用户量巨大。

这个系统最初即为开源，但由私人公司组织开发，公司生存模式与初期的REDHAT比较类似。
原因未知，开发团队中的主力，和所在公司分道扬镳，因着MAMBO本身的GNU/GPL协议，迅速发布完全no-profit的 JOOMLA，其1.0系列基本与MAMBO相同，每一版的代码都在更清晰，其本身的函数质量和结构性亦逐渐提升。这一个系列，基本上是修正bug，但仍然一年内获得了50万注册用户（此项记录原有专门博客记录，但博文因develop.joomla.org的博客功能的重大变更而消失，变更原因同样未知）。因为这些开发者在开发圈内的广泛资源和有效的组织工作，其后一年，全世界用户就只知有joomla而不知有曼波了。
当前，曼波/MAMBO仍然在有效开发及发布，但声势日减（向曼波致敬）。

Joomla的成功，是开源社区的巨大成功（另一个当前正火的Drupal，设计理念上与JOOMLA略有不同，一样优秀，这个往后再总结），是核心开发人员（有待进一步查证）组织能力的成功（印象深刻的是世界各地的joomla日，但cmsnav人在大陆，无缘数月前在台湾的盛会）。

而核心团队＋外围志愿者团队（测试、文档、推广等）＋基于兴趣的扩展制作主体＋商业模板公司＋用户，形成了完整的生态圈（当然，JOOMLA团队专门注册了非赢利社团，接受包括google等商业机构的资助，这包括定期的核心开发人员会议）。

从架构设计理念和开发流程设置看，如下细节值得重视并划出专门篇幅讨论：
1. 高度得视系统的可扩展性，系统中重要概念明确化（组件、菜单、插件/自动化程序、模块、模板），系统流程先处理页面逻辑（组件），加载页面上的模块，套用模板，在此过程中，插件（自动化程序）有几个触发点，用于完成文本替换等系统特定任务（如替换文章中字词，在主体内容后加载评论块，验证登录信息等）；
2. 模板制作简单，与可随意置换和排布的模块，能最简单的实现几乎一切表现层功能，这使商业模板公司积极加入并贡献大量优秀模板（这可能是JOOMLA最具吸引力之处）；
3. 对扩展的高度重视，每一类扩展都有固有的模式并且代码相当简单，方便移置其他系统进入（早期cmsnav.com曾在一些站点使用过joomla的WP插件，效果不错），当然，不少核心开发人员及时撰写示例并带领编写关键扩展——当然，现在joomla1.5的系统重新设计，本质上，它是一个侧重地门户的全功能框架库，因此，不少早期的组件编写者已经完全基于这个库重写了组件代码，组件作者和JOOMLA系统之间的共生关系由此更加紧密；
4. 开发流程上，与正常的开源项目流程类似，SVN使协作管理简化，专门的测试及bugs修订小组、有效的社区经动，让定期的修订版发布成为可能，而核心团队的主要注意力集中于下一个版本的需求分析和实现；
5. 组件和模块在概念上仍然有明确的分离，这到现在仍然是有别于主流CMS的一点，因：drupal和dnn均认为一个功能就是一个组件，而模块显然也被归入了这个概念（DNN中统一叫作“模块”、DRUPAL中统一名为“扩展”），因此，替代的，他们的名词是：模块/扩展、页面、皮肤——当然，大家都有语言文件。这个概念的分离，一定程度上来说，让为不同功能组件开发不同形式的模块变得更清晰更明确（见仁见智吧）。

当前JOOMLA已经从1.0跳空到1.5正式版，优势自不必言，kolidon的treeber.com采用了最初的1.5测试版本并一路升级，发现的主要变化有：
1. 对页面执行流程的定义更为明确（我相当怀疑这个是因为ASP.NET页面生命周期概念的逐渐流行，当然，这个概念的明确才产生了自动化程序的概念），因此，首页index.php的代码量相当少——10余行，对页而执行流程形成如此明确的理念，导致了joomla成了一套可供选择的php开发框架（其中众多功能直接采用开源实现，比如其模板功能性已经和smarty不相上下——采用的是www.php-tools.net提供的pattemplate enginen）
2. 执行效率大大降低:-(装载首页组件，取文章数相同，装载相似模块，确保每模块所消耗SQL查询内容相似前提下，比1.0x慢约1/2（在我的 win2003服务器平台和ubuntu server平台上均如此），据信这主要是由地采用了完全面向对象的框架所致（这个框架代码量巨大，逻辑复杂，为了容错性而相当严谨），当然，全能的 CMS系统比之WP、VBB一类的博客、论坛程序在逻辑上复杂得多；
3. 去除了一些次要概念（如：存档文章）；
4. 缓存粒度更细，可根据模块、页面、组件等分别缓存，实现单对象销毁和重建；
5. 在UI层所选用的Mootools库非常优秀（虽然我更倾向Jquery），预期将能鼓励模板制作者和模块制作者据此实现更丰富的UI层动态效果。
（Mootools的core库若全选，在100K往上，这一点上DNN有专门有UI来管理JS和CSS文件——当然，DNN用的不是Mootools——据信他们已经开始采用微软的AJAX框架）。

使用Joomla1.5过程中遇到的若干问题：
1. 每个页面由不同的itemid（菜单编号）索引，可能的情况是，单元有自己的itemid，而单元下的分类也有自己的itemid，而文章又有不同的 itemid，那么，灵活性可以相当大——joomla根据itemid来决定此页面上要展示的模块和配套模板等，这样，不同的主体内容通过配置不同的 itemid，可以加载不同的外围模块，采用不同的模板，这相当自由——但在很多情况下，这会让人困扰（Drupal，DNN这样的系统并没有创建专用概念：“建立新页面”这个词这个词解决了itemid的问题——然后，让新页面容纳和展示不同的内容和模块组合，尽管原理完全一样，但相对joomla，这两个系统对终端用户更友好一些）；
（备注：有专用的sef插件可以处理itemid不同但内容相同的情况——去除itemid，生成同一页面文件名）

2. 仍然没有提供多级分类、核心缓存功能照例不够强大——系统分步调试和sql查询记录表明，在缓存状态默认首页仍需12次查询，而其中半数查询是可通过将整表复制到本地实现（组件表、菜单表、模块表、插件表、模板表至少耗5次查询），采用joomla的站点，这几个表的数据量应该不会太大——超大型站点即使采用，亦应该是做地次开发；
（专文讨论Joomla效能提升页面缓存组件法＋treeber.com独家法门）

3. 关于UI层，应该是对这一块的管理有所欠缺，竟然没有根据需求加载不同功能代码文件以减少单次传输数量的功能），也没有压缩存放——这是很多优秀的 Joomla模板提供商的一个严重问题，因他们在较早版本的模板中即已开始包含prototype或者jquery或者mootools甚至 highlight，严重时，在某些页面中，可以看到5－10个js文件及3-5个css文件，再加上模块制作者偶尔需要包含自有的脚本及css，这往往导致页面head部分过于雍肿，页面加载速度可能从原定的数百毫秒上升到数秒！！
（blog.treeber.com专文讨论JOOMLA效率提升之HTTP请求优化办法）

4. 这个新的框架可能未经严格的测试，亦未经足够的时间磨砺，尽管经过了严谨的设计，但在某些情况下，会产生令人困扰的回应——treeber.net最新的问题是：后台无法登录且无任何提示，以前的解决方案是重装，网上给出的解决方案显然低估了专业使用者的智力水准，但经两个小时 eclipse+xdebug，问题解决；
（专文讨论）