落葉之前在CHINAZ發(fā)布了一系列關(guān)于PHPCMS全過程、織夢及帝國這三款CMS對比分析文章，在對比分析中出現(xiàn)過對PHPCMS部分功能和架構(gòu)設(shè)計方式明顯的偏好參與水平，一些站長朋友們在評論中多提到落葉在為PHPCMS捉刀的質(zhì)疑大型。本文中落葉詳細分析下PHPCMS2008中一直存在的并且在sp4最終版中仍然存在的嚴重甚至低級的問題及一些使用中遇見的“見鬼”的問題。

　　A明確相關要求、低級問題/BUG：

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

　　一般的思路時體製，如果欄目下有子欄目構建，或者欄目下已經(jīng)有多篇文章，刪除時應(yīng)該提示該欄目不允許刪除服務延伸，或者至少應(yīng)該給出危險警告共創輝煌，結(jié)果PHPCMS中是一不小心服務機製，點刪除欄目重要平臺，然后彈出的JS中“是否要刪除欄目”點了確定后，就一下子所有子欄目全部干掉了認為，這也意味著這些所有欄目下的文章也沒辦法顯示了實際需求。雖然可以根據(jù)PHPCMS中DATA目錄下的欄目緩存中手動在數(shù)據(jù)庫中找回這些欄目解決方案，但這個引起的麻煩自不待言了。

　　很多新技術(shù)員進來時善謀新篇，使用PHPCMS套站時增產，我都很明確的說明，PHPCMS后臺不允許做任何刪除操作方法，然而還是常有因為誤點擊而導(dǎo)致幾十個子欄目及欄目因為這樣的誤點擊全部消失的情況行動力。不過，落葉在新站規(guī)劃時切實把製度，一般都會修改PHPCMS欄目刪除對應(yīng)方法保供，刪除前先查詢欄目是否有子欄目，然后子欄目是否有文章，如果有需先刪除文章責任，再刪除子欄目應用情況，才能刪除父欄目。

　　2.移動欄目后欄目關(guān)系字段沒能正確更新組建，刪除原欄目的父欄目表現，已經(jīng)移走的子欄目會跟著被全部干掉

　　落葉不止一次發(fā)生過這樣的杯具，原來B欄目是A欄目的子欄目作用，后來想到B欄目獨立出來做一級欄目更好，于是把B欄目修改為一級欄目統籌推進，然后更新欄目緩存方案，修復(fù)欄目數(shù)據(jù)，心想這下應(yīng)該沒問題了帝國cms批量助手了解情況，然后刪掉A欄目深入，結(jié)果大杯具發(fā)生了，整個A欄目及B欄目以及B欄目以下的所有欄目跟著被刪除了重要的。

　　問題出現(xiàn)的原因：PHPCMS無限級分類每個分類中以arrchildid字段記錄了所有子欄目的ID開展研究，當把B欄目稱出后帝國cms批量更新，PHPCMS程序中沒能對B欄目的原父欄目的相關(guān)字段正常更新相互融合，結(jié)果刪除A欄目時首要任務，遍歷arrchildid中的所有子欄目，括B欄目不同需求，一起全部干掉了發展。

　　3.添加欄目時緩存重復(fù)更新，欄目多后修改欄目保存時慢到不可理解的問題總之。

　　PHPCMS在編輯欄目后保存時帝國cms批量添加產(chǎn)品面向，會自動調(diào)用修復(fù)欄目的repair()方法和更新所有欄目緩存的cache()方法，并且repair()方法中本身調(diào)用了一次cache()方法研學體驗，結(jié)果導(dǎo)致的問題是每次編輯建設項目，欄目緩存都會全部更新兩次，當欄目比較多時落實落細，每次都重新生成一次緩存相結合，效率自然會降低，但一般這還不至于導(dǎo)致很明顯的慢製高點項目。更杯具的是更多的合作機會，PHPCMS黃頁模塊的產(chǎn)品分類均存儲在欄目表中，黃頁意味著有大量的多級產(chǎn)品分類認為，這樣一來服務好，每次在編輯內(nèi)容模型的某個欄目時，整個欄目表都會跟隨著更新兩次緩存，幾百個欄目的緩存重新更新共謀發展，并且寫入方式是file_put_contents學習，結(jié)果的杯具是，編輯欄目后保存時一直卡在那里無論怎么點就是更新不動市場開拓，關(guān)掉重新開措施，發(fā)現(xiàn)編輯的內(nèi)容又是保存成功的。

　　落葉一直的解決辦法是要落實好，修改PHPCMS編輯欄目后調(diào)用的緩存更新方法緊密相關，只讓他更新所涉及到的欄目的緩存。這樣的好處是臨時比較慢先進技術，不會花無用的時間去更新大量不需要更新的欄目的緩存培訓。缺點是會導(dǎo)致相關(guān)聯(lián)的欄目緩存沒有及時更新。不過宣講手段，這個不是問題重要工具，等欄目全部修改完成后，再在后臺點一次更新所有緩存配套設備，這下慢就慢吧更優質，點了不管，他自會更新完推進高水平。

　　4.刪除文章脫穎而出，靜態(tài)頁沒有跟著刪除。

　　一般的設(shè)計按理應(yīng)該是刪除文章的同時生產創效，對應(yīng)刪除的靜態(tài)文件廣泛應用，但不知道為什么PHPCMS中沒有這樣，結(jié)果是很多文章已經(jīng)刪除了橫向協同，但靜態(tài)頁還是被收錄了哪些領域，并且都是老的一些無用的測試頁面或者模板列換前的頁面。這時候想將這些的頁面去刪除只有人工去找了不斷創新。

　　5.內(nèi)容頁模板無法批量更換的問題建立和完善。

　　很多時候，程序上站設(shè)置好欄目等參與水平，設(shè)計美工處理模板界面大型，然后編輯同時發(fā)文章，然而因為模板還沒有做出來明確相關要求，默認欄目設(shè)置中內(nèi)容頁模板都是選擇的默認 show.html模板重要意義，發(fā)的文章的Template字段中記錄的也是show.html模板，然后設(shè)計那邊模板做出來后深化涉外，如果不用默認的 show.html文件名體系，而是show_new.html模板時生產製造，本來應(yīng)該可以直接欄目修改時，選擇新模板合理需求，然后勾選“將這些修改全部應(yīng)用到子欄目及內(nèi)容頁”是目前主流，實現(xiàn)內(nèi)容頁模板更換的。相信PHPCMS官方的本意也是如此的高質量，可結(jié)果勾了也白勾充分發揮，內(nèi)容頁模板原來是啥還是啥，這時候不得不手動一篇文章一篇去修改帝國cms批量更新文章管理，或者到數(shù)據(jù)庫中替換設計。

　　6.列表頁GET標簽調(diào)用文章列表，分頁鏈接跳到后臺的問題改進措施。

　　這個問題出現(xiàn)的大概原因是GET標簽中的分頁page參數(shù)就此掀開，與列表頁內(nèi)置獲取的分頁參數(shù)產(chǎn)生沖突，生成靜態(tài)時參數(shù)沖突高產，分頁出錯信息化技術。而使用默認TAG標簽時不會有錯發揮作用。

　　B良好、經(jīng)常遇到的“見鬼”的問題：

　　1.無論怎么改模板，生成頁面銘記囑托，始終不變的問題

　　這個是用戶自己的問題引領，也是PHPCMS的問題。之所以說是用戶自己的問題示範，那是因為他反復(fù)刷新的頁面并不是真這的最新生成的改變后的靜態(tài)頁面應用前景。之所以說是PHPCMS的問題，那是因為在某些情況下運行好，修改欄目后首次，欄目URL規(guī)則自動在不知情的情況下（修改欄目時，URL規(guī)則選項是以TAB選項卡的方式展示部署安排，修改其它選項卡下信息時搖籃，會難注意URL規(guī)則所在的選項卡中的變化而直接保存），變會到默認的URL規(guī)則推廣開來，然后用戶生成頁面后推動，新頁面生成在默認 URL規(guī)則對應(yīng)的欄目下，而用戶并沒有全站生成資源配置，點擊欄目導(dǎo)航訪問時還是舊頁面信息，所以無論怎么刷新也不變的見鬼的問題。

　　這個問題當有意去編輯欄目進行測試時特性，難以復(fù)現(xiàn)傳承，但是落葉之前一天多時，經(jīng)常遇到，最近一些新的技術(shù)在處理PHPCMS是經(jīng)常抓狂的仍然是這個問題形式。上傳模板建設應用，生成靜態(tài)，刷新刷新再刷新日漸深入，就是不變動力。

　　另外，還有很多更新后發(fā)現(xiàn)不變化的情況均因PHPCMS的緩存所至互動式宣講，無論是編輯系統(tǒng)設(shè)置還是修必欄目后都需更新修復(fù)欄目數(shù)據(jù)效高性，更新緩存才能生效，但不知道為什么自動化，很多時候需要重新編輯好幾遍提升，更新好幾次后才能生效。

　　再就是URL更新了不折不扣，更換URL規(guī)則后支撐能力，數(shù)據(jù)庫中記錄的URL路徑?jīng)]有變，需要先更新URL后再生成靜態(tài)才有效高效利用，但很多由于忘掉而無論怎么生成也沒用的特征更加明顯。

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

　　這個是程序員或者美工自己的問題，碎片變?yōu)榭牲c擊狀態(tài)需要頁面調(diào)用JQUERY框架講理論，用戶制作的模板如果沒有加截這個框架或者相關(guān)頁面沒有加載這個框架的可能性，那就出現(xiàn)這個問題。

　　3.文章提交總是出現(xiàn)phpcms_search' is marked as crashed and should be repaired的問題服務為一體。

　　這個問題就是phpcms_search數(shù)據(jù)表損壞了問題，落葉此前也是經(jīng)常碰到了，現(xiàn)在編輯基本每隔一兩天都會碰到這個表損壞而無法添加數(shù)據(jù)的問題全會精神。

　　這個表是為PHPCMS中實現(xiàn)全文搜索和全文索引而設(shè)計的系統穩定性，每添加一篇文章，文章全文內(nèi)容都會經(jīng)分詞處理后集中展示，存儲到這個表中實力增強，寫入操作比較頻繁，但是我不太清楚宣講手段，為什么這個表會這么容易損壞分析，頻繁出奇的高。當然見怪不怪時也就淡定了全面闡釋，因為PHPCMS后臺自帶的數(shù)據(jù)表修復(fù)功能還是很強大的》浅＜ち?，F(xiàn)在編輯在添加文章時發(fā)現(xiàn)數(shù)據(jù)表損壞，已經(jīng)不找程序員了引人註目，直接自己在后臺系統(tǒng)工具里點數(shù)據(jù)庫修復(fù)搞定領域。