-
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
Capture admin notices and summarize them in editor #5590
Capture admin notices and summarize them in editor #5590
Conversation
I probably could. I'll look up how to do it. Do you want it dismissible like that one? Or should it stick around? |
Definitely dismissible. But if you don't have bandwidth to do this, feel free to bow out. Your work so far has been super appreciated, someone else from the team could presumably take your work and run with it. |
It's no problem, @jasmussen. I'll update the PR. 😄 I'd like to start getting some commits here anyway. |
What happens if the notice only appears on the Post screen? |
That's a good question @danielbachhuber. I was a little unsure where to redirect the user. A previous implementation allowed errors to be viewed in an expandable drawer, but I didn't feel like it would be appropriate to do that within the post editor notice. Do you have a suggestion as to what should be done? |
Ideally, I think we should have some formal API (and corresponding UX) for plugins/themes to register notifications to Gutenberg. Historically, admin notices have been "dump whatever HTML you want to a certain position on the page". It would be better if we had different notification types, and some formal API/UX that intelligently handled a dozen plugins registering admin notices, etc. I recognize that what I suggest is a bit more work though. Maybe we could get someone from the design team to head up a mini project to this effect. |
Completely agree with you that a larger better API is necessary. Cc @hedgefield as I've seen rumblings of that from him. In the meantime it would be nice to have a holdover solution. In that vein perhaps it's fine redirect to the dashboard? This is from the perspective that any plugin that shows editor specific notices, but doesn't show Gutenberg specific notices, would presumably work better in the classic editor (either through the plugin, or through the presence of a non compatible metabox), where these would still show up. Does that make sense? Alternately, perhaps we should indeed look at collapsing the legacy notices in the field. |
Could be worthwhile to include it for a release as experimental and see what sort of feedback we get.
Maybe, although I'm not sure this is the majority use-case. Unknown at this point, I think. |
Great work so far! Thanks for the ping @jasmussen, I did start a trac ticket to get a notification center into WP core recently https://core.trac.wordpress.org/ticket/43484 it's intended to completely capture and replace existing admin notices (except maybe from WP core), so you would indeed have a template to put your notice in instead of HTML whatever you want. Would be helpful in this usecase too I bet. Anyway It's just a proof of concept right now, and knowing core, will take a while to crystallize out ;) but it's good to keep in mind here, and any ideas generated here for something like that would be much appreciated. I'd like to get it going in as small a form as possible as soon as possible, so feel free to chime in on the trac ticket or contact me on slack. As a holdover and Gutenberg-specific solution, this seems quite good already. |
This surrounds all admin notices with a containing div that then hides them, and shows a count of admin notices rendered above the editor content.
Rebased. |
This uses `createInfoNotice` instead of rendering a `Notice` component.
@jasmussen, I've updated the code to use |
This is what I see now, and I love it: One thing, though, if I dismiss it then it's gone, cool. But if I reload the page, it's back again unless the notice has been dealt with elsewhere. This is probably fine, as presumably the notice is there for a reason, and we also don't want to have to build too much cookie logic into this dismissed notice. The one situation where this might be an issue, is when, as Daniel suggests, a plugin is showing a notice that exists ONLY in the editor. Given the redirect you can never actually dismiss that. I don't know how possible this is — but can we toggle a CSS class on Perhaps with a close button in the top right corner that would untoggle the CSS class on
CC: @youknowriad for ideas, as I know he's also thought of notices recently. |
In |
If we can put all of the notices inside such an accordion, I think it's okay to "pull a big drawer down" on top of Gutenberg, as mocked up above, so long as you can close it. |
#3964 is an example of |
Created #5975 for this. |
I can see the idea of an accordion but I have to admit I have concerns over the usability of that. What other options are there? Any examples out there we can learn? |
I'm definitely open to design options here. I feel like I'm kind of stuck on this until we can reach a consensus on what should be done. |
@coderkevin rather than holding it up why don't we get what we have merged in and then iterate? |
The link is incorrect. The notices should expand inline, instead of linking to the dashboard. |
Are we okay with expanding the notices inline? A sort of accordion that expands to show the notices in it? If so, I'll give it a try here. |
Yep, that would be totally fine. You can even do it in a half-hearted way and I'll polish up the visuals. Just ping me if you have a toggle that works. |
Okay, I'll add it to my to-do list this week. 👍 |
Is it likely this will be resumed, or can it be closed? |
Is it still needed? If so, I can put some time towards it. |
It might be safe to consider as partially blocked by #9617 |
@coderkevin I see #9617 is now merged, so @aduth is it worth Kevin finishing this now? |
I personally would love to see this feature wrapped and shipped. |
This would no longer be considered blocked by #9617, correct. With that having been merged, it could have an impact on how best this be implemented (i.e. does it really make sense to be specific to the post editor, if it's more to the general issue of respecting server-side notices?). There was some discussion yesterday in Slack (cc @desrosj) about this, and a point was raised that there's nothing which enforces that what is https://wordpress.slack.com/archives/C02QB2JS7/p1541519233726300 (Mentioned also at #5590 (comment)) What we have here in inspecting class names to determine whether an element can be decided to be a notice seems like a reasonable enough compromise to cover the large majority of backwards-compatibility. To simplify both technical and design implementation, I'm not sure why these can't just be treated as any other notice in the editor, rather than having their own standalone display. I'm not sure about @coderkevin 's availability. I might also be able to put some time toward this. |
Going to close this as superseded by #11604 |
Description
This surrounds all admin notices with a containing div that then hides
them, and shows a count of admin notices rendered above the editor
content.
How Has This Been Tested?
Test with any admin notices that normally show up on a classic post edit. This will instead render a summary notice at the top of the post with a link to the dashboard, which displays admin notices normally.
I made a very big, annoying admin notice just to test this. It does everything in CSS that an admin notice shouldn't and therefore makes a good test: https://github.com/coderkevin/annoying-admin-notice
Screenshots (jpeg or gifs if applicable):
Types of changes
This PR does two things for admin notices:
Bug fix: Wraps all admin notices in a containing div, so they can be more effectively hidden.
New feature: Uses
createInfoNotice
to display a summary notice to show the user that there are WordPress notifications in a more pleasing way, with a convenient link to the dashboard for more information.Checklist: