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/