您如何组织插件和主题代码？
我开始使用 WordPress 作为 CMS，现在 V3 可以更轻松地管理分类法和自定义帖子类型。我的工作主要集中在开发插件和主题。
我最大的插件做了一些管理工作（添加管理菜单项以及相关页面和功能），但也做了一些导入和导出，并挂钩一些基本的后期处理处理（“创建新帖子时”）。
我最大的主题非常小，它所做的只是以自定义方式显示自定义帖子。
经过几周的工作，我已经有了几千个 LoC，而且挖掘起来越来越难。这引出了以下问题：您如何组织 WP 插件代码？那么你的 WP 主题代码呢？
I starting working with WordPress as a CMS, now that the V3 makes it way easier to manage taxonomies and custom post types. My work is mostly focused on developing plugins and themes.
My biggest plugin does some admin stuff (add admin menu items and the related pages and features), but also does some importing and exporting, and hooks some of the base post processing treatments ("when a new post is created").
My biggest theme is pretty small, and all it does is display custom posts in a custom way.
After a few weeks of work, I have several thousands of LoC, and it's getting harder and harder to dig into it. Which leads me to the following question: How do you organize your WP plugins code? And what about your WP themes code?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这真是史诗般的！我一直发现 WP 的美妙之处在于我可以，正如 jQuery 所说；
您最好将 Pods CMS 与 WP 一起使用来减少代码。
That's pretty epic! I've always found the beauty of WP is that I can, as jQuery put it;
You might be much better off using Pods CMS alongside WP to cut down your code.
这就是我们构建包括主题、第三方插件和自定义代码的客户端部署的方式。
这是一个非常简短的总结，但简而言之，这是我们发现最能防止失败的代码的逻辑划分。
This is how we structure client deployments that include themes, third-party plugins, and custom code.
That is avery brief summary, but in a nutshell that is the logical compartmentalization of code that we've found to be most failure proof.
为什么不将插件按功能拆分成多个文件？主题也是如此。你对此有什么问题吗？
Why not to split plugin into several files by function? The same goes to themes. Any problem you have with that?
基本上有三种方法可以做到这一点： 前缀函数，使用
require_once按功能包含文件，这很常见。另一种被广泛吹捧的“正确”方法是拥有一个包含所有插件代码的巨型类。正如您所说，在保持良好状态的同时，一旦该文件进入数千行代码，您就会陷入可管理性的困境。
我喜欢的方式是来自我的 C# 背景的一种方式 - 有一个主插件类和其他“worker”类（您可以将它们放在命名空间中以保持类名简短）。例如，有一个专门用于管理部分的类（它也可以有自己的小“子类”，例如每个页面一个）。将所有这些代码重构到不同的类和文件中需要一段时间，但这是值得的 - 跟踪所有内容以及让人们在代码库上工作会更容易一起。它还迫使您更多地考虑应用程序如何组合在一起，这有助于更好地编写代码。
我实际上正在写一篇关于此的文章系列，概述了三种不同的方法。您可以在此处查看第一部分。接下来几周还会有另外两个。
希望我有帮助！
There are basically three ways you can do this: prefixed functions, with
require_once's including files by functionality, which is quite common.The other "right" way that's touted a lot is having one giant class with all your plugin code in it. While keeping things nice, as you said, once that file gets into the thousands of lines of code, you're screwed for manageability.
The way I like to do it is a way coming from my C# background - have one main plugin class, and other "worker" classes (you can put them in a namespace to keep classnames short). For example, have a class dedicated to the admin section (it can have its own little "subclasses" too, say one for each page). It'll take a while to refactor all this code into the different classes and files, but it'll be worth it - it'll be much easier to keep track of everything, as well as for example getting people to work on the codebase together. It also forces you to think more of how your application all fits in together, which lends to better thought out code.
I'm actually writing an article series about this, outlining the three different methods. You can take a look at the first instalment here. There are two more coming in the following weeks.
Hope I helped!