-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Editor: Display Site Icon (if one is set) in Gutenberg Fullscreen Mode #22952
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems like a good approach to me for now. As we discussed earlier, the main concern is that updating the site_icon_url
setting would not actually change the site_icon
option under the hood. All of the site icon related code (like the favicon and get_site_icon_url
pulls from that option under the hood. Unfortunately, since that option stores a media ID and not a URL, we can't use it directly for our purposes here.
packages/edit-site/src/components/header/fullscreen-mode-close/index.js
Outdated
Show resolved
Hide resolved
return ! select( 'core/data' ).hasFinishedResolution( | ||
'core', | ||
'getEntityRecord', | ||
[ 'root', 'site', undefined ] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't this need to match the useEntityProp
args?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great question. I'm not entirely sure if they have to be the same because I couldn't find great documentation on hasFinishedResolution
, but I'll investigate and update you here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
one thought is that since 'root', 'site'
translates to a single query which fetches /settings
, there probably isn't a need to be more granular, since every prop is resolved in the same request. (I think)
packages/edit-site/src/components/header/fullscreen-mode-close/index.js
Outdated
Show resolved
Hide resolved
I tried testing on gutenberg.run but was not able to because of errors in the customizer. |
packages/edit-site/src/components/header/fullscreen-mode-close/style.scss
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work here. Left some comments.
packages/edit-post/src/components/header/fullscreen-mode-close/index.js
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good REST AP wise.
Testing this on my end works well with and without the icon set. This is great to see! |
postType: getPostType( getCurrentPostType() ), | ||
}; | ||
}, [] ); | ||
return { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mtias @youknowriad do you think we should limit this to just edit-site for now, or do you think it would also be good to start testing it in edit-post?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should do it in both, but if we are not certain yet, better to keep it in edit-site. We would need to decide if it's ready for 5.5 as well (in edit-post).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We would need to decide if it's ready for 5.5 as well
Sounds good 👍 . I'm newer on the team so I'm not sure what this entails. Could you elaborate?
Also, I wanted to call out that I'm on the gardening rotation so development on this PR is going to slow down until the end of the month.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The second week of July is the beta period for WordPress 5.5. Anything that affects the post-editor needs to be in good shape by then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mtias I'm back from the gardening rotation, which leaves us a few weeks to test this feature if we want it in 5.5. I see two options here:
1. Test post-editor for 5.5 release
Pros:
- Site icon feature released sooner
- No need for a follow-up PR to bring post-editor to feature parity
Cons:
- The accelerated timeline could cause us to miss issues, especially since code review on this PR isn't finished yet.
2. Test post-editor for 5.6 release
Pros:
- More time to test the feature
Cons:
- Have to follow up with a second PR to ensure feature parity between site editor and post editor
Also @sirreal Would you be able to send me documentation about how I'd make sure the post-editor is tested thoroughly with these changes for the 5.5 beta?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mtias @vindl Since it sounds like there is more extensive testing needed before releasing this feature in edit-post
, I'm leaning towards separating this feature into two PRs. The current PR would be for edit-site
, and the follow-up would be for edit-post
.
Since the work here isn't urgent, we wouldn't have to rush testing while we prep for 5.6. Let me know what you think.
Data from WordPress REST endpoints can be preloaded. We're effectively asking the server to inject a response on the initial page load that we know will always be triggered on that page. The alternative is waiting for the page to load, waiting for the scripts to executre, and then waiting for a response to a network request. Preloading the site icon means that upon initial page load, rather than a blank placeholder, the icon will be displayed almost immediately. Edit post preloading happens in core, and the endpoints we specify for preloading are extensible through the block_editor_preload_paths filter. This change preloads the endpoint that serves site icon data to edit post.
I moved the edit post preloading into the |
Done. Did we decide that we wanted this to land in the wp core release? |
If I understand correctly, I think we're past the 5.5 deadline. I'll defer to Riad. Happy to go with 5.5 or 5.6. |
yes, unfortunately, we're definitely passed the deadline for 5.5. |
that makes sense to me. 👍 |
className="edit-post-fullscreen-mode-close" | ||
icon={ wordpress } | ||
iconSize={ 36 } | ||
className="edit-post-fullscreen-mode-close has-icon" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might be missing some context, but is there a reason why we're adding the .has-icon
class?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good question.
Previously, we used to pass the wordpress
icon (an SVG
component from @wordpress/icons
) via the icon
prop to Button
. The Button
component forwards that prop to an Icon
element it embeds, and sets the has-icon
prop.
Since we're no longer passing the logo to Button
via the icon
prop (but wrap the Button around the logo), we're losing the .has-icon
styling and have to add it back manually.
However, we might explore an alternative...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Icon
component seems to accept pretty much any valid component as a fallback. So we might be able to continue to pass in our custom log (or fallback) via Button
's icon
prop, and remove the manually added has-icon
prop (which is arguably an implementation thing rather than part of the API).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was experimenting a bit with this, and it would be possible. However, the Icon
component is also passing a size
prop to the element it clones, and <img />
elements don't support that. So let's keep things as they are.
Okay, I think this is ready to land! 🎉 |
I'm not sure what's going on, but my local install now shows a broken image instead of the WordPress logo: I don't think its related to this PR (I think my local install is busted in some other way), but it makes me think there should be a better fallback if the image doesn't exist, or if its been deleted from the library. |
Thanks for letting us know Shaun. The code, as it exists today, will use the WordPress Logo as the default icon to render if a user hasn't uploaded a custom one.
I didn't realize that the default WordPress logo could be removed. Maybe the fallback should actually be to render nothing at all? Let me know what you think @shaunandrews |
Sorry, I think there's a misunderstanding. I had a Site Icon setup previously, but at some point had deleted the image from my library. When this PR was merged, I noticed that the editor tried displaying my Site Icon, but the file no longer exists — hence the broken image in my previous comment. |
* @return array Modified path list to preload. | ||
*/ | ||
function gutenberg_preload_edit_post( $preload_paths ) { | ||
$additional_paths = array( '/?context=edit' ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This ticket has been rejected on Core, should we remove that code from here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the heads up Riad 👍 This is on my radar -- will respond when I get the chance tomorrow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's been quite a while since I've looked at this code, but yeah removing it makes sense to me, especially if, according to Timothy, the index endpoint doesn't even support context
query params.
I'll spin up a draft to remove this code soon.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here's an attempt at making the entity request urls more specific to each entity, and prevents the need for preloading /?context=edit
: #30482
The `site_icon_url` index was supposed to ship with WordPress 5.6, but was [WordPress/gutenberg#22952 never backported to core]. This commit backports the original PR from Gutenberg repository: * [WordPress/gutenberg#42957 #42957: REST API: Add the missing 'site_icon_url' to the index] Follow-up to [52080]. Props Mamaduka, bernhard-reiter, TimothyBlynJacobs. See #56467. Built from https://develop.svn.wordpress.org/trunk@54083 git-svn-id: http://core.svn.wordpress.org/trunk@53642 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The `site_icon_url` index was supposed to ship with WordPress 5.6, but was [WordPress/gutenberg#22952 never backported to core]. This commit backports the original PR from Gutenberg repository: * [WordPress/gutenberg#42957 #42957: REST API: Add the missing 'site_icon_url' to the index] Follow-up to [52080]. Props Mamaduka, bernhard-reiter, TimothyBlynJacobs. See #56467. Built from https://develop.svn.wordpress.org/trunk@54083 git-svn-id: https://core.svn.wordpress.org/trunk@53642 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The `site_icon_url` index was supposed to ship with WordPress 5.6, but was [WordPress/gutenberg#22952 never backported to core]. This commit backports the original PR from Gutenberg repository: * [WordPress/gutenberg#42957 #42957: REST API: Add the missing 'site_icon_url' to the index] Follow-up to [52080]. Props Mamaduka, bernhard-reiter, TimothyBlynJacobs. See #56467. git-svn-id: https://develop.svn.wordpress.org/trunk@54083 602fd350-edb4-49c9-b593-d223f7449a82
The `site_icon_url` index was supposed to ship with WordPress 5.6, but was [WordPress/gutenberg#22952 never backported to core]. This commit backports the original PR from Gutenberg repository: * [WordPress/gutenberg#42957 #42957: REST API: Add the missing 'site_icon_url' to the index] Follow-up to [52080]. Props Mamaduka, bernhard-reiter, TimothyBlynJacobs. See #56467. Built from https://develop.svn.wordpress.org/trunk@54083
The `site_icon_url` index was supposed to ship with WordPress 5.6, but was [WordPress/gutenberg#22952 never backported to core]. This commit backports the original PR from Gutenberg repository: * [WordPress/gutenberg#42957 #42957: REST API: Add the missing 'site_icon_url' to the index] Follow-up to [52080]. Props Mamaduka, bernhard-reiter, TimothyBlynJacobs. See #56467. git-svn-id: https://develop.svn.wordpress.org/trunk@54083 602fd350-edb4-49c9-b593-d223f7449a82
Description
This PR addresses issue #20929
Iterations on W icon in the editor header
. It renders the current site icon (if one is set) instead of the default WordPress icon in the site and post editor.Note:
register_setting
to extend the WordPresswp/v2/settings
API. @ockham discussed the idea of including that as a field in Core WordPress itself. We are considering opening a new issue, and I'd love to hear more feedback about this.How has this been tested?
Full Site Editing
Full Site Editing Demo Templates
Screenshots
With no uploaded site icon
With site icon
GIF
Types of changes
Checklist:
Requirements
With default WordPress icon
782px
With custom site icon
782px
Browsers