使 WordPress 维护顺利的 10 个技巧
已发表: 2022-03-11作为一名从事过各种类型项目的 WordPress 开发人员，我想讨论一下我在对现有 WordPress 网站进行编辑或错误修复时亲身经历的一些痛点。 本文中列出的提示和建议旨在最大程度地减少甚至摆脱这些痛苦。
为什么正确的 WordPress 维护很重要
大多数时候，网站不是“一次性设置”的事情，所有网站都是如此，而不仅仅是 WordPress 网站。 有时，您将不得不处理您最喜欢的首选开发人员会处理的编辑、更新或错误修复。 但是，在某些情况下，您可能需要在网站的整个生命周期内依赖多个不同的开发人员。
在后一种情况下，对于新来的开发人员来说，事情通常不会顺利进行，特别是如果以前的开发人员在处理他们的维护任务时未能遵守最佳实践。
让我们看看在您未来的 WordPress 项目维护工作中需要考虑的一些更重要的点，这样您就可以让下一个开发人员的生活更轻松，让他们喜欢在您的网站上工作。 显然，让您的开发人员的工作更轻松也必然会在此过程中节省一些工时和金钱，这对于您的潜在客户来说始终是一个很好的卖点。
1. 备份它！
这听起来可能太明显了，但第一件事就是第一！ 您需要定期正确备份您的 WordPress 网站。
即使您目前没有对您的网站进行任何更改，这也是最基本的事情之一。 您可以通过抓取所有文件以及数据库转储并将其存储在安全的地方手动完成，或者您可以使用自动备份选项，由 WordPress 备份插件提供。 您可以在 WordPress 插件存储库中找到大量免费和付费插件。 您还可以在服务器级别充分利用备份选项，因为大多数托管服务提供商都提供备份选项——您需要与托管服务提供商核实。
通过定期备份，您可以放心，您的网站将在崩溃或错误后重新启动并运行。 它还可以帮助您的新开发人员轻松解决问题，尤其是当您尝试修复您怀疑在过去维护期间可能发生的错误时。 定期备份应该可以帮助您的新开发人员识别和解决挥之不去的问题，这些问题发生在他们接管项目之前的几个月或几年。
2. 在本地安装您的 WordPress 网站
我并不自豪地承认我自己在早期就犯了这个错误，从那时起我注意到许多开发人员直接在远程服务器上进行编辑。 除非您担心敏感数据和所有站点文件都受开发人员的支配，否则您应该永远避免这个错误。 每次编辑后在开发者的本地机器和服务器之间来回切换是非常低效的。
即使是微小的更改，例如更改站点上的一些文本的小修改，开发人员也必须导航到 FTP 客户端中的相应文件/文件夹（如果您使用 FTP 进行文件上传），等待要上传的文件，并希望没有偶尔的 FTP 连接失败。 我们不要忘记，一些 WordPress 网站有太多数据无法实际移动，而不会浪费太多时间和带宽。 而且，在成功上传所有内容后，他们必须转到浏览器并刷新页面，这再次取决于当时网络/服务器的速度和状况。 看起来我们只是在谈论每次更改可以节省的时间，但在您的项目过程中，这些时间可能会增加数小时的不必要工作。
如果您的开发人员在他们的本地计算机上安装了站点，则编辑速度会快得多：他们只需要进行编辑，刷新页面，就可以完成。 即使他们住在没有任何互联网连接的洞穴中，他们仍然可以工作并在以后上传他们的更改。
如果您有您担心的敏感数据，或者有一些法律原因阻止您与开发人员共享您的所有数据，该怎么办？ 在这种情况下，您可以为此专门准备一些虚拟数据。 您也可以保留这些数据以备将来维护。
3. 使用 Git
在软件开发领域发生的最好的事情之一就是在线版本控制的曙光。 我提出这一点是因为有很多网站仍在使用传统的 cPanel/FTP 方法来处理文件。 要么他们不知道版本控制有多好，要么他们知道但由于最初的设置工作而犹豫不决。 但是，这实际上并没有那么多工作，而且绝非一项艰巨的任务。
在管理文件时，版本控制带来了许多好处，包括跟踪不同作者的更改、轻松恢复编辑、为每个独立任务拥有单独的分支以确保每个任务的更改不会干扰其他任务。
您必须在外部服务器上设置 Git，大多数情况下您的托管服务提供商已预先安装了该服务器。 您可能需要在服务器方面具有一定专业知识的人来启动存储库并设置工作流，我不打算在这里讨论，因为它超出了本文的范围。
更不用说，如果你不使用分支，你实际上并不是在“git'ing”！ 至少为开发和生产创建两个分支，以便开发人员可以在开发分支上完成所有工作，测试站点，然后如果一切正常，推送到生产分支，确保实时站点上没有任何问题。
4. 删除不需要的文件、代码和插件
留下不再需要的文件和插件是很常见的。 一旦文件在您网站的整个生命周期中随着时间的推移而累积，这就会变得很痛苦。 如果您的开发人员不关心删除随着时间的推移添加的不需要的文件，那么很难追踪它来自哪里以及它当前是否被网站的某些部分使用。 这会导致额外的头痛，因为应该再次测试该站点以确保在移除这些可疑项目后没有任何损坏。
这可以通过相应的开发人员立即删除不需要的文件来消除。 您可以向所有开发人员强调这种做法。
除了 PHP 文件和插件之外，未使用的媒体文件也会随着时间的推移填满您的wp-content文件夹，这可能会给您的开发人员在使用任何与媒体相关的功能时带来麻烦。 您可以找到各种插件来简化此任务。 一个例子是媒体清洁器。
该插件具有内部垃圾箱，可暂时将文件移到那里，以确保文件实际上没有被使用； 检查后，您可以永久丢弃它们。 在清理任何文件之前，请确保遵循本文中的第 1 点（即备份）。
5. 评论
您可能熟悉这样的编程模因：编写代码时，编写它的作者、同事和上帝都理解它。 过了一段时间，只有作者和上帝知道它做了什么，现在只有上帝知道它做了什么——除非作者添加了适当的评论！
一些开发人员在评论时可能不情愿或完全懒惰，但这是在良好的开发环境中必须具备的做法。 它减少了编辑和错误修复的时间，否则新开发人员甚至同一开发人员将花费这些时间来弄清楚特定代码块的作用。
每当函数/类或代码块不明显时，都应添加注释，例如以下函数：
function stripWhiteSapaces(str) { … Return str; }上面的函数名称不言自明，用户也不需要进入函数内部查看它是如何工作的，它只做一项工作，去除空格——就是这样！ 因此，在这种情况下，可能不需要评论。
但是，例如，如果有一个函数接受多个参数并返回过滤后的帖子列表，那么这不像前一个那样明显。 应该有描述参数及其类型的注释。 可能还需要描述此函数内的代码块。
为了快速检查，您可以从 WordPress 核心获取一个文件，看看 WordPress 专家是如何评论它的。 或者，有关更多详细信息，您可以参考 WordPress 的官方指南，该指南很好地说明了这一点。
6. 掉毛
Linting 是另一个很酷的功能，它在我们编写代码的方式上强制执行规则，有时它会纠正代码格式本身，这既酷又有用。 当今使用的大多数 IDE 都带有 linting 选项，您可以通过添加各种 linting 配置来进一步改进或自定义这些选项。
例如，当使用 Visual Studio Code 作为 IDE 时，VS Code 使用官方 PHP linter ( php -l ) 进行 PHP 语言诊断。 您可以分别为每种语言（即 PHP、JavaScript、CSS 等）配置规则/限制。 您可以查看 WordPress 编码标准了解更多详细信息。
- https://make.wordpress.org/core/handbook/best-practices/coding-standards/php/
- https://make.wordpress.org/core/handbook/best-practices/coding-standards/javascript/
一旦有了 linting 配置，就需要强制执行它。 您当前和未来的所有开发人员都需要将此 linting 配置集成到他们的 IDE 中，以便他们的代码也遵守相同的规则/限制。 否则，你的大部分努力都将付诸东流。
7. 变量和文件命名
设计一个处理事物如何命名的标准。 这包括函数/类名、变量名、文件名，甚至媒体/图像名（如果它是模板的一部分），因为它也有助于理解它们的用途。
考虑一些要点：
- 避免使用明确的名称
- 尽可能保持简短
- 有时将“类型”附加到文件名非常有用。 例如，如果它是一个图标，您可以使用 BlackArrowIcon.png 之类的东西，或者如果它是一个大背景图像，它可以是 FrontYellowBG.jpg 之类的东西。 或者，如果它是一个代码文件，有时在 IDE 的不同选项卡中打开多个文件时，很容易知道该文件代表什么。 例如，如果有一个具有辅助函数的类，如果将其命名为 HelperClass.php 而不是 Helper.php，将会很有帮助。
有关更多信息，请查看 WordPress 最佳实践指南中的命名约定部分。
8. WordPress 调试
调试可能会花费大量时间，并且往往会在总开发时间中占据很高的份额，尤其是在编辑或错误修复方面。 这意味着您必须注意您的开发人员是否以最有效的方式进行操作。 大多数开发人员倾向于通过手动var_dump在网页的某些部分中对变量执行此操作，这不是最有效的方法。 这也可能让以后加入项目的开发人员感到头疼，因为如果在工作完成后没有正确清理调试代码，他们最终会到处出现垃圾代码行。
有一些插件可以帮助完成这个调试任务。 以下是一些流行的 WordPress 调试插件示例。
- Kint 调试器
- 调试栏
- 查询监视器
9. 有更好的 CSS
在 Web 开发方面，使用 CSS 进行样式设置是最基本的活动之一。 不幸的是，这意味着它经常被忽视，并且比 JS、PHP 等受到的关注更少。但是，不管你信不信，如果你以后尝试添加或编辑某些东西时，如果架构不正确，CSS 可能会造成巨大的麻烦，除非您的网站是基本的和小型的。
如果您有兴趣进一步了解为什么这种相对基本的样式技术容易出现问题，您可以谷歌一下为什么 CSS 很烦人，或者您可以阅读更多关于 CSS 的 5 件最烦人的事情。
以下是我这边的一些快速提示，没有太多细节：
- 执行良好的命名习惯。 使用像 BEM（块元素修饰符）这样的命名方法
- 避免内联样式。 请改用外部样式表。
- 尽可能尝试提出常见的可重用模式，而不仅仅是在需要时增加样式。
- 根据网站的功能或区域将样式分解为多个文件。 如果你担心更多的样式文件可能会影响加载性能，你可以使用一个很好的缓存插件来克服这个问题，它将多个文件合并到一个文件中。
- 使用 CSS 预处理器，如 SASS、LESS 等。
10. 从当前开发人员那里获得反馈
作为最后的想法，并且为了使列表完整，您可以从开发人员那里获得有关他们在您的网站上工作时遇到的问题的反馈。 他们可能会提供一些很好的建议，因为他们是那些在您的网站上弄脏了手的人。 他们还可能指出以前开发人员留下的错误或脏代码。