wordpress插件_我的功能是否属于WordPress插件或主题？-CSDN博客

wordpress插件

WordPress offers a clear separation between design, content and functionality.

WordPress在设计，内容和功能之间提供了清晰的分隔。

Themes very clearly handle the overall design and layout of a website while plugins offer the ability to add new features to the WordPress installation.

主题非常清楚地处理了网站的总体设计和布局，而插件提供了向WordPress安装添加新功能的功能。

Therefore, the question of whether or not your functionality belongs in a plugin or a theme should get a fairly straightforward answer. In practice, the waters get a bit murky when considering both the flexibility of WordPress as well as the divergent intentions of different web developers.

因此，有关您的功能是否属于插件或主题的问题应该得到一个相当简单的答案。在实践中，考虑到WordPress的灵活性以及不同Web开发人员的不同意图，这会变得有些模糊。

Before we examine these nuances though, let’s first define exactly what we mean by “functionality”.

但是，在检查这些细微差别之前，我们首先要准确定义“功能”的含义。

Defining Functionality

定义功能

The term “functionality” is a common buzzword that gets thrown around pretty loosely these days by developers, designers and clients alike, but exactly what are we talking about when we reference it?

“功能”一词是一个常见的流行语，如今，开发人员，设计人员和客户都非常随意地使用它，但是当我们引用它时，我们到底在谈论什么呢？

For the most part, just about anybody involved would agree it to be a general term describing a specific feature set that has been introduced into a system. In WordPress, almost all types of functionality can be broken down into four primary categories:

在大多数情况下，几乎所有参与其中的人都会同意它是一个通用术语，用于描述已引入系统的特定功能集。在WordPress中，几乎所有类型的功能都可以分为四个主要类别：

Core WordPress functionality
核心WordPress功能
Functionality that enhances existing feature sets within core WordPress
增强核心WordPress中现有功能集的功能
Functionality that introduces entirely new feature sets unavailable within core WordPress (including third party application integration such as Twitter)
引入全新功能集的功能，这些功能集在核心WordPress中不可用(包括第三方应用程序集成，例如Twitter)
Functionality that aids a specific theme in handling variables from a design and layout perspective
从设计和布局角度帮助特定主题处理变量的功能

Whether you are looking to add a real-time feed of Tweets to your sidebar, a jQuery image gallery on your home page, or set up your site to be ranked better in search engines, these four categories should cover just about anything you want to throw at WordPress.

无论您是要向侧边栏添加实时Tweets提要，还是要在首页上添加jQuery图片库，或希望将网站设置为在搜索引擎中排名更高，这四个类别都应该涵盖您想要的任何内容扔在WordPress上。

If we accept that all functionality within WordPress falls within one of these four categories, and if we consider that WordPress provides us a logical location to “house” specific types of operations, we can make some fairly linear projections as to whether a specific piece of functionality belongs within a plugin or within a theme.

如果我们接受WordPress中的所有功能都属于这四个类别之一，并且如果我们认为WordPress为我们提供了“安置”特定类型的操作的逻辑位置，那么我们可以对是否有特定的操作做出一些相当线性的预测。功能属于插件或主题内。

Core WordPress functionality is simply included within WordPress, and should never be directly edited at any time. If you do, bad things can happen to you … think “removing random pieces of your engine just to see what happens”.

WordPress的核心功能仅包含在WordPress中，并且绝对不应在任何时候直接对其进行编辑。如果这样做，您可能会遇到不好的事情……想想“删除引擎的随机零件只是为了看看会发生什么”。

Functionality that either enhances existing WordPress core features or introduces brand new features typically belongs as a plugin so it can be added and removed as necessary.

可以增强现有WordPress核心功能或引入全新功能的功能通常属于插件，因此可以根据需要进行添加和删除。

Likewise, functionality that aids a specific theme belongs within that theme, but it’s useful to note that this is typically scripting that helps display specific pieces of content rather than add or extend functions—in this way, the intent of the scripting is different. It’s more about display logic than it is about site functionality—and that’s probably the most important distinction to make in determining for yourself where to place your site’s custom functionality.

同样， 有助于特定主题的功能也属于该主题，但值得注意的是，这通常是脚本，可帮助显示特定内容而不是添加或扩展功能-这样，脚本的目的是不同的。与其说是网站功能，不如说是显示逻辑，这可能是您自己决定将网站自定义功能放在何处的最重要区别。

Display Logic and Site Functionality

显示逻辑 和站点功能

Much of the gray area involved in addressing the question in our title is due to almost all functionality in WordPress being written in one of two languages—PHP or JavaScript. After all, whether you are creating a custom jQuery script to add a specific behavior to a slideshow or modifying the Loop to add the three most recent posts in the “Featured” category to the front page, you are really working on the site’s functionality, right?

解决标题中的问题所涉及的大部分灰色区域是由于WordPress中几乎所有功能都是使用两种语言之一(PHP或JavaScript)编写的。毕竟，无论您是要创建自定义jQuery脚本以向幻灯片显示添加特定行为，还是要修改Loop以便将“精选”类别中的三个最新帖子添加到首页，您实际上都是在致力于网站的功能，对？

Sort of.

有点。

The truth is that while you are, indeed, working with functional pieces of scripting on your site, you should be able to pretty squarely place any scripting into one of two categories. The script either:

事实是，实际上，当您在站点上使用脚本的功能部分时，您应该能够将所有脚本公平地放置到两个类别之一中。该脚本可以：

Adds to or enhances the actual features of your WordPress site (Site Functionality), or
添加或增强WordPress网站的实际功能(网站功能) ，或
Assists you in displaying that information to your audience (Display Logic).
协助您向观众显示该信息(显示逻辑) 。

We all have a pretty reasonable idea of what site functionality is, but display logic has everything to do with how we actually display useful data within the context of the theme. Common examples of display logic include:

我们都对站点功能是一个非常合理的想法，但是显示逻辑与我们如何在主题上下文中实际显示有用数据有关。显示逻辑的常见示例包括：

Registering sidebars and widgetized areas
注册边栏和窗口小部件区域
Registering new WordPress menus
注册新的WordPress菜单
Custom conditional logic inserted into the Loop
自定义条件逻辑插入循环
Post thumbnail scripting references such as TimThumb
发布缩略图脚本参考，例如TimThumb

Incorporating pre-fabricated site functionality via the plugin system by customizing a theme’s display logic is the most common form of WordPress development performed by the typical WordPress developer.

通过插件系统通过自定义主题的显示逻辑来整合预制站点功能，是典型WordPress开发人员执行的WordPress开发的最常见形式。

Most of us spend our time finding slicker and more effective ways of integrating existing tools we find across the Web to create solutions for our clients.

我们中的大多数人都在花时间寻找更流畅，更有效的方法来集成我们在网络上发现的现有工具，从而为客户创建解决方案。

Often, the difference between good coding practice and poor coding practice lies in recognizing the difference between actual site functionality and display logic, and coding each in the appropriate location.

通常，良好编码实践和较差编码实践之间的区别在于识别实际站点功能和显示逻辑之间的区别，并在适当的位置进行编码。

ABC Real Estate: a Case Study

ABC房地产：案例研究

If this is all as clear as mud so far, let’s see if we can’t clean up the stream a little bit by applying it to a practical example. Suppose we have a new client who is a realtor with ABC Real Estate, and they’d like us to develop a new site built on WordPress with the following special “functionality” requests:

如果到目前为止这一切都像泥一样清澈，让我们看看是否可以通过将其应用到实际示例中来稍微清理一下流。假设我们有一个新客户，他是ABC Real Estate的房地产经纪人，他们希望我们开发一个基于WordPress的新站点，并具有以下特殊的“功能”要求：

Because they’ll be running regular seminars, the client would like some form of an event management system
由于他们将定期举办研讨会，因此客户希望使用某种形式的事件管理系统
The client would like to make sure that each of their properties is displayed in a constant, intuitive way that leaves room for multiple photos—the number will vary per house listing
客户希望确保以恒定，直观的方式显示其每个属性，从而为多张照片留出空间-每个房屋列表的数量将有所不同
The client would like to show six featured properties that they select on the home page in a specific format
客户希望以特定格式显示在主页上选择的六个特色属性
The client would like Facebook comments integrated into their site so that visitors can easily share potential homes with their friends
客户希望将Facebook评论整合到他们的网站中，以便访问者可以轻松地与朋友分享潜在的房屋

Each of these requests seems more than reasonable and intuitive for a real estate website, but let’s sort out exactly where we’d add each piece of functionality listed above.

对于房地产网站，这些请求中的每一个似乎都超出了合理和直观的范围，但是让我们精确地确定在上面添加每个功能的位置。

1) Because they’ll be running regular seminars, the client would like some form of an event management system

1)因为他们将定期举办研讨会，所以客户需要某种形式的事件管理系统

This one is pretty simple. Because WordPress doesn’t contain an event management system in its core, we’ll need to add one via the plugin system. Could we write our own and add it directly to the theme itself? Technically, sure—but it wouldn’t make a lot of sense because there are already so many event management systems available that we can try in a heartbeat.

这很简单。由于WordPress的核心不包含事件管理系统，因此我们需要通过插件系统添加一个。我们可以自己编写并将其直接添加到主题本身吗？从技术上讲，当然可以，但是这没有多大意义，因为已经有太多的事件管理系统可供使用，我们可以心动地尝试。

Further, if we were absolutely bent on writing our own system, it’d be easiest to contain all of the files necessary for the system in their own place to keep things tidy … sounds like a plugin to me.

此外，如果我们绝对想编写自己的系统，那么最简单的方法是在自己的位置包含系统所需的所有文件，以使事情保持整洁……听起来像是我的插件。

2) The client would like to make sure that each of their properties are displayed in a constant, intuitive way which leaves room for multiple photos—the number will vary per house listing

2)客户希望确保以稳定，直观的方式显示其每个属性，从而为多张照片留出空间-每个房屋列表的数量将有所不同

This one is a touch more complex, and a bit of a trick question. Since we are talking about how things are displayed, you might think we’re immediately in the realm of display logic. However, WordPress 3.0 introduced the notion of post types which allows developers to create a specific display format for a specific type of post.

这有点复杂，有点棘手。由于我们正在谈论事物的显示方式，因此您可能会认为我们正处于显示逻辑领域。但是，WordPress 3.0引入了帖子类型的概念，该概念允许开发人员为特定类型的帖子创建特定的显示格式。

You can collect a discrete set of data within the WordPress Admin for each record within the post type, and then output that record to a post template inside the theme which allows the post to be output to the screen in a specific, unique way.

您可以在WordPress管理员中为帖子类型中的每个记录收集一组离散数据，然后将该记录输出到主题内的帖子模板中，以使帖子可以特定，独特的方式输出到屏幕上。

Because of the unique way that post types operate, when you work with them you are essentially forced to create both display logic as well as site functionality. We’ll go over this in a bit more detail further on in this article.

由于帖子类型具有独特的操作方式，因此当您使用它们时，实际上必须创建显示逻辑以及站点功能。我们将在本文中进一步详细介绍这一点。

3) The client would like to show six featured properties that they select on the home page in a specific format

3)客户希望以特定格式显示在首页上选择的六个特色属性

This is display logic. We’re adding nothing new here at all, but rather picking specific pieces of stored content from the database. This is always done directly within the theme.

这是显示逻辑。我们在这里没有添加任何新内容，而是从数据库中选择特定的存储内容。这总是直接在主题内完成。

4) The client would like Facebook comments integrated into their site so that visitors can easily share potential homes with their friends

4)客户希望将Facebook评论整合到他们的网站中，以便访问者可以轻松地与朋友分享潜在的房屋

Third party application integration—in this case, it’s Facebook. Piece of cake … we’ll add one of the litany of Facebook commenting plugins available for WordPress and integrate it appropriately. Plugin, all the way.

第三方应用程序集成-在这种情况下，它是Facebook。小菜一碟…我们将添加一系列可用于WordPress的Facebook评论插件，并将其适当集成。插件，一直。

“Great, so I understand how WordPress would prefer me to add my site functionality, but I have my own way of doing things that really works for me.”

“太好了，所以我了解WordPress希望我添加我的网站功能，但是我有自己的做事方式，这些事对我来说真的很有效。”

To that I say, “I completely understand where you are coming from, but allow me to make a few (hopefully) compelling points that just might change your mind”.

我要说的是： “我完全了解您的来历，但请允许我提出一些(希望)令人信服的观点，这些观点可能会改变您的想法” 。

First of all, if you are developing site functionality yourself, you’ll likely find it much more useful to do so within the context of a plugin than directly within the theme for purposes of portability.

首先，如果您自己开发站点功能，则可能会发现在插件上下文中进行此操作比为可移植性而直接在主题中进行更为有用。

After all, even after a specific job has been completed and the site launched, a large percentage of developers retain intellectual property rights to programs that they develop and utilize within sites they work on, and sooner or later there is a necessity to reuse the same code (or a version of it) for another project. Plugins make this site functionality portable and easy to install, saving quite a bit of time in the long run.

毕竟，即使在完成一项特定的工作并启动了网站之后，仍有很大一部分开发人员保留了在其工作的网站内开发和使用的程序的知识产权，并且迟早有必要重新使用该程序另一个项目的代码(或其版本)。插件使此站点功能可移植且易于安装，从长远来看可以节省大量时间。

Because WordPress plugins are structured to maintain all of their files in separate directories away from other plugins and core WordPress features, they inherently provide an instant modicum of order to the functions written throughout the site.

由于WordPress插件的结构是将其所有文件保存在与其他插件和WordPress核心功能不同的单独目录中，因此它们固有地为整个站点编写的功能提供了即时的顺序排列。

For instance, if you are having an issue with the meta description on the home page and you know you are using an SEO plugin that handles that specific function (easily looked up by referencing the active plugin listing in the WordPress Admin), you’ll know exactly where you need to begin investigating the source of the issue, even if you were not the original developer that put the site together.

例如，如果您在主页上的元描述上遇到问题，并且知道您正在使用处理该特定功能的SEO插件(通过引用WordPress Admin中的活动插件列表可以轻松地进行查找)，即使您不是将站点整合在一起的原始开发人员，也要确切知道您需要在哪里开始调查问题的来源。

In this way, plugins can actually provide a loose form of documentation in and of themselves, giving developers reasonable clues as to where certain functions might live in even the most poorly documented sites.

通过这种方式，插件实际上可以自己提供一种松散的文档形式，从而为开发人员提供合理的线索，即使在文档最差的站点中某些功能也可能存在。

Troubleshooting is another fabulous reason to maintain site functionality within plugins rather than embed it directly into the theme. Adding new features to a WordPress site can occasionally cause conflicts and “break” a website, causing any number of display or performance issues that need to be corrected.

故障排除是在插件中维护站点功能而不是将其直接嵌入主题的另一个绝佳原因。向WordPress网站添加新功能有时可能会导致冲突并“破坏”网站，从而导致许多显示或性能问题需要纠正。

When these types of things go bump in the night, the first line of defense most seasoned developers leap to is to begin an examination of existing plugins to see where scripting may be happening. Using WordPress’s plugin system to activate and deactivate plugins provides a handy way to eliminate active scripts running on the site and bring them back one by one to determine which are the offending scripts.

当这些事情在夜晚发生时，大多数经验丰富的开发人员都会跳入第一道防线，即开始对现有插件进行检查，以查看可能在哪里进行脚本编写。使用WordPress的插件系统来激活和停用插件，提供了一种便捷的方法来消除站点上正在运行的活动脚本，并将它们逐一带回，以确定哪些是有问题的脚本。

Without the ability to turn plugins on and off, a developer can be stuck stumbling around in the dark trying to sort out exactly which scripts are conflicting with one another and causing a buggy result to the end user.

如果没有打开和关闭插件的能力，开发人员可能会陷入困境，试图准确地找出哪些脚本相互冲突，并给最终用户带来错误。

Finally, don’t underestimate the importance of flexibility in your website functionality. The more of the site’s core functionality that is directly built into the theme, the more difficult it becomes to make design changes to that theme, or even swap out entirely. It may sound clichéd, but the Web is constantly shifting and changing, and ultimately so is your website—probably faster than you might think.

最后，请不要低估灵活性对网站功能的重要性。直接在主题中构建的网站核心功能越多，对主题进行设计更改甚至完全替换的难度就越大。听起来有些陈词滥调，但是Web一直在不断变化和变化，最终您的网站也是如此-可能比您想象的要快。

Hard coding site functionality into a theme can lead to time consuming edits, changes and overhauls in the long term (and often the short term as well) as you realize that something you thought was so absolutely crucial yesterday that you based your entire site development upon it becomes entirely obsolete next week.

将网站功能硬编码为主题可能会导致长期(有时甚至是短期)的编辑，更改和检修工作很耗时，因为您意识到昨天您认为某些事情至关重要，因此您将整个网站开发都作为基础下周它将完全过时。

Believe me, it’s happened to the best of us.

相信我，这是我们中最好的一次。

Breaking the Rules

打破规则

“Alright …” I hear you say. “That’s all well and good, but I have a good reason to deviate …”

“好吧……”我听到你说。 “一切都很好，但是我有充分的理由偏离……”

Every subjective argument like this has situations that bear solid reasoning to go your own way, and I think it’s useful to point a few out here as well.

像这样的每一个主观论点都具有可以按照自己的方式行事的可靠理由，我认为在这里指出一些观点也是有用的。

Reason #1: Post Types

原因1：帖子类型

In our case study, we discussed putting together a customized post type to handle the display format for a property listing. Pragmatically, this involves putting two pieces of code together: 1) an array initializing the data for the post type, and 2) the post template to handle the visual display within the context of the theme.

在我们的案例研究中，我们讨论了将自定义帖子类型放在一起以处理属性列表的显示格式。在实用上，这涉及将两段代码放在一起：1)一个数组，用于初始化帖子类型的数据，以及2)帖子模板，以处理主题上下文中的视觉显示。

While the second component here is clearly an issue of display logic, the array initializations are a bit more fuzzy. This function is commonly defined within the theme’s functions.php file, but it’s important to note that it could be defined with a functions file initialized within the plugin system.

虽然这里的第二个组件显然是显示逻辑的问题，但是数组初始化有点模糊。该函数通常在主题的functions.php文件中定义，但要注意的是，可以使用在插件系统中初始化的函数文件来定义该函数。

In many ways, this makes a touch more sense as it keeps a clean separation between site functionality and design components, but as of this writing initializing the array within the theme’s functions.php file is the clearly the most common practice. It is certainly a gray area.

在许多方面，这使站点功能和设计组件之间保持清晰的分隔更加有意义，但是在撰写本文时，在主题的functions.php文件中初始化数组显然是最常见的做法。这肯定是一个灰色区域。

Reason #2: Specialized Page Templates

原因＃2：专门页面模板

Occasionally, it becomes important to create a special page on a WordPress site that simply performs a specific function. Perhaps you are iframing something from another site, or pulling in some type of custom functionality that isn’t particularly conducive to working within the constructs of the standard WordPress page template and content editor.

有时，在WordPress网站上创建仅执行特定功能的特殊页面变得很重要。也许您是从另一个站点中整理东西，或者引入某种类型的自定义功能，这些功能特别不利于在标准WordPress页面模板和内容编辑器的结构中工作。

When this is the case, a common practice is to register a new page template with the standard WordPress syntax in the template file, and then include the functionality directly within that particular page. In this instance, the functionality is not portable to other sites at all, but often it is done in a situation where that is not necessary.

在这种情况下，通常的做法是在模板文件中使用标准WordPress语法注册新页面模板，然后将功能直接包含在该特定页面中。在这种情况下，该功能根本无法移植到其他站点，但是通常是在不必要的情况下完成的。

Reason #3: Protecting the Client from Themselves

原因3：保护客户免受自身侵害

As much as we’d all like to believe that WordPress is a bulletproof system that clients are unable to break, we all know that isn’t wholly accurate. Occasionally, there is a very good reason to hard code something.

我们都想相信WordPress是客户无法破解的防弹系统，我们都知道这并不完全准确。有时，很有必要对某些内容进行硬编码。

Let’s say you have a client who needs to edit the sidebar on his or her website, but continually adds to or edits the wrong item. In this instance, it can be useful to hard code simple elements into the sidebar that you are reasonably sure the clients themselves will never need to update on their own, guarding against the possibility that they might accidentally delete it.

假设您有一位客户需要在其网站上编辑侧栏，但不断添加或编辑错误的项目。在这种情况下，将简单的元素硬编码到侧栏中是很有用的，因为您可以合理地确定客户端本身将永远不需要自己进行更新，以防止它们可能会意外删除它。

Examples of things that might be hard coded could include an email opt-in box, or perhaps social media connection buttons.

可能被硬编码的示例可能包括电子邮件选择框或社交媒体连接按钮。

Reason #4: Developing a Specialized Product for a Specific Industry

理由4：为特定行业开发专门产品

There are many theme developers out there who build targeted WordPress themes tailored to specific industries. These themes lack a certain amount of flexibility, but the upshot is that for the target market they serve additional flexibility is unnecessary. Examples of this include real estate specific themes, product review themes, or question-and-answer aggregation themes.

那里有许多主题开发人员，他们针对特定行业构建有针对性的WordPress主题。这些主题缺乏一定程度的灵活性，但结果是对于目标市场而言，它们提供了额外的灵活性是不必要的。这样的示例包括房地产特定主题，产品评论主题或问答集合主题。

Reason #5: Time and Budget Considerations

原因5：时间和预算注意事项

It’s sometimes faster to code something directly into a theme than it is to make it modular and use a plugin as defined as best practice. When time is a factor or your client has a tight budget you need to adhere to, an argument can be made that a legitimate reason exists to cut corners and code site functionality directly into the theme.

有时，直接将某些内容编码到主题中要比将其模块化并使用定义为最佳实践的插件要快。如果时间是一个因素，或者您的客户预算有限，那么您就可以提出一个合理的理由，那就是偷工减料并将站点功能直接编码到主题中。

It’s important to note that this is certainly not best practice, but it is a reason to do what you need to do to get the job done.

重要的是要注意，这当然不是最佳实践，但这是做您需要做的事情以完成工作的原因。

What’s the Bottom Line?

底线是什么？

The question of where to house your site’s functionality is like just about anything else … there is a straightforward answer based on fairly finite rules, but you can always come up with the justification to go your own way if needed.

将网站的功能放置在何处的问题几乎与其他任何问题一样……基于相当有限的规则，有一个直接的答案，但是您总是可以根据需要提出自己的理由。

Best practice is to determine which functionality is best described as display logic and which functionality is best described as overall site functionality, with display logic being added directly to the theme and site functionality being enveloped within the plugin system.

最佳实践是确定将哪个功能最好地描述为显示逻辑 ，将哪个功能最好地描述为整体站点功能 ，将显示逻辑直接添加到主题中，并将站点功能封装在插件系统中。

Is this reflected in the way you work?

这是否反映在您的工作方式中？