Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add toggle on featured image to fallback to first image of post #65107

Closed
wants to merge 0 commits into from

Conversation

efu98
Copy link

@efu98 efu98 commented Sep 6, 2024

What?

Add a toggle in the featured image settings to fallback to first image if no featured image is set

Why?

Display an image for old blog post that do not have featured images.
Closes #39170

How?

Toggle sets the already existing attribute useFirstImageFromPost from the featured image block. (See #56573)

Testing Instructions

  1. Create a new post with an image in it, but no Featured image.
  2. Edit a template with a query block that contains a Featured image block.
  3. Notice that the Query Block doesn't display any image in the Featured image block in the editor or the frontend.
  4. Enable "Fallback to first image from post" in the featured image block settings.
  5. Notice that the Query Block now displays the image in the Featured image block in the editor and the frontend.

Testing Instructions for Keyboard

Screenshots or screencast

fallbackfirstimage

@efu98 efu98 requested a review from ajitbohra as a code owner September 6, 2024 05:24
Copy link

github-actions bot commented Sep 6, 2024

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: efu98 <elfu98@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: annezazu <annezazu@git.wordpress.org>
Co-authored-by: jasmussen <joen@git.wordpress.org>
Co-authored-by: cbravobernal <cbravobernal@git.wordpress.org>
Co-authored-by: SantosGuillamot <santosguillamot@git.wordpress.org>
Co-authored-by: paaljoachim <paaljoachim@git.wordpress.org>
Co-authored-by: skorasaurus <skorasaurus@git.wordpress.org>
Co-authored-by: gaambo <gaambo@git.wordpress.org>
Co-authored-by: liviopv <liviopv@git.wordpress.org>
Co-authored-by: mrfoxtalbot <mrfoxtalbot@git.wordpress.org>
Co-authored-by: davipontesblog <dpontes@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

@github-actions github-actions bot added the First-time Contributor Pull request opened by a first-time contributor to Gutenberg repository label Sep 6, 2024
Copy link

github-actions bot commented Sep 6, 2024

👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @efu98! In case you missed it, we'd love to have you join us in our Slack community.

If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information.

@torounit torounit added [Type] Enhancement A suggestion for improvement. [Block] Post Featured Image Affects the Post Featured Image Block labels Sep 6, 2024
@annezazu
Copy link
Contributor

annezazu commented Sep 9, 2024

Tagging in @WordPress/gutenberg-design for feedback here! I'd love to see this land.

Copy link
Contributor

@t-hamano t-hamano left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think everything about the code is correct. There may be room for improvement regarding the label.

I agree with exposing this attribute as UI, but #56573 mentions the following:

We decided not to expose this setting in the UI for now. Since this is a more advanced feature, we are happy for now to only expose it through an attribute that theme builders can add via the code.

cc @scruffian @dmsnell

@jasmussen
Copy link
Contributor

This is definitely a feature we want. We even had a mockup for this a while back, which I can't find, but eventually this feature grew into what is today "block connections". The idea being that virtually any block that shows an image, should be able to connect to both the basic data sources (featured image, first attachment), or indeed external sources as defined in functions.php:

gb-19-block-bindings.mp4

For that reason, I would think the UI we end up surfacing should be the same. Not necessarily the above shown, but perhaps an evolution of that. Mainly I'd be concerned about landing the toggle and then having to support that forever, as a separate UI to what block bindings would be able to do. I'd defer to a developer on insights here.

@efu98
Copy link
Author

efu98 commented Sep 10, 2024

Hello! Thanks for all your feedbacks!
@jasmussen the dropdown only for html attributes? Or also attributes of the block such as useFirstImageFromPost? I'm not sure how it would work with a Boolean attribute too?

@jasmussen
Copy link
Contributor

the dropdown only for html attributes? Or also attributes of the block such as useFirstImageFromPost? I'm not sure how it would work with a Boolean attribute too?

Thank you again for the work. Whether this PR can move forward or not is mainly dependant on having a good plan for the final look of the user interface.

In this case, the toggle is just another setting, that might work. But for the final UI we need to consider all the different places you can replace media (block toolbar and inspector for cover, featured image, image, media & text, site logo), and all the different sources you can replace them with (featured image, uploaded image, image from URL, image from media library, a registered block binding such as https://picsum.com/400/300, or indeed, first image attachment). If we end up with rows of toggles for each of those, we'll end up with multiple different user interfaces for the same. So even if this PR is a nice step forward, unless we're careful, we'll end up adding too many knobs and dials.

I'd like to defer to developers like Aki who's participating in the discussion here: if we added the toggle today, would it be easy without back-compat concerns to move it to a unified UI at some point in the future? Or is it better even today, to start hooking into that "Replace" dropdown that we are unifying across media blocks? Example from the Cover block:

Screenshot 2024-09-11 at 09 39 15

@t-hamano
Copy link
Contributor

t-hamano commented Sep 12, 2024

Mainly I'd be concerned about landing the toggle and then having to support that forever, as a separate UI to what block bindings would be able to do.

My understanding is that if the feature is supported internally as an attribute, we need to continue to support it regardless of whether the UI is exposed, so adding a toggle itself doesn't concern me.

Or is it better even today, to start hooking into that "Replace" dropdown that we are unifying across media blocks?

This is not difficult to achieve. We can achieve this by making the following changes in the trunk branch:

Details
diff --git a/packages/block-library/src/post-featured-image/edit.js b/packages/block-library/src/post-featured-image/edit.js
index dff34379e4..4a340bbf6a 100644
--- a/packages/block-library/src/post-featured-image/edit.js
+++ b/packages/block-library/src/post-featured-image/edit.js
@@ -14,6 +14,7 @@ import {
        PanelBody,
        Placeholder,
        Button,
+       MenuItem,
        Spinner,
        TextControl,
 } from '@wordpress/components';
@@ -353,6 +354,8 @@ export default function PostFeaturedImageEdit( {
         * - Has an image assigned
         * - Is not inside a query loop
         * Then display the image and the image replacement option.
+        * @param root0
+        * @param root0.onClose
         */
        return (
                <>
@@ -367,7 +370,22 @@ export default function PostFeaturedImageEdit( {
                                                onSelect={ onSelectImage }
                                                onError={ onUploadError }
                                                onReset={ () => setFeaturedImage( 0 ) }
-                                       />
+                                       >
+                                               { ( { onClose } ) => (
+                                                       <MenuItem
+                                                               onClick={ () => {
+                                                                       setAttributes( {
+                                                                               useFirstImageFromPost:
+                                                                                       ! useFirstImageFromPost,
+                                                                       } );
+                                                                       onClose();
+                                                               } }
+                                                               isPressed={ useFirstImageFromPost }
+                                                       >
+                                                               { __( 'Fallback to first image from post' ) }
+                                                       </MenuItem>
+                                               ) }
+                                       </MediaReplaceFlow>
                                </BlockControls>
                        ) }
                        <figure { ...blockProps }>

image

However, we cannot adopt this approach right now because the current Post Featured Image block does not display the Replace button unless the media is set, whereas the useFirstImageFromPost attribute should be controllable regardless of whether the media is present or not.

#64288 aims to show the add media button whether media is set or not. I think this also applies to the Post Featured Image block.

So I think the path forward is either:

  1. Proceed with this PR and expose the toggle UI >. Always show the add media button > Move the toggle UI into the dropdown
  2. Always show the add media button > Add functionality equivalent to this PR there

Also, I don't know if the UI this PR is aiming for will be supported as the Block Bindings API in the future. @SantosGuillamot and @cbravobernal may know something about this 🤔

@jasmussen
Copy link
Contributor

My understanding is that if the feature is supported internally as an attribute, we need to continue to support it regardless of whether the UI is exposed, so adding a toggle itself doesn't concern me.

Just looking now at the code, yes I guess this already exists as an attribute. That makes the back-compat conversation much simpler.

However, we cannot adopt this approach right now because the current Post Featured Image block does not display the Replace button unless the media is set, whereas the useFirstImageFromPost attribute should be controllable regardless of whether the media is present or not.

Would it be reasonable to make the same changes to the Featured Image block as we've recently made to the Image block? That is, show "Add image" or "Add media" when it's in the placeholder state? That would let us add the "Use first image attachment" option to both the Add and Replace options.

@t-hamano
Copy link
Contributor

Would it be reasonable to make the same changes to the Featured Image block as we've recently made to the Image block? That is, show "Add image" or "Add media" when it's in the placeholder state?

That's right. The Post Featured Image block doesn't need a white placeholder in the first place, so the flashing that was discovered in the comment wouldn't occur.

If we need this implemented before this PR, I'll be happy to submit a PR.

@efu98
Copy link
Author

efu98 commented Sep 12, 2024

I think it's a good idea to use "Add image" to show the option! Please let me know if there's anything I can do.

@cbravobernal
Copy link
Contributor

cbravobernal commented Sep 12, 2024

Post featured image block is not yet supporting block bindings.
When it does in a near future, we could create a source that calls the first image post, and would appear as a new item on the fields list.

Something like this (we could just render the option without a key, sources should be able to decide the view there)

Screenshot 2024-09-12 at 13 51 54

Then we could add the attribute (as already exists the possibility) if that source is checked.

I think this a design decision (adding new buttons-options vs using block bindings UI).

@jasmussen
Copy link
Contributor

I think this a design decision (adding new buttons-options vs using block bindings UI).

It should only ever be one button, there should not be two ways to do it. But whether that's two things under the hood (the existing attribute, and the new block binding), I'll defer to developers how/whether that might be possible.

@cbravobernal
Copy link
Contributor

cbravobernal commented Sep 12, 2024

updateBlockBindings will end being public. Is using updateBlockAttributes, that UI could call a binding, that under the hood could achieve a similar result.

const updateBlockBindings = ( bindings ) => {

Also, it seems that just updating the attribute is the easiest solution. Current solution is using HTML API, which is also similar to what bindings do.

@SantosGuillamot
Copy link
Contributor

I am still not sure if the Post featured image block will support block bindings or if we should rely on the Image block connected to the post feature image. This still needs more exploration to decide one or the other.

Having said that, in terms of code, given that the useFirstImageFromPost attribute already exists, I don't think adding this UI should be an issue in the future.

@t-hamano
Copy link
Contributor

@cbravobernal @SantosGuillamot Thank you for your feedback!

It's reassuring to know that adding new UI is unlikely to be an issue in the future.

To move this PR forward, I'd like to work with the following suggestions:

Or is it better even today, to start hooking into that "Replace" dropdown that we are unifying across media blocks?

This is not difficult to achieve. We can achieve this by making the following changes in the trunk branch:

However, we cannot adopt this approach right now because the current Post Featured Image block does not display the Replace button unless the media is set, whereas the useFirstImageFromPost attribute should be controllable regardless of whether the media is present or not.

#64288 aims to show the add media button whether media is set or not. I think this also applies to the Post Featured Image block.

@paaljoachim
Copy link
Contributor

paaljoachim commented Oct 7, 2024

I assume I am having a few missing spots of information here and there.
Regarding the Replace drop down mentioned here:
#65107 (comment)

For instance can a user add an Image block and click the drop down to select the specific Image as featured?
Something similar is being worked on in this PR: #65896

@efu98
Copy link
Author

efu98 commented Oct 8, 2024

Hello @paaljoachim, it seems like there are only 3 option on the Replace dropdown so there is no way to set a specific image as the featured image.
Capture d’écran 2024-10-08 à 22 17 04
I also looks like the replace dropdown is also not available in the site editor, but I think some people would want enable the fallback to the first image of a post globally.

@paaljoachim
Copy link
Contributor

Hey @efu98 Elise.
Yeah. I would also like to see a fallback to adding the first image in post as featured as a Global option.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Block] Post Featured Image Affects the Post Featured Image Block First-time Contributor Pull request opened by a first-time contributor to Gutenberg repository [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Post featured image block: Allow using "first image" as a fallback
8 participants