smartyp

Also confirming this is a problem.

The change seems to be around the initial entry to the job screen and the way Bucket Selection is being validated. For example, if I now edit a job that has been running fine for ages it will now give this error next to Bucket selection:
User: arn:aws:iam::xxxxxxxxxx:user/the-bucket-name is not authorized to perform: s3:ListAllMyBuckets because no identity-based policy allows the s3:ListAllMyBuckets action

On edit it used to just display the bucket name if it had already been set. Now it appears to be trying to get the list of all buckets first to check if the bucket name is still valid. And if it can’t get the list then it no longer displays the buck name field and displays this error instead – even though the bucket name is valid. Previously the plugin would give a less ‘critical errror’ that bucket names could not be accessed BUT would still allow you to manually enter the bucket name (so this can’t just be an AWS change?)

Note: the existing backup job will also continue to work just fine IF you don’t save that job. If you change anything else, not only does it happily save (with no visible bucket selected!) but the save wipes out the previously set valid bucket name so backups then fail..!

So ideally a return to the previous behaviour of allowing you to manually enter the bucket name where a list of all buckets is not permitted would be best. Or if that doesn’t work with the way validation is being done now, maybe add a tickbox to allow this check to be overridden and the bucket name be typed in?

@ulrichbittl17 All plugins have a Download button on their main page, so you can download from there then upload/overwrite via FTP. Or probably easier – you can just delete the plugin folder via FTP so you can login, then reinstall it to get the latest version.

Cool – thanks. ??

Thanks for your help Sybre – now sorted by setting: Settings / Reading / Your homepage displays = Your latest posts

(more info just in case anyone else hits this – one site was using the Extra theme which has a weird/quirky ‘extra’ homepage setting so just don’t use it if possible, and another site was using Twenty Sixteen theme but had no setting at all which shouldn’t be possible)

Thanks.

Are write permissions required for all of those? I tried with write anyway just in case, but it looks like more permissions are required as I get the same error as above.

This is for the basic core plugin, no addons, just one-time transactions.

It’s not the api that’s insecure – it’s the use of keys that have unlimited access to everything. No app should ever have more permissions than it needs. That’s basic security. ?? This is why Stripe introduced restricted api keys in 2017:-
https://stripe.com/blog/u2f-restricted-keys

The main api key has permissions to do pretty much anything on a Stripe account – so if those keys are compromised that’s big trouble. It only takes one plugin/theme to ever have a security hole.

E.g. see the recent case where someone had their keys stolen, probably from a mysql injection attack – those keys were then used to create a new Stripe sub account with different bank details and make large volumes of charges that ended up in the hackers account. Stripe are pursuing the real owner of that account for the refunds (around $70,000)!

Using a restricted key makes this kind of thing impossible. Nobody should be using the main api key on a website.

Yeah because of the way it’s been built there doesn’t seem to be any way to hide it using css (without blocking other messages) or override the code to prevent displaying it either.

I did submit a feature request as suggested (thanks). But a week later and it doesn’t even show in the request list yet. ˉ_(ツ)_/ˉ

Am I correct in assuming that the website error issue has been repaired in the 4.0 release of this plugin?

Yes. They reverted back to the previous version (otherwise the broken version would have rolled out to even more sites). But yes, going to 4.0.1 now would have been less confusing.

Deleting it through WP admin seems to delete the jobs I’d created

There’s a setting for this (under Settings/General = ‘Keep BackWPup data stored in the database after uninstall’ – I think it’s ‘off’ by default though).

Same error here too (auto updated site). Re-installing the 4.0 release fixes it, but yeah, the same site killing error twice in a week..?!

Awesome – thanks. ??

Only just installed it, so yup this is on the latest version (0.3.4).

This is still an issue.

Thanks.

Unfortunately noindexing tag pages doesn’t work. ?? At least, it doesn’t work in Yoast SEO – “Picture tag ngg_tag” is already set to noindex, but no robots header is output on the tag pages.

OK. Are there any filters or a function I can override to achieve both?

No, I mean select only the image formats you want to use, i.e. at the moment you have to have jpg/png/gif and can optionally have webp and avif. If I just want webp then how do I stop an uploaded jpg being optimised as both a jpg and webp, and just converted to webp.

It wasn’t really an issue before as webp was a free addition to jpg/png/gif (so it didn’t really matter which you were paying for), but now we’re all going to be paying for every image generated. So that will be double the cost unless you can choose not to optimise what you don’t need.