Eusebiu Oprinoiu

Hello, Pacotole!

Both methods are OK to use. In this case, using the global variable was an intentional choice.
The people who need to use this filter might not have much experience with WordPress development and might not be aware that filters accept additional arguments. Or even if they do, they might forget to specify the number of arguments, leading to errors or unexpected behavior.
This is just a safety net on my part.

Thank you, Janis!
I appreciate it…

Thank you, John! I appreciate it.

That’s OK. Thank you for taking the time to inspect this.

Thanks for letting me know about the Schema bug. The settings have been lost, and I will have to recreate them.

As for how Git Updater works, you need to be aware of a few things:

While checking for updates, Git Updater reads the version from the Primary Branch. If the repo has tagged releases, it will pull the zip archive from the latest tagged release. If it doesn’t, it pulls the zip archive of the Primary Branch.

As a consequence, the plugin version in the Primary Branch needs to be the same as the one in the latest tagged release. You will get an infinite update loop if they are not in sync.

Andy Fragen recommends the use of a separate development branch.
Personally, I push everything to master, but I don’t increase the plugin version until I am ready to publish a new release.

You can read more about the update behavior here:
https://git-updater.com/knowledge-base/versions-branches/

Hello, Sybre!

Git Updater is a great plugin. It’s one of the easiest solutions to provide seamless updates.

Unfortunately, I don’t think you will be able to use it unless you change your GitHub slug to “autodescription”. I found two old tickets relevant to the issues above, and this is the fix suggested by Andy:

https://github.com/afragen/git-updater/issues/746
https://github.com/afragen/git-updater/issues/779

Maybe one day, WordPress will allow developers to change the slug of their plugins.

Hello, Sybre!

The interface of Git Updater does not provide a way to exclude plugins. It can only be done with code, like in the KB article you linked. (which is good enough for me)

The problem is Git Updater works on the assumption that both the WordPress and the GitHub slugs are the same. (as stated here in the official documentation)

Why did you add this header? Do you really need it?
Plugins in the WordPress repo already have a reliable update mechanism. This header is meant to be used with plugins hosted on GitHub that have no other means to provide seamless updates.

After additional testing I can confirm the issues are caused by Git Updater.
Apparently this has been a problem for a long time for plugins hosted in the WordPress repo with a different slug than on GitHub.

I am very disappointed.
You did not update the library in the update released a few days ago.
Please, release a fix for this, preferably using phpseclib 3.0.34 or newer. (it contains additional fixes for the JIT issues)

Hello, Rob!
I came across Media Cleaner in the past, and it might do a good job. Jordy Meow is a good developer.

I checked the website listed in your profile and I see that you are using Avada. This theme used to rely on TimThumb to generate thumbnails and switched to native WordPress function 7-8 years ago. If your website is older than that, all images used as Featured Images that were uploaded before the transition have orphan thumbnails.

Hello, Rob!

The plugin removes only thumbnails that are tracked by WordPress.
If your website has been around for a long time, chances are that at some point, you used a theme that generated thumbnails on the fly with third-party scripts like TimThumb or Aqua Resizer. WordPress was never aware of those thumbnails. They are orphaned files on your server.

This was a big problem 7-10 years ago, and it plagued many themes, especially those available from ThemeForest. Thankfully, modern themes rely on native WordPress functions to generate thumbnails.

I am not aware of any plugin or script that can help you remove those orphan thumbnails, but you could solve this issue by deleting and regenerating all existing thumbnails. By recreating everything from scratch, you don’t have to check which files are tracked by WordPress and which are not.

1. Make a full backup of your website
2. Identify and delete all thumbnails either manually via FTP or with the help of a script. If successful, only the original files should remain on your server.
3. Regenerate all thumbnails either by using the Regenerate Thumbnails plugin or through WP-CLI.

If you use the Regenerate Thumbnails plugin, make sure the option to delete thumbnails for old unregistered sizes is enabled, and make sure you do not skip regenerating existing thumbnails.

If you have a lot of files in your media library, it’s better to use WP-CLI. The command you need is wp media regenerate --yes.

PS: In case you are not aware of this, you should regenerate thumbnails every time you change your theme or when you make changes to image sizes under Settings > Media.

No problem.
I appreciate you took the time to fix it.

As for the “Go Pro” button, I’m with Sean. The current implementation is very intrusive. It should be a normal menu link, not styled like a button. It looks out of place in the admin UI.

I don’t think this is an error specific to me.
This is most likely due to stricter type declarations introduced in PHP 8.2.
I manage websites for multiple people and all that run on PHP 8.2 have this issue.

I also tried to reinstall the plugin, making sure to remove all options from the database, but the issue persists.

Hello, Frank!

The plugin handles media on your local website.
The Cloudflare integration should be done either via the official Cloudflare plugin, or your caching plugin. For other CDNs, this should almost exclusively be done via a caching plugin.

But you only need to worry about this if you frequently replace images (with the same filename and location on the server) and you don’t have any plugins to handle the CDN/Cloudflare integration.

Also, Autoremove Attachments only removes your images if they are attached as children to a parent post, page, or custom post type, AND if they are not re-used in another location. In other words, only media files that are not used anywhere are deleted. So even if old images are cached at the edge, they are not referenced anywhere on your website. This means the plugin should not cause any problems even when you don’t have proper CDN/Cloudflare integration.