之前使用CMS中用最久的是XOOPS...從一開始1.X到2.X都使用過(公司不少的網站也是用他來架)
也使用XOOPS來開發自己的模組,當時自己寫了一個股票的模擬系統
不過也因為當時在1.X時就開發好了...到後來XOOPS改版到2.X有了很大的變動
包括整各模組設計及核心的語法...也因此要移植到2.X讓我很猶豫
因為當初開發那個模擬系統花了3個多月時間...改版到2.X少說也要2個月
所以我認為這樣的大變動對於往後的維護是一個大問題...
只要XOOPS大改版一次之前所開發的模組就得跟著改...
若不改舊的版本可能又會有安全性以及開發團隊不再維護的窘況
後來又因為XOOPS內部分歧,變成總站和日本2個版本,更讓我苦惱不以
因此我開始思考更換別的CMS或是自己全部重新開發...
後來想說自己開發(包含會員系統,權限,討論區加上自己的模擬系統...),不過這樣工程蠻浩大的
雖然優點自己可以全部掌握,但是開發時間少說要拉長到半年以上...
後來因為想找PHP的MVC架構...剛好看上Qcodo,因緣際會看到Qcodo有Drupal的開發模組
於是就上來找Drupal的相關資料,雖然才剛裝起來,不過也發現了不少Drupal的優點
尤其是對開發模組的人員的優點更為明顯,不知道我的了解是否有誤...
核心的Drupal因為有HOOK系統的協助可以讓我開發模組時分享會員權限的函數
可讓我再開發時省去不少時間,不過想請教一個問題...
當DRUPAL再改版時,若因使用HOOK系統分享函數的關係,是否會因為大改版影響舊版本開發的模組...
若會影響至少修改成新版時所花的時間不要太長也還能接受...
不知道是否有大大有這方面的經驗可以分享...
我一開始就使用4.7所以還不知新舊版本間和自己開發的模組影響差異性有多大
老兄~關於您的疑慮
目前我也卡死在這裡,雖然昇級是好事,但是舊的模組也跟著完蛋。
特別是要維護一堆網站的時候,更是頭痛拉~~~
我沒開發過模組,但很多相容於 Drupal 4.6 的模組,在 4.7 就有問題;XOOPS, Joomla... 也好不到那裡去!
經常更新昇級固然是好處,但是背後隱藏的物力、人力與財力等資源的投入也相當可觀。而每一次的蛻變,週期愈來愈短,該如何取捨好呢?
看你的模組牽扯到核
看你的模組牽扯到核心多少,基本上,改版都是痛苦的,沒有改版是輕鬆的事情,那本來就是必要成本。
需要思考的問題是,為什麼要用新版本?沒有其他的替代方案嗎?
至於drupal,4.6到4.7在官方上也引發很多這樣的討論,大致上是這樣:要維持社群的自由度,那就不可能做一個限制說:4.7之後核心都freeze。因為這樣drupal也許只能活三年,但對於眾多的drupal developer來講,那可能是讓drupal趕不上時代的一種作法,也是違背自由精神的做法。
比較有可能的方式是,有一部分的人會不斷針對drupal特定版本開發新的module,另一部份的人可能會對drupal core做改善和應用。這兩個不衝突,但是使用者選擇版本時就要好好考慮自己的用途了。
其實自由軟體的世界,drupal只是一個小小例子而已,以linux而言,哪一個project沒有碰到這種問題?當linux的kernel一升級,很多套件都牽一髮動全身.. 因此許多server並不會用最新版本的linux,相對應的應用軟體便更多。當linux發展到一個階段時,可以發現有實力、好用、有能力維護的套件一定會跟的上腳步,剩下還有很多中斷開發、不重要的套件就終止。這本來就是正常狀態。
所以鼓勵release出自己的module,這樣的好處是,當你沒有力氣去做升級的動作時,搞不好有人有興趣就幫你完成了。而選擇module時,也得瞭解哪些module是有持續維護的,甚至有團隊在幫忙(看CVS log就知道了)。
看來使用CMS都逃不過宿命
也看了看drupal4.6->4.7的版本,即使不用到核心的函數,光templete的改變也要改不少地方,使用CMS的好處當然是為了省時,甚至有些現成的模組比自己開發還來的更好,當然礙於自己開發的模組是商業模組,所以只能靠自己,CMS小改版時也還好,跟著改版的其實也只有自己開發的模組,我比較不怕改版,因為選擇CMS跟著改版的宿命是逃不了的,而是怕向XOOPS或是Joomla一樣出現分歧,XOOPS目前還看不出來哪一派未來比較有優勢,各有支持者,到時選錯邊即使跟著改版怕最後變成孤兒那就慘了...若不是安全問題我想未必是需要跟著新版走,但是大部分改版卻都是因為安全問題連帶著改版居多@@
不過我在Qcodo這個PHP的MVC看到一則,他說明了即使Qcodo未來變更核心,也不會影響到自己所開發的自訂函數
http://twpug.net/modules/newbb/viewtopic.php?topic_id=1740&forum=29&post...
我也想過只要有用到核心函數的部份都分別寫成一個檔案在include到有用到的地方(10個函數就10個檔案),未來碰到核心改版,我大都也只需要修改那10各檔案即可,當然最差狀況可能那個函數已不再使用也不一定...這已是我想到能最小變動的方式
另外我發現drupal在貴站的速度,似乎普普,貴站有開CACHE嗎?當然我是像其他例如像XOOPS來比較...
還是因為drupal的架構的關係所造成的,MYSQL的CACHE和PHP CACHE是否都有設定或加大?
drupal裡面有辦法針對每各模組或區塊作cahce的設定嗎?目前好像內建核心的功能無法針對各各區塊和模組分別設定
Re: 關於Drupal未來更新的問題 - Block Cache
再來補充一下:
Drupal 是有針對區塊快取的模組 - Block Cache
http://drupal.org/project/blockcache