Make WordPress Core

Opened 10 days ago

Last modified 6 days ago

#44579 new defect (bug)

get_option() is type aware now (returns Integers as Integers)

Reported by: gdespoulain Owned by:
Milestone: Awaiting Review Priority: normal
Severity: minor Version: trunk
Component: Options, Meta APIs Keywords:
Focuses: docs Cc:



I noticed that the get_option() function now returns the value type it was originally given (ex. I give an INT in update_option(), then get_option() returns an INT).

But the doc doesn't seems to agree with that:


* Any scalar values will be returned as strings.

This text seems to be there for historical reasons (https://core.trac.wordpress.org/ticket/31820) and something changed in the code since then, but I can't find the related commit.

Proposed text to fix the doc:

* This function is type-aware: the return type will be the same as the last given input value.


Change History (3)

#1 @pfefferle
9 days ago

  • Component changed from General to Options, Meta APIs
  • Focuses docs added

#2 @boonebgorges
9 days ago

Hi @gdespoulain - Welcome to Trac, and thanks for the ticket!

The bit of documentation you cite here was added in [36234]. You can read the backstory in #31820 and #22192, but briefly: get_option() and similar functions return all values as strings *except when pulled from memory on the same pageload as when update_option() is called*. So:

update_option( 'foo', 1 );
var_dump( get_option( 'foo' ) );
// int

update_option( 'foo', 1 );
// refresh page
var_dump( get_option( 'foo' ) );
// string

You may also see the same behavior between pageloads if you're running a persistent cache (Memcache, Redis, etc) depending on the nature of the cache. Can you confirm?

This being said, this bit of documentation could probably be improved. Something like "Note that scalar values may be returned as strings when retrieved from the database" might be a more accurate wording.

#3 @gdespoulain
6 days ago

Thanks for the insight @boonebgorges :)

I did some more unit testing with $wp_object_cache->flush() to simulate the page reload and indeed, I can confirm the values are then returned as strings.

It's a good idea to update the documentation in order to reflect this behavior... but on the other hand, I'm a little disturbed by said behavior...

Wouldn't it be better to have a consistent return type, whatever the use case? For reliability purpose?


Last edited 6 days ago by gdespoulain (previous) (diff)
Note: See TracTickets for help on using tickets.