Hide/show admin notifications in according with the user will

Actual admin notifications are annoying and take place that should be taken by more important content. An action link could be added to the admin top bar to toggle the admin notices visibility.


Read-only archive: Issues · ClassicPress/ClassicPress · GitHub

Author: giuseppe mortellaro

Vote count: 6

Status: open

Tags:

  • request-modify-feature

Comments

Hello, new here, I wanted to chime in on this as well. While we all know some plugin developers do abuse the admin notifications, and there are a few plugins to hide notifications, as mentioned; they sometimes do hide critical messages we need to see. And for that very reason, I don’t feel there should be an admin switch to remove them.

I feel that this has become an out of control problem due to an oversight in plugin reviews. No plugin that was published for distribution on the .org should have been allowed if it was blatantly abusing the notification system.

It was something that could have been stopped very easily by the review team. I think this is something that CP could look ahead and change overtime. If/when/as CP gains it’s own footing and more plugins and themes are developed, it should be an enforced part of general guidelines if a plugin is to be promoted by CP.

5 Likes

Welcome @WeTite. I completely agree that the solution to this problem is in plugin guidelines and reviews.

The plugin guidelines for our directory do already include such wording:

Therefore I am setting this petition to close in a week.

2 Likes

I doubt that plugin reviews would handle it.
There is a team working on a notifications feature, over at WP. You can follow their progress: feature-notifications – Make WordPress Core
and look at their code: GitHub - WordPress/wp-feature-notifications: WP Feature Notifications - a proposal to modernise the way in which WordPress handles emails, admin notices and user notifications
As it says in the December project review,

Much of the design work has been detailed in issue #23 and issue #26, and we invite other designers to challenge the direction, or just suggest different approaches.

1 Like

I still think it’s best to try this approach first because this is more of a social problem than a technical problem, and technical solutions will only get you so far, as evidenced by comments like this from the original petition:

We get to have somewhat more of a “fresh start” as compared to WP which gives us an advantage in terms of actually being successful here, as opposed to just “getting the design right”.

If in the future some other functionality around notifications is needed then maybe we should consider adding it at that point in time. Maybe we should give this petition a new status like maybe-later instead of declined?

1 Like

Notifications center should be a separate petition. This petition asked for a visibility switch, which a lot of people don’t seem to want. I think this petition can be declined. A new petition for notification center should be opened.

1 Like

Sounds good to me.

I think the right moment to open that new petition would be when we have established our plugin directory and integrated it as part of core, and if there are still problems with notifications at that point, then the new petition should discuss the specific problems and suggest how to solve them.

It is not clear to me what those problems would be yet, because the existing notification system is minimal but works pretty well as long as people use it respectfully.

1 Like

The problem is when you install 10 plugins, and then 10 others on top of that, and 33 of those plugins you have on your site all push notifications like “You have used this plugin a while, rate us now!” or “Your site is in acute danger of this and that, do this now!” and wether or not those plugins actually let you dismiss the notification in a persistent manner (many don’t, despite the clear rules), then your screen gets messy.

It will tell a lot about the quality and seriousness of the plugin developer and that feedback should go to the plugin developer, not to core.
(On that note, we do not have a feedback way for users to submit to plugin developers here in CP. But that is not a urgent issue, since we also basically have no plugins.)

Plugin review team does their best to spot such issue and would of course not publish something where undismissable notices are found, but we really can’t because often the notices appear after a whole while using the plugin and not just on first install. Neither can any sort of code.

What would be a much wiser move would be to make last parameter of admin_notices | Hook | WordPress Developer Resources actually useful. From the DOC:

* optionally use is-dismissible to add a closing icon to your message via JavaScript. Its behavior, however, applies only on the current screen. It will not prevent a message from re-appearing once the page re-loads, or another page is loaded.

That is basically inviting folks to do it wrong. I am not even sure there is an inbuilt method to actually dismiss notices for good or if all those are actual custom implementations. There are sort of hacks, it seems (like plugins - How to stop showing admin notice after close button has been clicked - WordPress Development Stack Exchange). So … IMO, and if I do not miss anything, the fault for this mess is actually on core API and should if anything get fixed there by providing a proper, dismissible notice hook argument.

So, in that light, maybe we can convert this Petition in an ask to resolve that/Enhance that feature?

Additional info… there seems to be a define('DISABLE_NAG_NOTICES', true); which users might find useful who want to get rid of whatever notices (but I have never tried it)

Plugins/themes actually have to use it for it to work. Very few do, because it’s not required.

Very few do, because they don’t know about DISABLE_NAG_NOTICES.

Learned something new today :slight_smile:

Right, it’s actually a unofficial constant - more reading makes the wiser!
I did not see that this morning when skimming thru the doc…

This should be prohibited at the directory level. If something like that is found in a plugin that is already published, then we would address it once someone creates a forum thread about it.

That should be a new, separate petition instead. However I think it is a bit premature to add something like that now.

This topic was automatically closed after 7 days. New replies are no longer allowed.