Sideloaded image is not compressed

Hi Alduin,

Thanks for your question. Currently it is not really a supported use case of the plugin, but I’ll try to help you as best as I can.

You’re correct that the plugin hooks into wp_generate_attachment_metadata. When registering to that hook, the plugin specifies a priority (10):
https://github.com/tinify/wordpress-plugin/blob/5b8074b9abf33232df81389859db77c4bbbf6d85/src/class-tiny-plugin.php#L60

This is documented here: https://developer.www.ads-software.com/reference/functions/add_filter/

It could be that your other plugin(s) has the same or a higher priority (i.e. lower integer value) and executes before our plugin has registered the callback. You could check the other plugin’s priority and change it to see if this is the cause of the issue.

Kind regards,
Tinify

Hello,

thank you for your reply.

Well, my plugin calls itself as an action attached to the “init” hook (prio 420 for the memes), so that all plugins should be available and loaded. And since I do not hook myself into wp_generate_attachment_metadata directly (I have media_handle_sideload do that for me), I don’t think that’s the issue here.

Best
-Alduin

OK I debugged it further. Point of breakage is class-tiny-image.php:
if ( $this->settings->get_compressor() === null || ! $this->file_type_allowed() ) {

get_compressor() returns null and therefore the compression will not happen.
https://github.com/tinify/wordpress-plugin/blob/5b8074b9abf33232df81389859db77c4bbbf6d85/src/class-tiny-image.php#L198

Compressor seems to be the API key if I saw this correctly. I can tell you for sure that it should not be null because I did save an API key because bulk compression does work (and so does manual upload).

I also did a var_dump($GLOBALS['wp_filter']); so you don’t have to. ?? As long as you don’t call it right at the beginning, it does not matter – the hooks init or wp_loaded or wp – each of them are fine, the action is registered and gets triggered. “Just” the compression fails because settings->get_compressor is null.

I hope this information helps further in the process of fixing that. Because I think this will not only fix my issue but also next to every other who uploads images other than manually. (I read a some reports about contact form uploads and such).

Best,
-Alduin

Hi Alduin,

Good to hear you were able to narrow it down further.

The compressor is initialised from the admin_init hook: https://github.com/tinify/wordpress-plugin/blob/5b8074b9abf33232df81389859db77c4bbbf6d85/src/class-tiny-settings.php#L82

Is your plugin running in the admin environment and causing this hook to fire?

Nice, ok then we have the likely problem. My plugin runs on the frontend. Because it’s a self-made API of some sort. It checks if some $_GET is set.

I will try some stuff today and report back with what I found if that’s ok. ??
(And I am pretty sure this WILL fix all other use cases reported in this forum where Tinify is not compressing when uploaded from elsewhere!)

Hello,

I found a solution. In said class-tiny-settings, I stored a little flag if the compressor is initialized. And get_compressor checks for whether or not it is available. And if not, it initializes one. And then us pleb calls from the frontend can compress too.

I can offer you a neat little diff and I would ask you to apply it to the official code because it does fix a bug (or adds a feature, depending on how you want to sell it ?? ).

Threads that would be fixed (most likely):

Pretty sure this: https://www.ads-software.com/support/topic/does-not-compress-when-i-upload-image-from-fronted/

I think even this: https://www.ads-software.com/support/topic/include-wp-cli-support/ (Well, not CLI as such, but I assume recreating the sizes is done by WP API and if all plugins are loaded and hooks are used, Tinify should also be triggered)

If BuddyPress runs through WP APIs too, this is fixed as well. https://www.ads-software.com/support/topic/admin-vs-site-members/

And this https://www.ads-software.com/support/topic/compress-new-images-during-upload-frontend/

And so on ??

It should not have any notable performance impact because it only initializes the compressor when it would actually do something with an image (when the hook we talked about is ran).

I do not have a github account and I kinda sorta don’t want one, so I offer you a diff (and the finished file) instead. We are talking about src/class-tiny-settings.php

Diff:
https://pastebin.com/9S3DZ86N

Whole resulting file if you want to check its function:
https://pastebin.com/hiCQwyWz

Thanks for the hint,
Alduin

• This reply was modified 3 years, 4 months ago by alduinwf.

Hi Alduin,

Awesome, great to hear that you got it working!

We’ll consider adding this as a feature in a future version of the plugin

Happy compressing!