为什么您不应该使用functions.php(以及您应该做什么)

相信使用 WordPress的人可以分为三大阵营:

1. Plug and players: WordPress的爱好者，他们可能是没有经验的网站设计师，并正在寻找一个统包解决方案。他们将找到一个主题，安装它，并可能继续进行内容创建。
2. Tweakers: 这些人将采取一个主题，可能会直接使用，并应用他们自己的调整。他们可能会使用 custom.css和定制 functions.php文件(或类似的文件)来自定义它们的主题。他们会拿出一个现成的选项，把它弄得乱七八糟，直到他们有了(A)适合他们需要的东西，(B)看上去是独一无二的。
3. Frameworkers: 这些开发人员通常会从一个主题框架开始，这个框架提供的东西很少-你猜不到-一个框架，内容可以放在这个框架上。几个小时或几天后，他们将为他们或他们的客户的≠特定需求定制一些真正独特的东西。

如果我不得不猜的话，我会说三个阵营中最大的一个是调整者。

让我们面对现实: WordPress是一个变色龙的天堂。只需要Google搜索和 functions.php 文件就可以了，WordPress可以轻松地为您的网站添加不同的功能。

唯一的问题是很多调整者都在玩火。使用 functions.php向您的站点添加功能可能是一个意外(由于多种原因)。在本文中，我将解释原因，并为您提供一个更好的选择。

WordPress是如何工作的

WordPress的核心是一个简单的原则：设计和功能应该(只要有可能)清楚地分开。

这就是为什么我们有主题和插件；表面上，主题只负责设计，插件单独负责功能。一个应该能够在不影响功能的情况下切换主题，并且应该能够在不影响设计的情况下禁用插件。

这并不总是可能的(我稍后将讨论的一些原因)，但设计和功能的分离是任何值得他或她的 SALT开发人员都应该追求的理想。

那么，functions.php在哪里适合这一点呢？

functions.php 是一个特定于主题的文件，我的意思是它存在于WordPress主题的目录中，并且只适用于该主题。

正如您可能从名称中猜测的那样，functions.php包含与主题相关的函数，这些函数的示例如下:

• 特色图像的使用
• 节录长度
• 宽化区

这些类型的函数是证明 WordPress的设计/功能分离规则的例外。虽然它们是功能元素，但它们只与其父主题相关，在应用于另一个主题时可能不合适。因此，它们属于 functions.php，应该保留在那里。

例如，一个 200字的节选长度在一个主题上看上去很棒，但在另一个主题上却很糟糕。尽管从技术上讲，我们正在通过调整节选长度(包括 functions.php中的必要代码)来处理站点的“功能”，但这是正确的做法。

在这篇文章中，我不打算深入讨论有效利用 functions.php的复杂性，但值得一提的是，如果您要在站点中包含很多特定于主题的功能，您应该考虑在主题中创建一个 inc目录(如果已经存在，可以使用预先存在的目录)，以便在主题的功能中实现某种组织。以下是WordPress开发者TomMcFarlin关于这个主题的一个很好的读物，如果你想更进一步的话。

我的最终观点是: functions.php is not the enemy. 它是主题引擎中的一个有价值的齿轮；除了最基本的设计之外，对所有的设计都是必要的。

但是，函数PHP的滥用很普遍，应该加以制止。

当您不应该使用functions.php时

对于何时应该使用 functions.php，简单的答案是“几乎从不使用”。

稍微复杂一些的答案是“用你的嗅觉”。

如果您了解 functions.php的作用(与特定主题严格相关的功能)，那么您应该能够弄清楚它不是用来做什么的。

简单的例子可以在 WordPress网站的插件目录中找到。插件是(理想的)逻辑排列的“数据包”的代码，由他们的预期功能分开。

WordPress将功能与设计分离的最佳例子之一是 Google Analytics跟踪代码，它如下所示:为了跟踪访问，需要将此代码添加到站点的头部分。

在添加此代码时，有三个主要选项:

1. 将其手动添加到主题的 Header.php文件中
2. 将它手动添加到 functions.php (使用一个钩子 hook)
3. 使用一个插件

如果你使用一个或两个选项，你的跟踪代码将消失，如果你改变主题，访问者将不再被谷歌计算。(下次更新主题时，它也可能消失。)但是如果你使用第三种选择(我推荐的是 Google Analytics by Yoast)，你就很棒了。除非您有一个高级时刻，并关闭您正在使用的插件，跟踪代码是无路可走。

我的简单建议是：如果有疑问，请使用插件。它们很受欢迎是有原因的。

为什么你不应该用functions.php

在解释上面的“什么时候”时，我也公平地解释了“为什么：”不要使用functions.php，因为更改主题会改变站点的功能，这是各种各样的错误。

但是，我还应该提出几个要点，以进一步加强尽可能避免 functions.php的原因。

首先，有一个可怕的“死亡的白色屏幕”。坦白地说，如果你从来没有在和 WordPress打交道的时候遇到过这种情况，那么你就没有活过。或者说，当你第一次开始修改 WordPress时，你比我要小心得多。

我觉得在这个阶段，我们需要一个截图来澄清这个白色的死亡屏幕到底是什么样子:

很吓人。但这意味着什么？

好吧，用女王的英语来说，当你举起 PHP时，你会遇到死亡的白色屏幕。

换句话说，你搞砸了。

换句话说，插入 functions.php 中的 PHP代码中的语法错误“破坏”了您的站点，导致您只看到一个白屏幕。(不要问我“死亡”是从何而来的。据我所知，没有人受伤。)

当遇到死亡的白色屏幕时，最好是通过 FTP或在线IDE(如 ShiftEdit)来编辑站点，而不是WordPress后端，否则您将很难回到您的站点。另外，你会因为使用WordPress后端而受到我的一记耳光。淘气。

但我离题了。我要讲的重点是：将 PHP代码放入插件可以防止死亡的白色屏幕发生。相反，WordPress可以在不对整个站点的持续运行产生负面影响的情况下，关闭这个令人反感的插件。

其次，如果您计划插入更多的代码，那么使用 functions.php就会非常混乱；特别是如果您使用的主题已经具有现有的功能。

第三，正如我前面已经提到的，functions.php 中的代码是特定于主题的(也就是说，当您更改主题时不会移动)，并且可以被主题更新覆盖。

所有这些都不是好的，而且应该让您相信，在大多数情况下，functions.php并不是您想要放置代码的地方。当然可以；默认情况下保留任何内容(假设主题开发人员只包含特定主题的功能)，但是您添加的任何新代码都可能是公平的。

那你是做什么的呢？

美丽的选择：创建自己的插件

如果你是一个花园品种的 WordPress微调，从来没有创建过你自己的插件，你会原谅认为它涉及某种复杂和神秘的过程。也许需要某种咒语。

幸运的是，事实并非如此。如果您知道如何正确地编辑 functions.php文件(通过FTP或在线IDE)，那么您已经具备了必要的技能，可以为您本来要放入的所有代码创建一个插件 functions.php。

所以我们开始吧。

首先，通过 FTP(或者宿主面板的文件管理器，或者通过在线IDE)导航到 WordPress网站的根文件夹。从那里，您应该导航到 wp-content/plugins:

您在 plugins目录中看到的文件夹(正如您可能想象的那样)是当前安装在站点上的插件。要创建自己的插件，只需创建一个新文件夹。我要给它起个名字 tme-custom-functions:

(“TME”是我的首字母，我将它们放在插件名称的前面，这样我就不会意外地使用现有插件的名称。)

接下来，在插件的文件夹中创建一个名称相同的 PHP文件:

最后，将以下代码插入全新的 PHP文件中:

非那样做不行。确保保存了文件，插件现在将出现在 WordPress插件列表中:

当然，您的插件还没有做任何事情，但是现在您可以随意插入以前驻留在 functions.php文件中的任何自定义函数，它们将继续正常工作。

更进一步：创建一个“必须使用”插件

一般的插件都很好，但是如果你想让你选择的功能在任何情况下都在你的网站上工作呢？如果你不想让你的新的自定义插件把你的插件列表弄得乱七八糟怎么办？

听起来你需要让它成为一个“必须使用”插件，它是在你的网站上总是活跃的插件(不能被禁用)。它们甚至不会出现在 WordPress的插件列表上，除非你点击插件列表中必须使用的链接。

要使插件“必须使用”，只需在 WordPress站点的 wp-Content目录中创建一个名为 mu-plugins 的文件夹，然后将插件的 PHP文件(不是整个文件夹)移动到其中。

嘿预告片！插件将从列表中消失，并在新的“必须使用”部分中重新出现。:

包起来

您现在知道什么时候应该使用 functions.php，什么时候应该创建自己的插件。

您也知道，它几乎总是值得创建您自己的插件有很多原因。现在，你也可以通过创建一些出现在 WordPress后端的东西来感觉自己像一个聪明的 WordPress开发人员！不要假装它不会让你在编码方面感觉比你实际更好(至少，这让我感觉很好)。

如果你对我在这篇文章中讨论过的任何事情有任何疑问或担忧，请在下面的评论部分中发火，我会回复你的！

Photo Credit: skoop.

原文：https://premium.wpmudev.org/blog/why-you-shouldnt-use-functions-php/