[wp-trac] [WordPress Trac] #14017: New template "tag": get_custom_field()

[WordPress Trac]

#14017: New template "tag": get_custom_field()
-------------------------------------------------+-------------------------
 Reporter:  filosofo                             |       Owner:  obenland
     Type:  enhancement                          |      Status:  assigned
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  Posts, Post Types                    |     Version:  3.0
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-unit-tests dev-      |     Focuses:  template
  feedback                                       |
-------------------------------------------------+-------------------------

Comment (by costdev):

 As mentioned by @obenland in
 [https://core.trac.wordpress.org/ticket/14017#comment:13 comment 13],
 [https://developer.wordpress.org/reference/functions/post_custom/
 post_custom()] is already available.

 There is also
 [https://developer.wordpress.org/reference/functions/get_post_custom_values/
 get_post_custom_values()], which returns an array of values for the given
 field.

 Following that, this works:

 {{{#!php
 <?php
 function get_post_custom_value( $key = '', $post_id = 0 ) {
         $value = get_post_custom_values( $key, $post_id );
         return $value ? maybe_unserialize( $value[0] ) : null;
 }

 // Usage
 var_dump( get_post_custom_value( 'my_custom_field' ) );
 }}}

 - Is consistent with existing naming i.e. `post_custom()`,
 `get_post_custom()`, `get_post_custom_values()`.
 - Lets
 [https://developer.wordpress.org/reference/functions/get_post_custom/
 get_post_custom()] handle checks on `$post_id`.
 - Reduces maintenance.
 - Reduces the number of unit tests required.

 However, `get_post_custom_values()` is in use by
 [https://wpdirectory.net/search/01GAECEV4RA4KZ2SF0163Q07GG 789 plugins]
 and [https://wpdirectory.net/search/01GAECHBYXN58VW1KEMRAWM8DZ 140
 themes].

 While I don't have the strict number of plugins and themes using
 `get_post_meta()` - because I don't want to write the regex for excluding
 default meta fields 😝 - a cursory glance at plugins using
 `get_post_meta()`
 [https://wpdirectory.net/search/01GAECJRV75F9JRCF5FAVNBNB2 ref] and
 plugins using `get_post_meta( get_the_ID()...`
 [https://wpdirectory.net/search/01GAEDFE13TNWDGPJADMJX3C6N ref] suggests
 that `get_post_meta()` is used significantly more often for custom fields
 - likely for the reasons mentioned in this ticket's description.

 Therefore, do we:
 - as the current patch does, introduce a new function that also tries to
 use the current queried object and has a name more consistent with
 `get_post_meta()` in hopes it would make transitioning more likely.
 - introduce something like `get_post_custom_value()` above for consistency
 with the already available functions, since any new function will be
 mentioned in a dev note anyway.
 - don't introduce a new function, as the community already widely uses
 `get_post_meta()` and adding a new function might just introduce another
 asset for the BC-promise?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/14017#comment:16>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform