Make WordPress Core

Opened 15 years ago

Closed 15 years ago

#11395 closed enhancement (wontfix)

make is_user_logged_in() return the $user's ID instead of true

Reported by: denis-de-bernardy's profile Denis-de-Bernardy Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.9
Component: Users Keywords: needs-patch
Focuses: Cc:

Description

Is this just an artifact from the past, or are there any reasons for not doing so? (e.g. Ensuring plugins don't expect a user id to be present in the first place when oauth or the like is used.)

Attachments (1)

11395.diff (563 bytes) - added by Denis-de-Bernardy 15 years ago.

Download all attachments as: .zip

Change History (9)

#1 follow-up: @filosofo
15 years ago

Don't you think it seems reasonable to expect a function prefixed with "is_" to have a boolean return value? That's what the built-in PHP functions do, and all of the other WP functions (as far as I know).

And it especially makes sense in light of that other ticket you opened that shows PHP is inconsistent across versions in comparing variables of differing types.

#2 in reply to: ↑ 1 ; follow-up: @nacin
15 years ago

Replying to filosofo:

Don't you think it seems reasonable to expect a function prefixed with "is_" to have a boolean return value? That's what the built-in PHP functions do, and all of the other WP functions (as far as I know).

It does seem reasonable, but this patch still allows is_user_logged_in() to evaluate to true or false, as it either returns false or a user ID that evaluates to true. It just provides a little more functionality this way.

And it especially makes sense in light of that other ticket you opened that shows PHP is inconsistent across versions in comparing variables of differing types.

Actually, we found that PHP was consistent and documented, and it was only with regards to comparing a string to 0. See #11391. So this isn't an issue, especially since this function would never return 0 or a string.

#3 in reply to: ↑ 2 ; follow-up: @filosofo
15 years ago

If we really need get_current_user_id() or the like let's create it. Let's not add any hidden, unexpected functionality to existing functions.

#4 @Denis-de-Bernardy
15 years ago

what are really needed, in reality, are some kinds of *_current_user_meta() functions. :-P

#5 in reply to: ↑ 3 @Denis-de-Bernardy
15 years ago

Replying to filosofo:

If we really need get_current_user_id() or the like let's create it. Let's not add any hidden, unexpected functionality to existing functions.

Personally, I see it as a bonus. It's like... if I check if a user is logged in for some functionality, the odds are 80% that I'll then wonder which one might be logged in, in order to check a user meta. So might as well return the user's id.

I do see your point that it ought to be named get_current_user_id(), though.

#6 @dd32
15 years ago

+1 for a seperate function.

is_user_logged_in() is exactly that, Is the user logged in. It should be a boolean IMO.

#7 @Denis-de-Bernardy
15 years ago

  • Keywords needs-patch added; has-patch dev-feedback removed

#8 @Denis-de-Bernardy
15 years ago

  • Milestone 3.0 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

just closing, then. it was really mostly a question.

Note: See TracTickets for help on using tickets.