[wp-trac] [WordPress Trac] #50225: get_edit_term_link can technically accept also WP_Term and object for $term_id

[WordPress Trac]

#50225: get_edit_term_link can technically accept also WP_Term and object for
$term_id
--------------------------+-----------------------------
 Reporter:  david.binda   |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  General       |    Version:
 Severity:  normal        |   Keywords:
  Focuses:  performance   |
--------------------------+-----------------------------
 The doc block for `get_edit_term_link`
 [https://core.trac.wordpress.org/browser/trunk/src/wp-includes/link-
 template.php?rev=47808#L990 currently says it can only accept the
 term_id], but the `$term_id` param is being passed to the `get_term`
 function right away, which, IMHO, technically means it can be
 [https://core.trac.wordpress.org/browser/trunk/src/wp-
 includes/taxonomy.php?rev=47611#L807 anything what the get_term function
 accepts], which is `int, WP_Term, object`.

 I'm really able to figure out why the documentation limits the param to
 term_id only. I wonder if I perhaps missed something?

 However, the `get_term` behaves differently when it's being passed
 different values/types. From the documentation:

 > (int|WP_Term|object) (Required) If integer, term data will be fetched
 from the database, or from the cache if available. If stdClass object (as
 in the results of a database query), will apply filters and return a
 WP_Term object corresponding to the $term data. If WP_Term, will return
 $term.

 I have noticed that in many places where the code is passing just the
 `term_id` to `get_edit_term_link`, the code might go over some
 unnecessarily complicated logic, eventually causing some minor
 inefficiencies.

 For instance, the `wp_tag_cloud`. The function
 [https://core.trac.wordpress.org/browser/trunk/src/wp-includes/category-
 template.php?rev=47808#L707 first collects all the terms], which means
 collecting whole lines of terms entries in database, populating the terms,
 and then [https://core.trac.wordpress.org/browser/trunk/src/wp-includes
 /category-template.php?rev=47808#L723 loops over those passing in just the
 `term_id` to the `get_edit_term_link`] (as well as `get_term_link`, tho).

 Which means that the `get_edit_term_link` calls the `get_term` just with
 the `term_id`, which in turn, collects the very same data from local
 cache, in ideal situation, despite the data have all been already
 collected by `get_terms` and are ready in the `get_edit_term_link`
 function.

 However, there's also a situation in which passing in just the `term_id`
 actually triggers unnecessary SQL queries or prompts some remote cache get
 requests.

 In case the term is not being used elsewhere on the page, and in case a
 persistent object cache is in use, the `get_terms` may end early if it was
 cached previously, [https://core.trac.wordpress.org/browser/trunk/src/wp-
 includes/class-wp-term-query.php?rev=47808#L705 there is an early return],
 only triggering the `WP_Term::populate_terms`, skipping the
 `populate_term_caches` call,
 [https://core.trac.wordpress.org/browser/trunk/src/wp-includes/class-wp-
 term-query.php?rev=47808#L721 which otherwise happens later].

 So, the terms are well populated, but they are not in local object cache,
 and need to be brought from the object cache server, and if not found
 there, the `get_term` function, when passed in just the `term_id`, fetches
 the data from the database again.

 That said, I believe that the possibility of passing in the WP_Term (or
 object) to `get_edit_term_link` should be documented, and used by
 WordPress itself on respective places.

 It, IMHO, would also be beneficial, if we could go further, and pass in
 the WP_Term or object to any similar calls, eg:
 [https://core.trac.wordpress.org/browser/trunk/src/wp-includes/link-
 template.php?rev=47808#L880 `get_term_feed_link`, which can in theory also
 accept the WP_Term object], and which is being called repeatedly from
 [https://core.trac.wordpress.org/browser/trunk/src/wp-includes/class-
 walker-category.php?rev=47808#L161 `Walker_Category::start_el`], which is
 being called from `wp_list_categories` which
 [https://core.trac.wordpress.org/browser/trunk/src/wp-includes/category-
 template.php?rev=47808#L572 previously collected the WP_Term objects via
 `get_categories`] (which is calling the `get_terms`)

 The same goes for `WP_List_Table`.

 I'm attaching a patch, with those adjustments.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/50225>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform