WordPress.org

Make WordPress Core

Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#20529 closed defect (bug) (fixed)

r20565 introduces get_the_author_meta() regression

Reported by: johnjamesjacoby Owned by: nacin
Milestone: 3.4 Priority: normal
Severity: normal Version:
Component: Users Keywords: reporter-feedback
Focuses: Cc:

Description

Plugins like BuddyPress and bbPress use get_the_author_meta() on posts in loops that may not set the $post global or might not even be a post at all. Things like shortcodes and secondary loops of posts with their own WP_Query object still need to use get_the_author_meta() and might not have user ID information available in the $authordata global.

I suggest a few sanity checks to check for object/array values, and load/reset them if they aren't around. Long term we should look into smoother ways to get possibly cached post author data directly.

BackPress, bbPress 1.x, and WordPress pre 2.8 had functions like get_the_author_id() for convenience sake, but they were all deprecated in WordPress 2.8 in favor of the singular author_meta function.

Attachments (1)

20529.patch (1.3 KB) - added by johnjamesjacoby 2 years ago.

Download all attachments as: .zip

Change History (8)

johnjamesjacoby2 years ago

comment:2 scribu2 years ago

How is this is a regression caused by [20565]?

comment:3 nacin2 years ago

When writing a bug report, it is best to concentrate on the problem, not the solution. Like scribu, I have no idea what actually went wrong here. What is the actual nature of the regression? What breaks? What shows up in the error log? What is a sampling of code that can be used to reproduce the problem?

comment:4 nacin2 years ago

  • Keywords reporter-feedback added; has-patch removed

comment:5 nacin2 years ago

After talking with johnjamesjacoby, the issue is that before r20565, every call to a property of $authordata was first surrounded by an isset() check. Thus, if you called get_the_author_meta() without a $user_id when no postdata was set up, you would just get an empty string. (Or int(0) if you requested 'id' as a $field.) But, under r20565, you get a notice for $authordata->ID in addition to the empty string (no int(0) anymore).

Having get_the_author_meta() automatically check $post and reset postdata is interesting, but it would imply that $post was manually manipulated and that setup_postdata() was not called. If we are to be clever, it shouldn't be for edge cases. We *could* actually call the_post(), rewind_posts(), and wp_reset_postdata() like we do in an author.php typically. (I have a feeling that could break quite a bit though.) Regardless, it is an enhancement that deserves its own ticket.

comment:6 nacin2 years ago

  • Owner set to nacin
  • Resolution set to fixed
  • Status changed from new to closed

In [20575]:

Fix a notice in [20565] where get_the_author_meta() may be called prior to postdata from being set up. In this case, the function should return nothing (via the filter). props johnjamesjacoby. fixes #20529. see #20285.

comment:7 nacin2 years ago

http://unit-tests.trac.wordpress.org/changeset/695

Against 3.3, the 'id' condition fails as it expects 0 rather than an empty string.

Against r20574, with -d (WP_DEBUG on), you get a notice.

Against r20575, it passes with WP_DEBUG on.

Note: See TracTickets for help on using tickets.