pixeldynamo

Reading posts like this make me die a little on the inside. Sadly it’s not an isolated occurrence.

It’s not possible for code to bypass a browser dialog in this way. If such vulnerabilities existed then Google would have acknowledged user-reported issues over at: https://bugs.chromium.org/p/chromium/issues/list. Such reports don’t exist.

Widespread notification spam is not a thing, if it were we would all be bombarded.

The simple fact is that the user in question blindly consented to receive notifications, forgot, then became morally outraged when a notification popped up. Since that time they’ve lied on behalf of WordPress staff that plugin code could somehow override browser behavior, which is frankly ridiculous. The consent for notifications happens away from the site through the window chrome.

From what I can see all push-notification plugins have suffered user reports of this kind, even sites which run commercial solutions such as Roost frequently see complaints from users – although most don’t go to such extents to claim innocence.

Have you considered rolling back?

We’re still on 2.3.2 ourselves.

Later versions also introduced an annoying nag screen to both administrators and users, complaining about the use of competing plugins even when the equivalent Yoast functionality was disabled. It’s far from helpful and borders on monopolistic. We’ve since identified a workaround to disable this ‘feature’, but the current 3.0.x releases still have a lot of unpleasant issues which need to be resolved before we would consider moving up. Every time we’ve attempted an upgrade we’ve ended up rolling back to our trusty 2.3.2 backup.

WPTavern has a post on the lessons learned from 3.x but it only touches on a small proportion of the woes experienced with recent builds. Take a look through the support category for a measure of the potential pain.

Either create a new post as markdown on the site or via an app.

Edit the post via the WYSIWYG – editing markdown elements converts them to HTML.

It appears to be an interaction between the WYSIWYG changes in 4.3 and jetpack markdown.

In the end I edited the source of the plugin.

There’s a fundamental difference between how you envisage the plugin should be used and what suits teams in the real world. In this case it would have made no sense to tell our writers to change the way they post because a plugin developer said so.

You’re also misusing the resolved status.

Indeed, they also appear for non-admins. My editors can see the message twice at the top of each page.

Same here, there should be a setting to disable the tour for all users anyhow.

It’s ridiculous that it pops up thanking users for installing when they’ve simply upgraded.

All done.

I can give you access to a site which exhibits the issue, but we’re going to need to take the discussion away from the forums to provide you with credentials.

Hey Jeremy,

I’ve been in contact with Zoe and we’ve ascertained that aside from a couple of common plugins (Yoast/Akismet/Jetpack) we’re also both WPEngine customers.

WPEngine makes a number of configuration changes for the sake of speed and efficiency, including limiting the number of post versions kept. I can provide a copy of our wp-config if useful, please let me know where you would like it sent.

Up to 242 now, a big improvement on before but there’s obviously something we still need to identify.

This is still happening for us too, the timing is quite amusing seeing as Kraken is currently emailing paying customers to offer a $5 credit in return for a five-star review.

Up to 105 (JS) already in five hours of a total of 142 files.

I’ve excluded _stq but still generating a lot of files, how many are reasonable to expect?

Both sets of strings from the js file match the jetpack script, I can’t find them anywhere else.

I can email samples or the entire files if useful.