排列三字谜

帝國、PHPCMS及織夢對比(十二):PHPCMS低級BUG問題分析

2011-10-08 17:35:09來源:chinaz作者:

落葉之前在CHINAZ發布了一系列關于PHPCMS、織夢及帝國這三款CMS對比分析文章,在對比分析中出現過對PHPCMS部分功能和架構設計方式明顯的偏好,一些站長朋友們在評論中多提到落葉在為PHPCMS捉刀的質疑。本文中落葉詳

落葉之前在CHINAZ發布了一系列關于PHPCMS、織夢及帝國這三款CMS對比分析文章,在對比分析中出現過對PHPCMS部分功能和架構設計方式明顯的偏好,一些站長朋友們在評論中多提到落葉在為PHPCMS捉刀的質疑。本文中落葉詳細分析下PHPCMS2008中一直存在的并且在sp4最終版中仍然存在的嚴重甚至低級的問題及一些使用中遇見的“見鬼”的問題。

A、低級問題/BUG:

1.刪除欄目時所有子欄目和子欄目下所有文章不作任何提示,直接刪除。

一般的思路時,如果欄目下有子欄目,或者欄目下已經有多篇文章,刪除時應該提示該欄目不允許刪除,或者至少應該給出危險警告,結果PHPCMS中是一不小心,點刪除欄目,然后彈出的JS中“是否要刪除欄目”點了確定后,就一下子所有子欄目全部干掉了,這也意味著這些所有欄目下的文章也沒辦法顯示了。雖然可以根據PHPCMS中DATA目錄下的欄目緩存中手動在數據庫中找回這些欄目,但這個引起的麻煩自不待言了。

很多新技術員進來時,使用PHPCMS套站時,我都很明確的說明,PHPCMS后臺不允許做任何刪除操作,然而還是常有因為誤點擊而導致幾十個子欄目及欄目因為這樣的誤點擊全部消失的情況。不過,落葉在新站規劃時,一般都會修改PHPCMS欄目刪除對應方法,刪除前先查詢欄目是否有子欄目,然后子欄目是否有文章,如果有需先刪除文章,再刪除子欄目,才能刪除父欄目。

2.移動欄目后欄目關系字段沒能正確更新,刪除原欄目的父欄目,已經移走的子欄目會跟著被全部干掉

落葉不止一次發生過這樣的杯具,原來B欄目是A欄目的子欄目,后來想到B欄目獨立出來做一級欄目更好,于是把B欄目修改為一級欄目,然后更新欄目緩存,修復欄目數據,心想這下應該沒問題了,然后刪掉A欄目,結果大杯具發生了,整個A欄目及B欄目以及B欄目以下的所有欄目跟著被刪除了。

問題出現的原因:PHPCMS無限級分類每個分類中以arrchildid字段記錄了所有子欄目的ID,當把B欄目稱出后,PHPCMS程序中沒能對B欄目的原父欄目的相關字段正常更新,結果刪除A欄目時,遍歷arrchildid中的所有子欄目,括B欄目,一起全部干掉了。

3.添加欄目時緩存重復更新,欄目多后修改欄目保存時慢到不可理解的問題。

PHPCMS在編輯欄目后保存時,會自動調用修復欄目的repair()方法和更新所有欄目緩存的cache()方法,并且repair()方法中本身調用了一次cache()方法,結果導致的問題是每次編輯,欄目緩存都會全部更新兩次,當欄目比較多時,每次都重新生成一次緩存,效率自然會降低,但一般這還不至于導致很明顯的慢。更杯具的是,PHPCMS黃頁模塊的產品分類均存儲在欄目表中,黃頁意味著有大量的多級產品分類,這樣一來,每次在編輯內容模型的某個欄目時,整個欄目表都會跟隨著更新兩次緩存,幾百個欄目的緩存重新更新,并且寫入方式是file_put_contents,結果的杯具是,編輯欄目后保存時一直卡在那里無論怎么點就是更新不動,關掉重新開,發現編輯的內容又是保存成功的。

落葉一直的解決辦法是,修改PHPCMS編輯欄目后調用的緩存更新方法,只讓他更新所涉及到的欄目的緩存。這樣的好處是臨時比較慢,不會花無用的時間去更新大量不需要更新的欄目的緩存。缺點是會導致相關聯的欄目緩存沒有及時更新。不過,這個不是問題,等欄目全部修改完成后,再在后臺點一次更新所有緩存,這下慢就慢吧,點了不管,他自會更新完。

4.刪除文章,靜態頁沒有跟著刪除。

一般的設計按理應該是刪除文章的同時,對應刪除的靜態文件,但不知道為什么PHPCMS中沒有這樣,結果是很多文章已經刪除了,但靜態頁還是被收錄了,并且都是老的一些無用的測試頁面或者模板列換前的頁面。這時候想將這些的頁面去刪除只有人工去找了。

5.內容頁模板無法批量更換的問題。

很多時候,程序上站設置好欄目等,設計美工處理模板界面,然后編輯同時發文章,然而因為模板還沒有做出來,默認欄目設置中內容頁模板都是選擇的默認 show.html模板,發的文章的Template字段中記錄的也是show.html模板,然后設計那邊模板做出來后,如果不用默認的 show.html文件名,而是show_new.html模板時,本來應該可以直接欄目修改時,選擇新模板,然后勾選“將這些修改全部應用到子欄目及內容頁”,實現內容頁模板更換的。相信PHPCMS官方的本意也是如此的,可結果勾了也白勾,內容頁模板原來是啥還是啥,這時候不得不手動一篇文章一篇去修改,或者到數據庫中替換。

6.列表頁GET標簽調用文章列表,分頁鏈接跳到后臺的問題。

這個問題出現的大概原因是GET標簽中的分頁page參數,與列表頁內置獲取的分頁參數產生沖突,生成靜態時參數沖突,分頁出錯。而使用默認TAG標簽時不會有錯。

B、經常遇到的“見鬼”的問題:

1.無論怎么改模板,生成頁面,始終不變的問題

這個是用戶自己的問題,也是PHPCMS的問題。之所以說是用戶自己的問題,那是因為他反復刷新的頁面并不是真這的最新生成的改變后的靜態頁面。之所以說是PHPCMS的問題,那是因為在某些情況下,修改欄目后,欄目URL規則自動在不知情的情況下(修改欄目時,URL規則選項是以TAB選項卡的方式展示,修改其它選項卡下信息時,會難注意URL規則所在的選項卡中的變化而直接保存),變會到默認的URL規則,然后用戶生成頁面后,新頁面生成在默認 URL規則對應的欄目下,而用戶并沒有全站生成,點擊欄目導航訪問時還是舊頁面,所以無論怎么刷新也不變的見鬼的問題。

這個問題當有意去編輯欄目進行測試時,難以復現,但是落葉之前一天多時,經常遇到,最近一些新的技術在處理PHPCMS是經常抓狂的仍然是這個問題。上傳模板,生成靜態,刷新刷新再刷新,就是不變。

另外,還有很多更新后發現不變化的情況均因PHPCMS的緩存所至,無論是編輯系統設置還是修必欄目后都需更新修復欄目數據,更新緩存才能生效,但不知道為什么,很多時候需要重新編輯好幾遍,更新好幾次后才能生效。

再就是URL更新了,更換URL規則后,數據庫中記錄的URL路徑沒有變,需要先更新URL后再生成靜態才有效,但很多由于忘掉而無論怎么生成也沒用的。

2.模板可視化情況下碎片無法點擊添加或修改的問題

這個是程序員或者美工自己的問題,碎片變為可點擊狀態需要頁面調用JQUERY框架,用戶制作的模板如果沒有加截這個框架或者相關頁面沒有加載這個框架,那就出現這個問題。

3.文章提交總是出現phpcms_search' is marked as crashed and should be repaired的問題。

這個問題就是phpcms_search數據表損壞了,落葉此前也是經常碰到了,現在編輯基本每隔一兩天都會碰到這個表損壞而無法添加數據的問題。

這個表是為PHPCMS中實現全文搜索和全文索引而設計的,每添加一篇文章,文章全文內容都會經分詞處理后,存儲到這個表中,寫入操作比較頻繁,但是我不太清楚,為什么這個表會這么容易損壞,頻繁出奇的高。當然見怪不怪時也就淡定了,因為PHPCMS后臺自帶的數據表修復功能還是很強大的。現在編輯在添加文章時發現數據表損壞,已經不找程序員了,直接自己在后臺系統工具里點數據庫修復搞定。

系列相關文章:

 

贊助商鏈接:

排列三字谜