任何情況下都不應該直接修改主題或插件源碼,除非只是臨時調試,因為主題插件每更新一次就會還原一次你改過的源文件,迫使你一次次手動恢復修改的代碼。而且不小心改壞要恢復的代價可能是很大的。

如果有選擇,應該避免在子主題通過模板重寫(Override)的方式達到定制目的,原因同樣是主題或插件源代碼越往後更新,你的覆蓋文件與它們間的差距會越來越大,你可能因為要保留定制代碼而在不知不覺中失去新版本源碼提供的新功能或修復。源碼同步與定制需求是魚和熊掌不可兼得,除非站長願意在每次更新後重新在新模板源文件上應用定制代碼,如果真這麼做,恭喜你,一個巨大的維護黑洞產生了。這個問題在諸多WooCommerce專門主題中極為普遍,所以我這兩年已經停止使用這類主題(如知名的Flatsome),初看起來這些主題的專業程度很高,但因為要追求功能的一步到位(Out of the Box)所使用的大量WC原生模板覆蓋所帶來的不一致性風險,從架構和高端站點的穩定性需求來看,是不值得的。

如果開發者足夠自律,那麼現代WordPress開發中使用子主題幾乎毫無意義。一上來就開發自定義插件也未見得是什麼好主意,至少在需求充分迭代成熟之前,開發插件缺乏那種快速迭代時的部署靈活性。

後端所需PHP定制應在Code Snippets或類似插件的支持下,完全依賴WordPress/主題/插件所提供的action和filter達成。前端所需定制應在CJT或類似插件的支持下,用盡可能少侵入性(如結算頁面定制要在WC提供的的update_checked和updated_checkout兩個JS事件基礎上來做)的代碼達到目的。

有些PHP定制的副作用是很隱匿的,越一般的接口越是這樣,所以後台定制要極力選擇盡可能精確的接口。很多官方文檔都有語焉不詳或模棱兩可的地方,開發者和站長除了充分測試大概也沒別的好辦法,這是使用開源軟件的代價。

但是實際情況顯然不是那麼完美的,不是每一個PHP定制都能找到對口的action或filter,不是每個前端定制都存在可用的JS事件或函數接口,這是複雜WP定制開發的挑戰所在。這個時候與其一頭扎進對某個“巧妙Hack”的尋找之中,不如先給主題或插件作者去一封郵件,告訴他們你的定制目標,看他們能否提供解決方案(有時候他們會直接發給你代碼片段),如果對方確認的確無現成代碼可用,那麼大可以提feature request要求他們在下個版本增加定制接口。我個人經歷,一半以上開發者都至少會認真考慮,有三成開發者樂意立刻笑納你提供的免費idea並迅速完成集成。

懶洋洋的開發者自然也是不少的,在感覺到對方和自己溝通缺乏誠意後,不妨試試諮詢第三方專業開發,允許我在這裡自荐一下。

另有些時候,定制整頁全局要比定制頁面中多個局部難度低得多,所以找不到局部定制的辦法事,不如把思路切換一下,看看換個抽象層次會不會更加可行。

在窮盡技術與非技術手段仍無法達成定制目標的(這樣的情況在我碰到過的情況中大概佔5%),我們應該及時理性地與客戶溝通,說明無法有效定制的事實以及強行定制的系統性代價(採用破壞一致性的方法)是犧牲穩定性以及大大增加維護成本。

很多時候達到同一個目的存在多種手段,甚至連目標本身都是可以修正的,另闢蹊徑反而柳暗花明,放棄某些定制是完全正常的選擇,有些技術處理是不值得做的,哪怕客戶自己提的需求,也未見得是深思熟慮的結果,其實絕大多數時候都不是。

定制是WordPress生態給我們的巨大可能性,它首先是一件好事,操作的時候需要一點紀律,這和做別的開發一樣,有個品位的問題。

發現錯別字麻煩選中按Ctrl+Enter

類似帖子

guest
0 Comments
Inline Feedbacks
View all comments