-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make Tinify service available outside wp-admin #24
base: master
Are you sure you want to change the base?
Conversation
Making Tinify available outside wp-admin. For example if you sideload an image using an API or a frontend plugin (e.g. contact forms). No performance impact because compressor is only initialised if we actually have to process media, in which case we have to do quite heavy work anyway.
Hi Realrellek, Thanks for showing interest in this project and investing the time to extend the code base. How would you be integrating the plugin with the code above? Knowing how you would like to use it would give us a better view and would also help in documenting such feature. I think it might be better to create a new init funciton for your use case, as defined here:
With this change we are modifying the behaviour of the get_compressor function which is used in multiple places. Please share some example usage code we can discuss about the implementation |
Hi rkoopmans, sure. First of all, I don't think it changes the behaviour of the get_compressor. Because we have another issue: The compressor is only initialised when admin_init() is called (or xmlrpc_init or ajax_init). Which only happens when we have an xmlrpc-request or an ajax request or we are in wp-admin. see:
Otherwise, we do not have the compressor available. What we do have available, are the hooks. Most notably for wp_generate_attachment_metadata in class-tiny-plugin.php:
What that means is, if you use any WP function to sideload an image (or upload it using WP API) outside WP Admin, the compression method is called but will fail because of a missing compressor. My suggestion would initialise a compressor when it is needed. It does take into account that initialising a compressor without the need to can be a performance issue (especially when it fails for whatever reason), so I'd only do it when necessary. I do not like the idea of having an own init() function because that would bind my code to yours. It is much more elegant if I can just use WP API to sideload an image and magic just happens. Example code. Aside from countless support threads on wp.org asking for support for say contact forms or others that allow uploading from the frontend. But my specific problem is as follows: I have 2 WP installations. One is the master and on is the slave. On the master, the editor writes an article (with images and tables and everything). And editor clicks a link. Link beams everything to the slave install where another editor can modify the content but keeps images. I only copy the original size over and have WP do the crops. But those are not optimized then. Which I want Tinify to do. Relevant code: `$featuredID = null;
The actual upload happens in the last few lines with media_handle_sideload and add_metadata. As we are not in the wp-admin, because we do not need to, because that's just 2 servers talking to each other, no compressor is available and thus no tinification is happening. Which leads me to babysit all migrations because each time I have to check and manually optimize the images. Which I would like to avoid. I hope that helps you a little bit :) |
Making Tinify available outside wp-admin. For example if you sideload an image using an API or a frontend plugin (e.g. contact forms). No performance impact because compressor is only initialised if we actually have to process media, in which case we have to do quite heavy work anyway.