I didn’t know this. Thanks for the info.
Well, that settles it then. If @alvarofranz will use built in hooks so that the uploaded images get basic optimization, then this petition gets my vote.
1 Like
I was going to ask how… and found this Does WordPress automatically compress images? Image resizing tips. - WP Website Tools
Outrageous if you ask me. As if somehow this would improve anything in respect to speed.
Anyway, learned a new favorite filter to use from now on lol
2 Likes
With regard to image, jpg, compression. If you upload a correctly sized picture, (height and width) at a compression of 70% you would generally not see any degregation (there will always be rare execptions).
The only real reason to save at 100% is if you are going to be doing further editing as compression errors are cumulative, and if you are editing images you are unlikely to be using jpg anyway. I would do edits in png and export at the apropriate format, size and quality for the application
If you are using for example a 1920 x 560 header image with overlay text the visitor will be reading the text not admiring the image. So a 100% quality image uploaded, compressed by wordpress, could still be 1meg or more, optimally compressed this might only be 70k this makes a huge difference in the load time for the page with no disernable difference to the site visitor…
CP creates several ,4, copies of an uploaded images, themes and page builders can add several more.
So uploading a 2Mb image could use up 20Mb of storage on your server.
Many servers will compress images as there serve them, as will most caching and optimising plugins.
So if you upload an optimally sized and compressed image, using photoshop, fireworks,gimp, etc. at say 75% (or less) this is going to be least affected (abused) by CP, your server, optimising plugins etc. and be fast to load.
Uploading an image of the quality and size that you could print out for a wall could actually end up looking bad when displayed on a mobile or desktop monitor and be very slow to load.
I was not aware of that. Thanks! Good thing I always stick to SVGs!
Photos should be stored as JPEG since that’s what that format is specifically for: compressing real-life images in a way that does not make them look significantly worse to the human eye.
Screenshots and any other image that is supposed to contain large stretches of exactly the same color with sharp edges (for example, computerized drawings) should never be compressed with JPEG. They will look terrible and these should be uploaded as .png instead. They will compress well and this is what the PNG image format is for.
What if you make a meme that is based on a photo but has sharp-edged text? Should this be stored as JPEG or PNG?
I don’t see how a computer can make that decision.
Clipboard images can be in different formats. It is not always obvious how to do so, but I can choose to copy an image to the clipboard in JPG or PNG format. @alvarofranz under your current code, is the clipboard’s image format (MIME type) respected when pasting and uploading?
1 Like
Yes, sir. Getting 'em as blob. Sending 'em as files via Ajax. So, MIME Type is respected.
1 Like
Ok, great 
Why do you think this is a waste of time?
Anyway the other option would be to send this as a PR against the current version of ClassicPress.
1 Like
More than a waste of time it feels like a waste of energy, cuz I have to go read documentation for an old version of TinyMCE, to check what needs to be done differently. This section in the Tiny v4 docs talks about editor events.
In this case it’s just a minor difference but it drains my energy. I just want to make stuff work on modern technology. If there is a v5 I don’t want to have to deal with v4. The ClassicEditor Research plugin seems like a good place to add this because I won’t have to make adjustments for v4. It is the place where the next CP editor is being cooked, so yeah, it’s a good place to throw that feature in.
Thanks for your attention. I will keep working on this since I am using it (CP and the research editor), and I will be happy to PR that if it’s okay. And not PR if it’s not okay
I’ve worked on compatibility on 2 of my plugins with Tiny v5. Mainly there are changes dealing with buttons. So it’s pretty easy to tweak the code to make it work with both versions.
function myprefix_is_mce_5() {
global $tinymce_version;
return isset($tinymce_version) && substr($tinymce_version, 0, 1) === '5';
}
1 Like
I can see that you don’t want to make a plugin, because you don’t want to do maintenance.
There isn’t a v5 yet.
And I won’t accept a PR to the update plugin for a new editor feature, since it’s out of scope. (If it’s in core, I’ll have to adjust the update plugin to handle it, though.)
1 Like
That’s fair
But yeah, nothing to do with maintenance. I just don’t care about T v4. I will maintain it in the sense that I will use it on a daily basis and fix if something is not as it should.
I will keep working on it and we can implement it once the work on T v5 is done. So no more words about that. Peace, love, and chill forwards.
Do you have an estimated time to completion for v5 transition?
1 Like
The problem with this - as I see it, at least - is that TinyMCE v4 is what is available to the whole ClassicPress community today. So by far the quickest path available to get this working and available to everyone is to make it work with v4.
Still, if you want to keep this working only on v5, then that’s fine. Please do post your code somewhere though, so that we can see how it works and someone else can pick it up for v4 if desired!
In the broader open-source community it is common to encourage people not to ask for deadlines, especially for smaller projects where everyone working on it is a volunteer and the scope of work required is not always well-defined. I think we should adopt that mindset and expectation with ClassicPress as well.
2 Likes
Great! Will do
Great idea too! Let’s do that
I’m testing tiny 5, enriched editor, tiny 4.9.11 and 2 of my plugins that add buttons to the editor on 2 sites (one production and one with the develop branch of CP). If you publish i can add it to my test.
Really I’m very bad with JS but I can try to help with tiny 4 compatibility.
1 Like
You can see the currently available version published here.
I still have to work on attachments as @viktor proposed and copying the image directly from the “screenshot to clipboard tool”. Currently only works by directly copying the file from the system.
The positive side of merging this into the current research plugin is that I can work on this without interfering with the other tasks at all. But yeah if that’s not an option, I’ll keep it updated in the forked repo.
2 Likes
Are you planning to make it a standalone plugin (without the whole editor)?
1 Like
No. This is just something that I want to see added to the core TinyMCE v5 editor. Not as a plugin. It’s a basic feature that some users expect to have when using a WYSIWYG editor.
This petition will be closed but you can monitor its progress on GitHub:
This topic was automatically closed after 3 days. New replies are no longer allowed.