Change User control to store an object, like the Post control

[kienstra]

Question About Storing As An Object

Hi @lukecarbis,
Making this backwards-compatible was harder than I thought, though I might think of a better way.

It'll require clicking "Update" for each block (in the screenshot below), and the previous values in the block editor won't persist.

Is this PR important? As it is now, the User control stores the user slug, which is immutable.

The only improvement in this PR is a better UI, as it shows a "nicename" in the block editor like John Doe, instead of the slug, like jdoe.

It's an improvement, but wondering if you think it's worth a backwards-compatibility break.

Instead of storing the value as the string user slug, This stores the value as:

{ 
        id: 24,
        userName: 'John Doe',
}

The main difference is the display of the userName in the block editor. Before, it was the user slug, which could be like jdoe.

But this now displays the username, which could be like John Doe. It's what the user selected as "Display name publicly as" in /wp-admin > Users > Your Profile.

There's no change here in the front-end display of the template. block_field() still echoes the username like John Doe, and block_value() still returns the WP_User object.

Backwards-Compatibility Issues

Right now, it also requires clicking "Update" in the Block Lab UI:

This is because the logic saves the block type as object in that UI. This PR might be able to hack that by parsing $this->blocks and changing the saved value to object.

Also there's no backward compatibility for the block in the block editor. It's possible to filter the $attributes for the render_callback, but that filter doesn't have access to the field type.

So it won't know that it's a User control, in order to change the value from a string to an object.

Thanks, Luke!

Closes #288

[lukecarbis]

My view is that for Pro features like this one, as long as we’re in “Early Access”, introducing breaking changes is reasonable.

Personally, I think that keeping the return values for these types of controls consistent will create a simpler and better experience for developers.

I really want to stress though that this is just my opinion. Ultimately, as tech lead, it’s completely up to your best judgement.

[kienstra]

Hi @lukecarbis,

My view is that for Pro features like this one, as long as we’re in “Early Access”, introducing breaking changes is reasonable.

Good point, this PR is an improvement. The control is more intuitive, with the "nicename" (like John Doe) instead of the user slug (like jdoe).

I agree, we can break backwards-compatibility given that it's for "Early Access" users.

[kienstra]

Request For Review

Hi @lukecarbis,
Could you please review this when you have a chance?

The main change for the user will be that the block's <input> displays a "nicename," not simply the user slug.

Before

After

And the block saves the value as an object, not a string:

But there's no difference in the return or echo values of block_field() or block_value().

However, there's a complete backwards-compatibility break. Users will have to select a new value from the block <input>.

[lukecarbis]

Tested both block_field and block_value. Everything looks great. For some reason I thought we used to return the username, not the full user object, but I prefer the full user object as it is in this PR. Ready to merge.

[kienstra]

@lukecarbis, thanks for reviewing this!