Try/use featured image attribute #39515
Conversation
|
Size Change: +581 B (0%) Total Size: 1.21 MB
ℹ️ View Unchanged
|
| useEffect( () => { | ||
| attributesContext.map( ( ctxAttr ) => setAttributes( ctxAttr ) ); | ||
| }, [ attributesContext ] ); |
There was a problem hiding this comment.
Could this be handled in the edit-post package? As in, we wouldn't pass attributesContext – we would just update the attributes through some store action.
|
Thanks for the review @adamziel! To answer your question if we could handle this without doing anything to Also this is missing rendering synch, but I think a simple solution of storing current set value and replacing it at render in the rendered string with the live value is doable. Edit: ideally for the blocks we want to bind we add to its metadata the attribute that holds our key value store for attribute and the in editor dynamic data, so we don't need to add anything to |
|
This works great. A few thoughts: The option to use the featured image only shows once a featured image is set in the sidebar. I can also "replace" the image with another one, but it doesn't work if the featured image is toggled on. Could we add the toggle to the media replace panel, and hide the other options when its toggled? Alternatively could we use the media replace flow to set a featured image? When I add a cover block and then toggle the featured image it looks like this: |
|
Added a (draft) solution based on I seem to have a problem understanding my own PR :D because I can't get the un-setting of the featured image bind (clicking the icon to remove the binding) to register as an attribute change for the block. I'll come back to this. To test follow the steps in the PR description then use the classic editor to change the featured image. After saving in the classic editor, the post on the front end should render the new featured image. Opening the post in the block editor should automatically update the block. The downside of this is that if the featured image is changed elsewhere, then the post when opened starts with unsaved edits.
This should work now. Even if this somewhat works, it still has a long way to go:
I will iterate and clean up the code and also see what is the bare minimum to add for WordPress 6.0 that we can build later on, starting now only with the cover block, the most requested block to bind as it is important for page building in the site editor. |
|
Nice work, thanks for your patience as we unearth all these gnarly edgecases!
It seems okay to start without this? I feel like there's a separate iteration we can do on media placeholders in general that can happen outside of this. Mostly so the value of what the PR brings can land sooner!
Yes, this is a good point. Would it not be fine to just revert to the Image block placeholder state when untoggled? It seems like even if we used a button inside the menu — "Use featured image", a "Clear" button would still take you back to the placeholder.
I'd gray them out! Potentially that allows us to show a tooltip still, explaining why they are grayed out. Not for this PR, or probably any time soon, but it'd be neat to enable the featured image masking tool in the inspector when the featured image is set:
See also: #38990 |
draganescu
force-pushed
the
try/use-featured-image-media-replace-flow
branch
from
b1ba74e
to
a7d522b
Compare
draganescu
force-pushed
the
try/use-featured-image-media-replace-flow
branch
from
a7d522b
to
ae13af2
Compare
|
Biggest problem with this approach is that if the featured image is changed elsewhere then the data in the serialized image or cover blocks is stale, but it does not look stale on the front end. Also I have not checked if |
|
What if there was a URL that always pointed to the currently-set featured image? That would allow the Image block to always have an up-to-date image without the need for dynamic rendering. |
|
In a chat with @youknowriad about the idea @ZebulanStanphill put above, having an URL that links to a featured image per post would break the expectation that when I copy/paste the block in another post it would use the new post's featured image. |
|
@draganescu Then just make it work similar to the latest iteration of the Table of Contents block (#29739): the block saves its markup so it doesn't use dynamic rendering on the front-end, but when you copy-paste the block into another post, it automatically adjusts to that post and changes the saved markup. The editor can dynamically pick the URL to be rendered based on a |
|
Close in favor or #39658 |
What?
Continuation of #39410
Closes #13795 and advances #37753.
Why?
We need ways to use featured image when doing page building, as well as site building, via core blocks.
How?
Introduced a special prop that
BlockEditcan use to set attributes based on contextual data it received from the editor. The idea is that the editor implementation (e.g.edit-post) has access to data and it needs to pass it toBlockEditbecause this is the component that is always mounted in the editor, and we need it so that we can update blocks without hooking or modifying blocks themselves.Changes to data that the editor implementation can access happen in various ways (from plugins, from the editor itself, from blocks) hence the need for things that don't appear and disappear, hence don't het unmounted.
Testing Instructions
Screenshots or screencast
bound-attribute-featured-image.mp4