blocks|key|757348|text|为什么不把插件按功能分成几个文件呢？主题也是如此。你对此有什么问题吗？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|757349|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Why not to split plugin into several files by function? The same goes to themes. Any problem you have with that?

blocks|key|1503586|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1503587|几千个LoC|blockquote|1503588|1503589|1503590|这真是一部史诗！正如jQuery所说，我总是发现WP的美妙之处在于我能做到；|1503591|1503592|少写，多做！|1503593|1503594|1503595|你最好同时使用Pods+CMS和WP来减少你的代码。|offset|length|1503596|entityMap|0|LINK|mutability|MUTABLE|url|http://podscms.org/^0|0|0|0|0|0|0|0|0|0|7|8|0|0^^$0|@$1|2|3|-4|4|5|6|Y|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|Z|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|10|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|11|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|12|7|@]|8|@]|9|$]]|$1|H|3|-4|4|5|6|13|7|@]|8|@]|9|$]]|$1|I|3|J|4|C|6|14|7|@]|8|@]|9|$]]|$1|K|3|-4|4|5|6|15|7|@]|8|@]|9|$]]|$1|L|3|-4|4|5|6|16|7|@]|8|@]|9|$]]|$1|M|3|N|4|5|6|17|7|@]|8|@$O|18|P|19|1|1A]]|9|$]]|$1|Q|3|-4|4|5|6|1B|7|@]|8|@]|9|$]]]|R|$S|$4|T|U|V|9|$W|X]]]]

<blockquote>
 several thousands of LoC
</blockquote>

That's pretty epic! I've always found the beauty of WP is that I can, as jQuery put it;

<blockquote>
 Write less, do more!
</blockquote>

You might be much better off using <a href="http://podscms.org/" rel="nofollow noreferrer">Pods CMS</a> alongside WP to cut down your code.

blocks|key|1503633|text|这就是我们组织客户端部署的方式，包括主题、第三方插件和自定义代码。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1503634|1503635|wp-content/plugins只包含第三方插件，这里的代码没有被修改，网站不应该因为这些插件被禁用/删除而成为最后期限。|unordered-list-item|1503636|wp-content/themes应该包含与前端表示相关的代码。诀窍是不要用与presentation.|1503637|mu-plugins/不直接相关的代码重载主题(functions.php和其他与主题相关的文件)，其中包含所有特定于实现的业务逻辑。这里的东西永远不应该被禁用，它们是操作所必需的。|1503638|1503639|这是一个非常简短的总结，但简而言之，这是我们发现的最能证明失败的代码的逻辑划分。|1503640|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|P|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|Q|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|R|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|S|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|T|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|U|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|N|$]]

This is how we structure client deployments that include themes, third-party plugins, and custom code. 

<ul>
<li>wp-content/plugins only contains third-party plugins, no code in here is modified, and the site should not be deadlined by any of these plugins being disabled / removed. </li>
<li>wp-content/themes should contain the code related to presentation of the front-end. The trick is not not overload the theme (functions.php and other theme-related files) with code not directly related to presentation.</li>
<li>mu-plugins/ contains all of your implementation-specific business logic. Things in here should never be disabled, and are required for operations. </li>
</ul>

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.

blocks|key|1503664|text|基本上有三种方法可以做到这一点:带前缀的函数，与require_once的包含文件的功能，这是相当常见的。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1503665|另一种经常被吹捧的“正确”方式是让一个巨大的类包含所有的插件代码。在保持良好的同时，正如您所说的，一旦文件进入数千行代码，您就会陷入可管理性的困境。|1503666|我喜欢这样做的方式来自于我的C#背景--有一个主要的插件类，以及其他的"worker“类(你可以将它们放在一个命名空间中以保持类名的简短)。例如，有一个专门用于管理部分的类(它也可以有自己的小“子类”，比如每个页面一个子类)。将所有这些代码重构到不同的类和文件中需要一段时间，但这是值得的-跟踪所有内容会更容易，例如让人们一起工作在代码库上。它还迫使您更多地考虑如何将您的应用程序整合在一起，这有助于更好地思考代码。|1503667|实际上，我正在写一系列关于这方面的文章，概述这三种不同的方法。你可以看看第一批here。在接下来的几周里，还会有两个。|1503668|希望我能帮上忙！|1503669|entityMap|0|LINK|mutability|MUTABLE|url|http://blacktitans.net/organising-wordpress-code-part-1/^0|O|C|0|0|0|13|4|0|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@$9|W|A|X|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Y|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|Z|8|@]|D|@]|E|$]]|$1|J|3|K|5|6|7|10|8|@]|D|@$9|11|A|12|1|13]]|E|$]]|$1|L|3|M|5|6|7|14|8|@]|D|@]|E|$]]|$1|N|3|-4|5|6|7|15|8|@]|D|@]|E|$]]]|O|$P|$5|Q|R|S|E|$T|U]]]]

There are basically three ways you can do this: prefixed functions, with <code>require_once</code>'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 <a href="http://blacktitans.net/organising-wordpress-code-part-1/" rel="nofollow">here</a>. There are two more coming in the following weeks.

Hope I helped!

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?

How do you organize your plugins and themes code?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我开始使用WordPress作为内容管理系统，因为V3使得管理分类法和自定义帖子类型变得更容易。我的工作主要集中在开发插件和主题上。我最大的插件做了一些管理工作(添加管理菜单项和相关的页面和功能)，但也做了一些导入和导出，并挂钩了一些基本的后处理处理(“当一个新的帖子被创建”)。我最大的主题是相当小，它所做的一切都是以...

问你是如何组织你的插件和主题代码的？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问你是如何组织你的插件和主题代码的？EN