Persistent Notices on your own admin page please

[planetahuevo]

This is from your development notification post: (source)

Persistent notices

TSF now stores some notices in your database, so they can be shown to you later, and sometimes even more than once. We call these “persistent notices”.

Persistent notices are awfully annoying. We know that. However, since plugin auto-updates are part of WordPress 5.5, we can no longer expect you to invoke an update manually.

These notices are used when we expect them to go unnoticed otherwise–they are conditional, and may only show up when all of these conditions are met:

• You have sufficient administrative capabilities or a matching user ID. For example, you must be able to install plugins.
• You are (or aren’t) on a specific administrative page. For example, we won’t show some notices on the block-editor.
• The time limit hasn’t expired. For example, the update-notice won’t show up after 7 days from updating.
• The view count hasn’t been reached, regardless of who has seen it. For example, we only show some notices 3 times.
• You haven’t dismissed it. There’s an X-button at the top-right.

If you find a notice reappearing indefinitely, you might have a stubborn caching plugin enabled. So, clear your site’s cache.

---

The whole WP admin is getting crazy, as you said yourself. I do not want to see the notices, I do not care, I read your logs and access the site from WP CLI.
So the only people watching this are clients or other collaborators that does not need to watch it at all.
So,
1- Can you make so that the notices are only shown on your plugin settings page?
And better one:
2.- Can you add a config option to disable completely them?
And if you add this with a wp-config constant that will be the best thing so we can disable them be default on all our sites.
Thanks

[sybrew edit: readability & markup, added link to source]

[sybrew]

1. Yes. But, we choose how to handle this per notice invoked. We could allow administrators to filter these, but that'll cause an inconsistent mess and an increased number of support tickets ("Why did this happen!? I wasn't informed!"). We sometimes must output notices on specific pages, and we can't allow users to forward these elsewhere.
   We only use persistent notices when we're sure the user can miss the notice otherwise (e.g., by using auto-update). Currently, only two instances are used ("thank you for upgrading", and "hey, we want to reach out to you")—I think we'll leave it at that for the foreseeable future.
2. Yes. You can disable notices for the upgrade suggestion via this constant--any other notice will still pass through:
   define( 'TSF_DISABLE_SUGGESTIONS', true );
   If your collaborators cannot install plugins, they shouldn't have seen the notice.

For 1, see this doc comment on how we register the notices...

the-seo-framework/inc/classes/admin-init.class.php

Lines 468 to 475 in 0404f31

	* @param array $conditions : {
	* 'capability' => string Required. The user capability required for the notice to display. Defaults to settings capability.
	* 'screens' => array Optional. The screen bases the notice may be displayed on. When left empty, it'll output on any page.
	* 'excl_screens' => array Optional. The screen bases the notice may NOT be displayed on. When left empty, only `screens` applies.
	* 'user' => int Optional. The user ID to display the notice for. Capability will not be ignored.
	* 'count' => int Optional. The number of times the persistent notice may appear (for everyone allowed to see it).
	* Set to -1 for unlimited. When -1, the notice must be removed from display manually.
	* 'timeout' => int Optional. The number of seconds the notice should remain valid for display. Set to -1 to disable check.

...and how we test against that (continue means we forgo displaying the message). The counter at the bottom will delete the notice when it's been displayed X times:

the-seo-framework/inc/classes/admin-pages.class.php

Lines 450 to 463 in 0404f31

	if ( ! \current_user_can( $cond['capability'] ) ) continue;
	if ( $cond['user'] && $cond['user'] !== $this->get_user_id() ) continue;
	if ( $cond['screens'] && ! in_array( $base, $cond['screens'], true ) ) continue;
	if ( $cond['excl_screens'] && in_array( $base, $cond['excl_screens'], true ) ) continue;
	if ( $cond['timeout'] > -1 && $cond['timeout'] < time() ) {
	$this->clear_persistent_notice( $key );
	continue;
	}
	// phpcs:ignore, WordPress.Security.EscapeOutput -- use $notice['args']['escape']
	$this->output_dismissible_persistent_notice( $notice['message'], $key, $notice['args'] );
	$this->count_down_persistent_notice( $key, $cond['count'] );

For 2, these are the conditions we applied to the upgrade notice, where we excluded many screens we thought it would've been annoying:

the-seo-framework/inc/functions/upgrade-suggestion.php

Lines 136 to 143 in 0404f31

	[
	'screens' => [],
	'excl_screens' => [ 'update-core', 'post', 'term', 'upload', 'media', 'plugin-editor', 'plugin-install', 'themes', 'widgets', 'user', 'nav-menus', 'theme-editor', 'profile', 'export', 'site-health', 'export-personal-data', 'erase-personal-data' ],
	'capability' => 'install_plugins',
	'user' => 0,
	'count' => 3,
	'timeout' => DAY_IN_SECONDS * 7,
	]

We're very mindful of where, when, to whom, and how many times we output these notices. The last thing we want to do is turn users against us.

Related (I also left my thoughts there): https://wptavern.com/is-wp-notify-the-silver-bullet-wordpress-needs-to-end-admin-notification-spam

[planetahuevo]

We're very mindful of where, when, to whom, and how many times we output these notices. The last thing we want to do is turn users against us.

Well, I prefer that you left people the choice of not having any notifications at all.
Keep your notifications to your plugin screen. That is what I want.
So you are getting users against you at the end (at least one, me).
Lets agree to disagree, but thank you for the long and documented reply.

[sybrew]

I think we're miscommunicating. Please understand that I'm building the plugin with the best intentions, and with all its users at heart. Unfortunately, I'm sometimes forced to make changes not everyone agrees with. I'll try to explain.

1: Persistent notices are meant to convey critical messages

The persistent notice system wasn't built for marketing purposes. Instead, these types of notices will help users stay informed of critical changes made to their site or the plugin.

For example:

• "Twitter Photo Cards have been deprecated. Your site now uses Summary Cards when applicable." (source)
• "The previous sitemap timestamp settings have been converted into new global timestamp settings." (source)
• "A cronjob is now used to ping search engines, and it alerts them to changes in your sitemap." (source)

Since you work in WP CLI, I'm sure you've never seen any notice of this kind. But, they were there—check the sources above. I think you should be welcoming of this change, for you might've missed a change affecting your or your collaborators' businesses.

Now, if site administrators go about and filter where those notices should be outputted, they and their users might miss these when it's genuinely essential to the site.

To reiterate, because WordPress added another reason for us to deliver critical messages in a particular fashion (next to CLI, there's also plugin auto-updates), we chose to go with the persistent-notices route. We mean to use it until the WP Notify project releases to the public. Hopefully, this is sooner than later (maybe WP 5.6?), because I know we're now adding to the problem.

So, this whole issue might be resolved by the end of this year already! :)

2: The notice was meant to inform our users, and to get to know them.

This is what the notice said:

The SEO Framework was updated to v4.1! It brings 9 new features and [over 350 QOL improvements for performance and accessibility](https://theseoframework.com/?p=3598).

Did you know we have [10 premium extensions](https://theseoframework.com/?p=3599), adding features beyond SEO? Our anti-spam extension runs locally, has a 99.98%% catch rate, and adds only 0.13KB to your website.

We want to make TSF even better for you — please consider [filling out our survey](https://theseoframework.com/?p=3591), it has 5 questions and should take you about 2 minutes. Thank you.

As you can see, it wasn't just a marketing grasp. It was primarily meant to convey a message that the user's site was upgraded to v4.1, with a link to the changelog. It wouldn't be wise to output that only on the settings page, for that might've gone unnoticed.

We also put a survey link there—that survey is vital for us moving forward since we know very little about our userbase (we don't track). The team behind the WordPress plugin repository is unreachable; we can't communicate with them about anything other than security issues or guideline violations.

3: We do not advertise within the plugin.

TSF has no ads, and no upsells... not even branding. Nothing in the plugin steers our users to our premium services, yet we need to sell those to stay afloat.

This is what TSF isn't: It's not the first plugin (AIOSEO), it's not the plugin that screams loudest (Rank Math), it's not the plugin with the biggest reach (Yoast SEO), nor the one that's cheap and doesn't fix smelly code (efficient approach, though) (SEOPress).

TSF is the most secure, fastest, and most professional SEO plugin out there. We don't implement or remove features just to so we can sell more licenses.

Major updates for TSF take thousands of hours to complete. Please take a minute just to scroll through and take a glimpse at the full v4.1 changelog—there you'll find minuscule changes we made to improve every aspect of the plugin. As a developer, I'm sure you'll understand that's beyond difficult. Yet, if you believe that the plugin has lost value because we added a single sentence that helps us next to one that helps you, then please tell me how I can do it better.

Ultimately, it's vital for me to at least do some marketing within the plugin. The short end is that making a plugin with zero advertisements is self-deprecating.

I believe we've been forced to add at least some hints of marketing since WordPress isn't there for its developers (here's another rant from a Core Team member). It's why I linked to the WP Tavern post in my previous reply, where this problem is sorely highlighted; it's caused by the melancholious ignorance of the WordPress plugin repo team.

So, since TSF v3.0.6, I added a single extra notice that changes every time I bring a major release. Back then, I also added a constant we've been checking for ever since.

---

So, to get back to your message:

Well, I prefer that you left people the choice of not having any notifications at all.

We did. Add this to your wp-config.php file, and you'll never see these types of notices again:

define( 'TSF_DISABLE_SUGGESTIONS', true );

That constant was in the plugin since v3.0.6. I never received any complaints about this before, so I forwent conveying that it existed in this update. I also trust developers to browse the code every once in a while, especially since security is so important.

Alternatively, you can use this. It'll force all TSF's notices to go on "its" settings page. But, I don't know if you should use it; for the reasons explained above:

add_action( 'the_seo_framework_after_admin_init', function() {
	$tsf = the_seo_framework();
	remove_action( 'admin_notices', [ $tsf, '_output_notices' ] );
	add_action( 'the_seo_framework_setting_notices', [ $tsf, '_output_notices' ] );
} );

Keep your notifications to your plugin screen. That is what I want.

There's no mention of "The SEO Framework" on the settings screen. So, I'm not really sure if we can call it "ours".
Moreover, we expect users to go there only once in their lives. So, I doubt anyone will see an upgrade notice there.

So you are getting users against you at the end (at least one, me).

I noticed. Yet, I hope I've conveyed my reasoning behind this clearly, and that we can move forward from here on out.

I understand that the upselling part of the notice didn't convey well to you. I want to ask you why you think this is unacceptable. I also wonder why you haven't considered our services yet. Thank you!

[planetahuevo]

Well, that is again an amazing long response. Thank you for that.

There is still one thing you are not considering.
People like me, that use your plugin because we value performance, code well written and support, we already read the logs of the plugins before to update, we do not activate autoupdates, and we understand when things like this happen to a plugin.
I manage the sites for my clients, so they trust me with all this, and they do not want to know.
You want them to know, you want them to read. They do not want to. They pay me not to read that, because I do that for them.
They pay money to get rid of all notifications.
So, at the end, what I do is I code myself a plugin to disable most notifications from most plugins, but I try not to use or recommend the ones that do this too often or that make it too difficult to disable (not your case).

So, all your reasoning that you need to show things there, is wrong because the people that use your plugin, or at least this is what I have seen between other people I know, are people that know about WordPress and are not the "standard" user.

So you are building this for them, but then you consider that they are not good enough to know when they need to read logs or not.
Well, I know you want those notifications, but I prefer you to focus your development on removing anything not essential from the plugin that to add more "stuff" to my database or admin screen. And notifications are non essential features, we have logs for that.
So, if you are not going to remove then, provide other options, with a wp-config code to disable them completely or to show them only on the settings screen. If you do that, most of your users won´t even know that option is there, the pro users will know and will be happy to recommend it again to more pro users, and everyone will be happy.

About your business model, this is not the place to discuss, as this is a public forum and I prefer to send you my comments privately, if that is ok with you.

[sybrew]

I do consider people like you. This plugin came to fruition because I used to do the same work as you did. It's why I made the notification as non-obtrusive as possible, auto-dismissible, and not being outputted on pages authors have to do actual work. I also prevent all my clients from installing plugins, which is also checked against with this notification:
current_user_can( 'install_plugins' ).

I won't ever add anything to the plugin I wouldn't like to see in other plugins.

The persistent notices also do not add anything more to your database than we did before the update. They use the same option index as "you updated your settings (or that went wrong)" (THE_SEO_FRAMEWORK_SITE_CACHE === 'autodescription-updates-cache'), and they clean up after themselves. There's also no pollution of incremental indexes, something many other plugins do not consider.

I understand that you, as a developer, manage sites and wouldn't like your clients to see our once-in-a-year notification we output that helps us make a brilliant plugin freely available. For that, please register this constant:

define( 'TSF_DISABLE_SUGGESTIONS', true );

However, if you check our support forums, you'll be greeted by a plethora of users that are not aware of new features, know nothing about multisites, host with GoDaddy, stick with WP 4.9 because they couldn't find the Classic Editor plugin, find that the FAQ structured data is the holy grail of success, enable right-click prevention, and are still figuring out how to press CTRL+SHIFT+R.

We're dealing with over 140,000 users, and most of them aren't developers. Most of them need a helping hand, and we're there for them. If you disagree with something, feel free to send a PR that helps you filter it out; I'd love to see more contributors to this project!

If you wish to discuss things privately, you can do so via our contact page.

I'm considering this issue closed since we're flogging a dead horse: You can already filter it out, and this has been in our API docs since TSF v3.0.6:

define( 'TSF_DISABLE_SUGGESTIONS', true );