WordPress中缠结的自定义数据世界

by Kamil Grzegorczyk

通过卡米尔(Kamil Grzegorczyk)

WordPress中缠结的自定义数据世界 (The Tangled World of Custom Data in WordPress)

降低风险并管理您的自定义字段 (Reducing Risk and Managing Your Custom Fields)

Have you ever wondered how to properly name keys of WordPress custom fields? Does it make any difference? Should you care? What are the potential risks?

您是否曾经想过如何正确命名WordPress自定义字段的键？ 有什么区别吗？ 你应该在乎吗？ 潜在的风险是什么？

Recently I wrote a tutorial about filtering WordPress admin views. In the code, I named custom fields key like kg_order_items. You could ask why? Why not name it just items? Well… read below!

最近，我写了一篇有关过滤WordPress管理员视图的教程。 在代码中，我将自定义字段键命名为kg_order_items 。 你可以问为什么？ 为什么不将其仅命名为items ？ 好吧...阅读下面！

If you try to google for naming custom fields there is not so much information about it. Even the Codex entry tells nothing about naming the field keys in a proper way. I found only one resource at ACF forums that contains proper information.

如果您尝试用Google命名自定义字段，那么关于它的信息就不多了。 即使是Codex条目也无法说明以正确方式命名字段关键字的任何信息。 我在ACF论坛上仅找到包含适当信息的资源。

If there is no problem, what is the fuss about? You could ask.

如果没有问题，那么大惊小怪？ 你可以问。

The days when WordPress was a simple CMS supporting small blog websites with only posts and pages are gone. Today even the smallest website uses a plethora of plugins and complex themes. And all of them bring new custom fields into the game.

WordPress是一个仅支持帖子和页面的小型博客网站的简单CMS时代已经一去不复返了。 如今，即使是最小的网站也使用了大量的插件和复杂的主题。 所有这些都为游戏带来了新的自定义字段。

The situation gets even worse if you use any of the fancy “premium” themes. Unfortunately, many of these are not well written and combine 1001 functions in one. Final result? Slow, not performant, and tangled site which looks nice only on demo content and stock images. And they add a lot of custom fields too.

如果使用任何花哨的“高级”主题，情况就更糟了。 不幸的是，其中许多方法编写得不好，无法将1001函数合而为一。 最后结果？ 速度慢，性能低下且杂乱无章的站点，仅在演示内容和库存图像上看起来不错。 他们也添加了很多自定义字段。

危险！ (Danger!)

WordPress wp_postmeta table is very simple. It is a key-value pair attached to particular post_id. It means that all custom fields keys share a common namespace. That is especially true for the particular ID of the post.

WordPress wp_postmeta表非常简单。 它是附加到特定post_id的键值对。 这意味着所有自定义字段键都共享一个公共名称空间 。 对于帖子的特定ID尤其如此。

First examplea) Imagine that your post has a “learn more” link. After you click the link it redirects you to a particular URL. The address is provided in a custom field. Let’s name the field key as redirect_to.

第一个示例 a)想象您的帖子具有“了解更多”链接。 单击链接后，它会将您重定向到特定的URL。 该地址在自定义字段中提供。 让我们将字段键命名为redirect_to 。

b) Now imagine that you install a plugin called for example “Redirect me, Honey”. The plugin is very, very simple. When the user enters the page it immediately redirects the user based on custom field setting attached to a post. Oh… and its field key is named redirect_to as well.

b)现在，假设您安装了一个名为“ Redirect me，Honey”的插件。 该插件非常非常简单。 当用户进入页面时，它会根据帖子所附的自定义字段设置立即重定向用户。 哦，它的字段键也被命名为redirect_to 。

Result? After you activate the plugin, all of your posts with “learn more” button are redirecting users out of your website. And the reason why is not obvious at the first sight. It may even be unnoticed for quite a while.

结果？ 激活插件后，所有带有“了解更多”按钮的帖子都将用户重定向到您的网站之外。 乍一看原因并不明显。 甚至有一段时间可能没有引起注意。

This scenario is, of course, made up but the dangers are real. With thousands of plugins and thousands of themes available it’s just a matter of time to encounter such name collision.

这种情况当然可以弥补，但是危险是真实的。 拥有成千上万的插件和数千个主题，遇到这种名称冲突只是时间问题。

Second exampleWordPress can store multiple values for the same key name and post ID. (Unless you provide special parameter called $unique).

第二个示例 WordPress可以为相同的键名和帖子ID存储多个值。 (除非您提供称为$unique特殊参数)。

It means that if you save your data 5 times under the key location you will receive an array consisting of 5 elements when calling get_post_meta().

这意味着，如果将数据保存在键location下5次，则在调用get_post_meta().时将收到一个包含5个元素的数组get_post_meta().

Let’s assume that you have a post about the cities you have visited. You have been to 5 cities and those locations are shown on the embedded map in the post. Simple, right?

假设您有关于所访问城市的帖子。 您去过5个城市，这些位置显示在文章的嵌入式地图中。 简单吧？

Attention! Not useful code ahead. ;) !

注意！ 前面没有有用的代码。 ;)！

//NYadd_post_meta($post_id, 'location', '40.7127753, 73.989308');

//LAadd_post_meta($post_id, 'location', '34.0522342, -118.2436849');

//Parisadd_post_meta($post_id, 'location', '48.856614, 2.3522219000000177');

//Viennaadd_post_meta($post_id, 'location', '48.2081743, 16.37381890000006');

//Romeadd_post_meta($post_id, 'location', '41.90278349999999, 12.496365500000024');

//Lets check what we have herevar_dump(get_post_meta($post_id, 'location');

array (size=5)0 => string '40.7127753, 73.989308' (length=21)1 => string '34.0522342, -118.2436849' (length=24)2 => string '48.856614, 2.3522219000000177' (length=29)3 => string '48.2081743,16.37381890000006' (length=28)4 => string '41.90278349999999,12.496365500000024' (length=36)

What if after a while you use a new theme or plugin. It has a feature which can set the position of a post on a front page. You can pick between slider, sidebar or featured posts etc. This scenario may end up like this:

如果一段时间后使用新主题或插件怎么办。 它具有可以设置帖子在首页上的位置的功能。 您可以在滑块，侧边栏或特色文章等之间进行选择。这种情况最终可能像这样：

array (size=6) 0 => string ‘40.7127753, 73.989308’ (length=21) 1 => string ‘34.0522342, -118.2436849’ (length=24) 2 => string ‘48.856614, 2.3522219000000177’ (length=29) 3 => string ‘48.2081743,16.37381890000006’ (length=28) 4 => string ‘41.90278349999999,12.496365500000024’ (length=36) 5 => string ‘left_sidebar’ (length=12) // Yeah, right…

Or even worse:

甚至更糟：

array (size=5)  0 => string 'left_sidebar' (length=12)  1 => string 'left_sidebar' (length=12)  2 => string 'left_sidebar' (length=12)  3 => string 'left_sidebar' (length=12)  4 => string 'left_sidebar' (length=12)

Your pretty little map is broken now! And you lost all of your entered data. Not funny right?

您的漂亮小地图现在坏了！ 并且您丢失了所有输入的数据。 不好笑吧？

解 (Solution)

You can never protect your custom fields data from being overwritten or deleted. This is how WordPress works and why it is so flexible. You can reduce that risk though.

您永远不能保护您的自定义字段数据不被覆盖或删除。 这就是WordPress的工作方式，以及它如此灵活的原因。 不过，您可以降低这种风险 。

How?By avoiding common names and namespacing all your custom fields keys.

怎么样？ 通过避免使用通用名称和命名空间来定义所有自定义字段键。

My proposed convention is:

我提议的约定是：

• cpt-name_field-name

  cpt-name_field-name

  like

  喜欢

  books_author instead of author, order_items instead of items(solution for most lazy ones :) ).

  books_author代替author ， order_items代替items (大多数懒惰的解决方案:))。

• purpose_field-name

  Purpose_field-name

  like

  喜欢

  front_page_location instead of location, visited_cities_locationsinstead of location.

  front_page_location代替location， visited_cities_locations代替location 。

• prefix_(cpt-name/purpose)_field-name

  prefix_(cpt名称/用途)_field-name

  like

  喜欢

  kg_books_author, kg_visited_cities_locations (for the most strict ones).

  kg_books_author ， kg_visited_cities_locations (用于最严格的位置)。

That is not all. Additionally, you should always take care of optional parameters of built-in WordPress functions:

这还不是全部。 此外，您应始终注意内置WordPress函数的可选参数：

• add_post_meta() has $unique to not add the custom field if it already exists.

  add_post_meta()具有$unique不会添加自定义字段(如果已存在)。

• get_post_meta() uses $single to retrieve only one record (if you expect only one record).

  get_post_meta()使用$single仅检索一条记录(如果您期望仅一条记录)。

• update_post_meta() and delete_post_meta() leverage $previous_value to ensure that you update/delete the key you want.

  update_post_meta()和delete_post_meta()利用$previous_value来确保您更新/删除所需的密钥。

Those parameters are helping in writing better, cleaner and more predictable code.

这些参数有助于编写更好，更干净和更可预测的代码。

And that is not all. Use well tested, well written and extendable plugins like Pods Framework or Advanced Custom Fields. These will help manage your custom fields. They are great when it comes to managing the tangled world of your custom data.

这还不是全部。 使用经过良好测试，编写良好且可扩展的插件，例如Pods Framework或Advanced Custom Fields 。 这些将有助于管理您的自定义字段。 当您管理复杂的自定义数据世界时，它们非常有用。

摘要 (Summary)

In the ideal world, we should always be aware of what you are adding to the system. We should know what your plugins, themes, and custom functions are doing. That is unfortunately not always possible.

在理想的世界中，我们应该始终了解要添加到系统中的内容。 我们应该知道您的插件，主题和自定义功能在做什么。 不幸的是，这并非总是可能的。

Therefore we should pay attention to the code we produce and tighten up all those loose ends.

因此，我们应该注意我们生成的代码并收紧所有这些松散的末端。

That is all folks! I hope you liked it and have a great day!

就这些了！ 希望您喜欢它，并度过美好的一天！

This post was originally published on my private blog where I write about WordPress and development in general.

这篇文章最初发布在我的私人博客上 ，在那儿我写有关WordPress和一般开发的文章。

翻译自: https://www.freecodecamp.org/news/the-tangled-world-of-custom-data-in-wordpress-2ee8b57d49c/