任何情况下都不应该直接修改主题或插件源码，除非只是临时调试，因为主题插件每更新一次就会还原一次你改过的源文件，迫使你一次次手动恢复修改的代码。而且不小心改坏要恢复的代价可能是很大的。
如果有选择，应该避免在子主题通过模板重写（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生态给我们的巨大可能性，它首先是一件好事，操作的时候需要一点纪律，这和做别的开发一样，有个品位的问题。
