WordPress.org

Make WordPress Core

Opened 21 months ago

Last modified 14 months ago

#36341 assigned defect (bug)

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

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

Description


Attachments (1)

36341.diff (625 bytes) - added by DrewAPicture 21 months ago.

Download all attachments as: .zip

Change History (13)

@DrewAPicture
21 months ago

#1 @SergeyBiryukov
21 months 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
16 months 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
16 months 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 WordPress.com 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
16 months 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
16 months ago

init seems like a good promise to developers

+1

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


15 months ago

#7 @desrosj
15 months 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.


15 months ago

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


14 months ago

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


14 months ago

#11 @pento
14 months 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
14 months 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.

Note: See TracTickets for help on using tickets.