Make WordPress Core

Opened 8 years ago

Last modified 6 years ago

#36341 assigned defect (bug)

Add a note about the 'init' hook to the DocBlock for get_current_user_id()

Reported by: drewapicture's profile DrewAPicture Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Users Keywords: has-patch
Focuses: docs Cc:


Attachments (1)

36341.diff (625 bytes) - added by DrewAPicture 8 years ago.

Download all attachments as: .zip

Change History (13)

8 years ago

#1 @SergeyBiryukov
8 years ago

  • Component changed from Upload to Users

Should be used only after the {@see 'init'} action has fired, as the current user is not set before that point in the loading order.

This seems to contradict comment:19:ticket:14024.

get_current_user_id() calls wp_get_current_user(), and while it might be uncommon to call it before init, it appears to work as expected for me on plugins_loaded. Is there something I'm missing? :)

#2 @DrewAPicture
8 years ago

  • Milestone changed from Future Release to 4.7
  • Owner set to DrewAPicture
  • Status changed from new to accepted

@johnjamesjacoby Recommendations for which hook to reference here?

#3 @johnjamesjacoby
8 years ago

init has been (and is currently) the proper action, based on an unmodified core load order.

But, WordPress doesn't complain very loudly if anything regarding the current user is loaded prematurely.

The Customizer currently modifies the load order because of the split-pane view. I'm still not convinced this is necessary (and have a ticket and a probably-stake patch somewhere) and even does current user checks very early so it can short-circuit requests that are clearly intended for capable logged-in users.

The issue with this arises from plugins (namely bbPress) that don't hook anything in (even roles and mapped meta caps) until plugins_loaded, so when something needs to call the current user ahead of init, it should be at their own risk and with the understanding they are choosing to violate the core action order.

Does that make sense? It's really one of the only places in WordPress core where this type of action-jump can occur, usually on accident.

#4 @jorbin
8 years ago

  • Keywords commit added

If init is where things are guaranteed to be ready, that's what we should promise in the docs. It's possible for things to be ready early, but init seems like a good promise to developers.

#5 @johnjamesjacoby
8 years ago

init seems like a good promise to developers


This ticket was mentioned in Slack in #core by desrosj. View the logs.

8 years ago

#7 @desrosj
8 years ago

Patch still works for me. If everyone is happy with the wording here, I think this can get merged.

This ticket was mentioned in Slack in #docs by morganestes. View the logs.

8 years ago

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.

8 years ago

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.

7 years ago

#11 @pento
7 years ago

  • Keywords commit removed

If #23016 is committed, this disclaimer will no longer be necessary.

Also, Core does not obey this rule, see ticket:29783:50.

#12 @DrewAPicture
7 years ago

  • Milestone changed from 4.7 to Future Release
  • Owner DrewAPicture deleted
  • Status changed from accepted to assigned

Let's wait and see how #23016 shakes out.

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