[wp-trac] [WordPress Trac] #58903: set_transient() allows invalid transient name

WordPress Trac noreply at wordpress.org
Wed Sep 27 18:59:45 UTC 2023


#58903: set_transient() allows invalid transient name
--------------------------------------------------+---------------------
 Reporter:  jeremyescott                          |       Owner:  (none)
     Type:  defect (bug)                          |      Status:  new
 Priority:  normal                                |   Milestone:  6.4
Component:  Options, Meta APIs                    |     Version:
 Severity:  normal                                |  Resolution:
 Keywords:  has-patch has-unit-tests 2nd-opinion  |     Focuses:
--------------------------------------------------+---------------------
Changes (by hellofromTonya):

 * keywords:  has-patch has-unit-tests => has-patch has-unit-tests 2nd-
               opinion


Comment:

 > I found that WordPress accepts empty strings, null, and false for the
 $transient arg

 I did question if this falls into a broader discussion of input (data type
 and value coming into a function) validation. The transient name to be
 received by `set_transient()` is clearly identified as `string`. Sending
 it anything else (including `null` or `false`) is doing it wrong. The
 broader architectural discussion focuses on how to validate what is sent
 to Core functions. Rather than having isolated data type checks, a more
 structural architectural approach is also being considered across all of
 Core.

 But then @joemcgill pointed out that the
 [https://wordpress.slack.com/archives/C02RQBWTW/p1695836579071649 issue is
 more around an empty string being sent to it]:
 >I think the issue is that the value could be an empty string and cause a
 bad experience. Edge case, for sure, but the updates to safeguard against
 this seem reasonable.

 And in looking at the [https://github.com/WordPress/wordpress-
 develop/pull/4911/files#r1291630289 discussion in the patch], @flixos90
 proposed an idea:

 >You add the limitations only in set_transient(), which I agree is the
 root of the problem. But additionally, wouldn't it make sense to enforce
 those limitations in the other transient functions too? Potentially we can
 introduce a new private function like `wp_validate_transient_name()` and
 reuse in the relevant places?

 I tend to agree with his idea. Rather than fix the issue in only one
 place, instead put in a validation mechanism for all transient functions.
 But doing so might shift this ticket to an `enhancement` rather than a
 bugfix.

 Looking at the description of the ticket:
 >I found that WordPress accepts empty strings, null, and false for the
 $transient arg

 `null` and `false` are doing it wrong, but empty strings might be the
 value to fix.

 Given this ticket is still being discussed and the patch may go through a
 redesign (per @flixos90 suggestion), I'll mark this ticket as `2nd-
 opinion`, to denote
 it[https://make.wordpress.org/core/handbook/contribute/trac/keywords/
 needs more discussion and consideration] to land on a solution.

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


More information about the wp-trac mailing list