CMS漂流

大家可以在以下文件中下载，同样，参照这篇文章，看看哪些文件需要被修改。
[完成]Comsenz应用扩展系列之一：Ucenter/Discuz与Joomla深度整合完全解决方案：版本2安装说明（入门新手完全版）
注意:
1.请在安装后修改数据库名/密码为实际数据库名/密码，要改的地方至少四处（在我的文件中密码均为dsfadfa321）：
./configuration.php
./configuration_uc.php
./bbs/config.inc.php,
./ucenter/data/config.inc.php
2.以下几个路径/bbs, /ucenter分别对应论坛和ucenter，ucenter的超管密码为admin, joomla及bbs的超管用户名密码均为admin/admin

kolidon原作于2009年9月24日
1. 模板一致性 此问题并不是指模板风格和CSS一致，虽然这也很重要但是并不困难。Drupal中模板的问题在于因为系统模板的灵活，模板很难集中控制。即，模块中代码未模板化，或模板置于多个目录位置。
习惯以自有框架特别是某一种特定模板方案比如smarty一类，并且对模板进行集中处理的团队，转入Drupal后往往会对此迷惑。
实际上，这个问题是一个技术问题。
实施中解决办法是：制定出团队自己的模板命名，控制规范并不断修订完善。在每个项目中，对模板、自定义模板函数、自定模块中的模板以表格视图进行跟踪。
虽然Drupal系统提供了大量可能的模板化实施可能性，但对此系统了解越多，越能发现最简单的往往是最可靠的：仅使用模块内模板结构+模板目录内统一控制。
2. CCK及Views的使用
我们发现，基本上所有情况下Views殾能满足我们的需求——如果善用其Api文档的话，kolidon所在团队亦在学习如何将更多block也Views化——当然是不是一些其他页面也Panel化就有待考虑了（因为莫须有的性能问题）。
但我们偶尔会需要添加自定义的扩展模块来对其功能进行更改或扩展。
3. 权限问题
我们有时会需要在term页列出所有文章及其teaser但一个常用模块Content Access可能阻止那些无权限的文章出现在此页面，而此模块可能在其他页面会能用到（当然若不使用此模块此处不会用问题但会对项目其他需求造成不便）。
此时我们常做的时完全放开此content type的权限改由自定义模块来控制其全文存取。
4. Input format
输入格式对不同roles的授权也是需要较长时间试验才能获得满意结果的位置。
5. 开源模块质量
开源模块并非拿来就能用，最好看看其是否对性能造带来多大问题：比如某个模块og content admin就可能是一场华丽的性能灾难。
6. Menu及Breadcrumb系统
这个不用说，在任何系统中都是重中之重。若你使用了大量的第三方模块，然后又使用了大量的自定义模块，然后又企盼能将它们无缝组合起来：指的是在外部表现、菜单和Breadcrumb上的完全按业务需求而非模块的目录和自命名结构，那么，多考查几种相关模块，再多花点时间反复试验以便最终熟练吧。
7. 请尊重garland模板
这套模板，实际上，已经帮助我们完成了任何自定义模板工作的80%。所剩的唯有考查是否需要新增area，对原style.css作何种重规划和改进了。但对其整体结构的改变，试过后才会知道，意义不大。
8. locale问题
多语言在任何系统中都会是一个问题，kolidon并不认为Drupal在解决此问题上就已经完美了。
如果你仅仅是需要开发一种特定语言的系统，那么事情不会特别复杂（虽然也会出现一些莫名其妙的问题需要耗费大量时间去调试，比如关闭原生的English时你会发现部分页面会变成blank）。若需要开发多语言而且需要它们能正常切换，那么，诸天神佛保佑，但愿你的团队中有人研究过所有源代码，对这一部分的系统实际有深入了解并随时愿意解决各第三方模块中可能出现的语言问题。
9. Messaging和Notification
这部分也很好玩，如果你花了很多精力玩转了的话，另外，当然Cron不会是一个大问题但同样需要我们保持关注。但是当Messaging、Notification与Locale问题纠缠在一起，特别是不同的用户需要不同的Messaging的时候，我不知道它们是不是仍然让人喜欢。:-)
10. JS问题
如果团队中没有人精通JS，那么至少需要了解Jquery的用法和Drupal的JS框架。上天保佑，这么多Js不会产生冲突。
11. 性能问题
这个实际上如果没有太变态的第三方块的话，不会有什么问题，但若对性能要求较高的话，在登录状态，会需要所有人来贡献智慧以便解决周边的性能问题比如数据库、Gzip压缩、图片大小、背景图片或装饰图片数字，Js性能等等。最后，你会发现，转了一圈，回来了——我们终将面对的是登录状态下的Drupal核心的性能问题。若到了这一步，基本上，团队就开始专业起来了。

kolidon中项目实施过程中发现，Drupal项目应用中有如下问题值得关注：
在中等规模项目中，对核心代码及各开源模块源代码的尊重及版本控制与跟踪。
在华的外企和外包企业，对Drupal开发认识不足，因此常常招聘新手来进行“组装”，这些新手无PHP编程基础（可能拥有其他程序开发经验），无充分项目经验，这可能带来的问题是实施计划与项目进度不可控，代码质量与可靠性不可控，维护计划混乱。
实际上，更大的问题在于，即使稍有经验的Drupal开发人员，亦可能无法形成自己的开发规范/契约。自行开发的模块命名、功能分工、模板等均无法控制。
解决方向：
1. 减少对无PHP编程经验的开发人员的招募。应注意开发过程中的标准化文档的生成（即，所有解决方案均应经过讨论和一致许可并形成可供回顾的标准文档）。
2. 每周一次的集中学习，实施质量评估（点评）必不可少，在此过程中，重点讲述不周密的实施方案可能给后期开发，需求变更及维护带来的影响。
3. 在对人员的培训过程中，尤应注意对Drupal核心源码的集中学习，和对Drupal文化的讨论。
4. 若有可能，组织团队成员协同开发和维护某个开源模块。
kolidon识于2009年8月

在转场了新光天地的地下一层，两间上岛咖啡店，最后跑到24小时的永和大王用我可怜的移动3G上网卡撑了八小时，喝掉上百块人民币的咖啡和豆浆后，我终于成功地将桥接器的测试站点放到了网上。并且，重新整理了所有已经发布的代码，进行了尚算精细的测试。
请点击链接看这篇不断更新中的文章：
http://blog.treeber.com/20090104/500.html
目前我止，QQ上向我问询这个桥接器开发情况的朋友已经很多，但愿这篇文章能让一些不怕麻烦的朋友先跑起来，我仍然在完善它，以便能解决掉目前所有的不完美。
因Ucenter本身似乎不那么完美，很多地方得追进源码才能发现文档的错误，或者，它蛮横地不向其他应用提供新用户注册成功的消息，一个细节是：用户若在DZ一类ucenter应用中注册了，则在Joomla中注册时只能先探测username和email是否在ucenter中存在再给出提示，而不是注册时自动进入joomla系统——虽然已经做到了joomla中成注册完自动进入Ucenter。
估计再用一个小时左右就可以直接将其改成在任何用户在joomla注册时，直接将Ucenter中存在但joomla中不存在的用户同步过来，这样就不用看到丑陋的冲突提示了（见内文中的详细说明），或者，Jianer同学提到的jfusion也可以进入我们的视线——虽然，对jfusion我比较持怀疑态度。
若有开发者愿意合作，我们应该弄几个饭局讨论下如何将其做成组件，如何不用修改核心代码（目前已经有思路了但还得试）。
有点迟，主要是这半年工作有点千头万绪，另外，最近在新单位主要用Drupal。
祝大家顺利。

最近和朋友合作做了dedecms的一项目，颇有感触。 国内有想法的家伙其实是蛮多的。
一套好的CMS，特别是一套要在国内流行的CMS，几个因素非常重要：
1. 规则简单的，可扩展的模板系统，既支持模板单独定义，亦支持模板通用化（首页、频道首页、栏目清单页、文章页、专题页五个即够） 2. 静态页面生成、未生成静态页面时的预览功能 3. 动态建立内容模型(model)，如产品、软件、视频、图片等需要的信息有所不同 4. 其他如多级分类、对文章的不同标记（推荐、加粗、头条、图片、跳转等） 5. 配套的其他功能如广告、会员、图片水印、附件管理、数据库管理等。
我们分两次，每次半天，挂完了一个四屏长的页面加六七个三屏长的频道页，加栏目清单页和文章页。这在以前是无法想像的（JEECMS除外）。
另外，我们还对专题功能加装了一个插件，实以现对专题的各个节点分别列出文章清单。只需要taglib文件夹中放置一个myspecnote.lib.php的文件即可实现myspecnote的新标签。
{dede:myspecnote notei=somenote  }-----[field:arcurl/]------{/dedea:myspecnote}