New to the community? Start here

[Smush Pro] Convert PNG with Transparency

0

Hi.
We´re in the testing of Smush and want to convert and optimize product feed images. Some of the product feeds work with PNGs and transparency inside. But there is no need to use the product images as PNG.
Are there plans to provide an option that converts these also in JPG – maybe with a background color selector?
Thx & Cheers / Sascha

Tue, 11 Feb 2020 15:03:42
More Smush Pro discussions
Smush Pro
  • Patrick Cohen
    • Technical Docs Wrangler

    Hi there Sascha

    There are no plans to support converting transparent PNG to JPG as the JPG format does not support transparency. :slight_smile:

    And no, I’m not aware of any plans to support transparent PNG at all; they are simply ignored by Smush.

    So if you have transparent PNG images that you’d like to optimize or convert to JPG with any solid background, you’d want to do that before uploading them using either any image optimization software you may have installed on your computer, or try an easy online tool like this one:
    https://tinypng.com/

  • Sascha
    • WPMU DEV Initiate

    Hi guys.

    Thanks for Your support!

    We don´t need transparency in JPGs – also I´m aware that this isn´t possible by the nature of JPGs.

    We work with datafeeds that have hundreds / thousands of product-images in it. Some brands deliver these as PNGs with transparency. But there is no need for our site to keep them. For our case it´s also no option to run them through another tool like ‘tinypng’ or convert them ‘by hand’.

    So – the filter code You send is very welcome! Where is the best place (or only) to place this line?

    And by using it – Smuh will put a white background in it by default?

    Best regards / Sascha

  • Adam
    • Support Gorilla

    Hi Sascha

    So – the filter code You send is very welcome! Where is the best place (or only) to place this line?

    The simplest way would be to add it to the “functions.php” file of the currently active theme (perferably if it’s a child theme) so you can add it there at the bottom.

    Alternatively, you can add it as an mu plugin too (so it will not depend on the theme and won’t stop working when you switch theme):

    – create empty file with .php extension (e.g. “smush-png-jpg.php”:wink:
    – copy and past this code into it

    <?php 
add_filter( 'wp_smush_convert_to_jpg', '__return_true' );

    – save and upload to the “/wp-content/mu-plugins” folder on the server; if there’s no “mu-plugins” within “wp-content”, just create empty folder first.

    It will work both ways and yes, it will simply create solid background replacing transparency. I just tested it and in all my tests the background was black, though.

    Best regards,
    Adam

  • Sascha
    • WPMU DEV Initiate

    Hi Adam.
    Thx for Your time and help!
    I was afraid that it end with a black background. I guess You´ve no more out of the box ideas to get this with a white background? :thinking:
    Any chance to see such an option in the gui some day?
    Best regards / Sascha

  • Sascha
    • WPMU DEV Initiate

    Hi again.
    Hope it´s o.k. to post again with a followup problem.

    This all seem to work very well – but for some time now Smush converts the PNGs and then attach a ‘-1’ to all the thumbs / sizes. Like ‘holzkern-zwielicht-leadwood-gold-600×600-1.jpg’.
    All these images comes from a Woo product All Import feed.
    Any ideas why it´s acting like that?

    Of course Woo don´t find the sizes now. And Smush sets the status to ‘Not processed’. Trying to smush it by hand it sends back:
    Could not find ‘…/wp-content/uploads/2020/09/holzkern-zwielicht-leadwood-gold-600×600.png‘ – for sure because it´s not there anymore. It´s ‘holzkern-zwielicht-leadwood-gold-600×600-1.jpg‘ now.

    Cheers / Sascha

  • Predrag Dubajic
    • Support

    Hi Sascha,

    We haven’t received such reports so far, could provide us with support access to your site so we could have a closer look at your setup and check what might be going on?
    You can enable support access from WPMU DEV > Support > Support Access panel in your WP admin.
    You can find more details about granting support access here:
    https://wpmudev.com/docs/getting-started/getting-support/#chapter-5

    Please respond in this ticket once access is granted.

    Best regards,
    Predrag

  • Sascha
    • WPMU DEV Initiate

    Hi Predrag.
    I´ve opened the Support Access for You.
    Some details that may help. As said – we import products and their images only via WP All Import. This WP Installation is only for pre-processing all the product-feeds.
    For JPGs everything runs smooth. The described only happens for PNG converted images. And… we use the above supported code in the functions.php to convert transparent images and put a white background in it.
    To run another import via WP All Import use the following link and then choose ‘Holzkern . Mode / Schmuck’ (ID 9) as product feed:

    https://partner.faunt.de/wp-admin/admin.php?page=pmxi-admin-manage

    I´ve deleted all products in there so You get fresh products and images. But please be aware, the import can´t be done endless over and over again. It´s time restricted by Awin. The next try if needed should start after some hours.
    Let me know if You need further details.

    Thank You / Sascha

  • Adam
    • Support Gorilla

    Hi Sascha

    Thanks for explanation!

    I accessed your site to take a look at configuration but I didn’t try import yet as I’d like to ask something first.

    The way Smush saves image files (technically speaking) is by using WP core image editor. It’s using its “save” method so basically it’s just telling WordPress core to save the image. This “-1” part being added to the file name is “strangely familiar” :wink: I mean, it’s very similar to what WP does when e.g. you try to add second post with exactly the same title (it adds such number to the slug) or… upload the file of the very same name second time within the same year/month (when it goes to the same sub-folder in /wp-content/uploads/).

    My point is that it seems to be behave like it actually already had the file of such name. The process is supposed to override such file in case of optimization but here it seems like it’s actually behaving like it was “uploading a new one” rather than “updating” it.

    You mentioned that it’s happening for some time recently but it wasn’t happening before. Do you recall if it started to happen with one of Smush Pro updates (and if so, when it started – about?) or perhaps update of WP itself (or some other plugin or theme)?

    Could you also double-check permissions of the files – are they actually writable? I don’t mean upload folders because those surely are writeable as otherwise even those “-1” files wouldn’t be there but image files themselves.

    I just want to get better picture of the issue before we continue.

    Best regards,
    Adam

  • Sascha
    • WPMU DEV Initiate

    Hi Adam.

    Thanks for Your feedback!

    Yes – it really looks like what You have described. I try to answer Your questions and put my 50 cent to it:

    It´s really hard to say or remember when this started. My initial post here was a while ago and there was a break in our process. So I got back to this some weeks ago. What is sure about it:

    – It only happens with PNGs and it´s conversion to JPG
    – The conversion happens – the new file is a JGP not a PNG any more
    – The original size is fine – only the thumbs get this number attachment
    – With All Import and in the import process we give the images new names and SEO stuff like alt-text, etc. – what again works well with the JPG (and PNGs as well). So for me it don´t look like there is a problem in the renaming process that could cause this number attachment
    – What is some kind of strange because it converts – but in the media library the status shows ”Not processed’

    Could you also double-check permissions of the files – are they actually writeable? I don’t mean upload folders because those surely are writeable as otherwise even those “-1” files wouldn’t be there but image files themselves.

    Here I like to ask back… Does the process of PNG converting use any kind of temp-folder that could be affected for write permissions?

    To give You a picture I have also imported 50 products and You can find the images in the media library. I´ve deactivated 2 plugins that could affect the process – but there seems no conflict.

    Cheers / Sascha

  • Adam
    • Support Gorilla

    Hi Sascha

    Thanks for response and additional information!

    I checked the site again and I think I found something that might be relevant here.

    I was trying to find what could possibly be causing such kind of renaming if it’s not about duplicated filename. I didn’t find anything “wrong” with the site and nothing in Smush code that would seem relevant too. So I also reviewed import and found this option:

    Ändere die Dateinamen der Bilder zu

    being enabled in “Bilder” tab of import configuration, in its “SEO” sub-tab. There some “replacement” code in an option field there but also an explanation that says…

    Multiple image will have numbers appended, i.e. image-name-1.jpg, image-name-2.jpg

    This looks like closely related thing. I’m not much familiar with the import plugin and I’m not exactly sure how this option should work but I think you might want to look into it. It seems like this is related and if so such renaming would be happening “outside” of Smush or “core” WP “flow”.

    Best regards,
    Adam

  • Sascha
    • WPMU DEV Initiate

    Hi Andam.

    Sure – that´s looks closely. But…

    – We have a lot of productfeeds and in each we change the SEO stuff via WP All Import. There is no other feed with original JPGs that cause a problem.
    – Also actually I removed the SEO lines from the PNGs productfeed and gave it a test – with the same results
    – Deactivated the PNG conversion in SMUSH – but the code in functions.php did the conversion even then / good to know

    /**
    * Smush PNG to JPG – White Back
    */
    add_filter( ‘wp_smush_convert_to_jpg’, ‘__return_true’ );
    add_filter( ‘wp_smush_bg’, function( $color ) {
    return ‘ffffff’;
    } );

    – Removed the lines from functions.php – so there happens no conversion to PNGs

    And here it seems to happen. After that last step everything is like it should be. But we have optimized PNGs instead of JPGs. It looks like the failure is happen in the conversion.

    Are there any folders (temp) in use that could be write protected on our server for that process?

    Best & Thx / Sascha

  • Adam
    • Support Gorilla

    Hi Sascha

    Thanks for response!

    To make sure that I get that right: you have confirmed by testing that even with that SEO option enabled the “-1” is not added if you remove those custom lines from “functions.php”, right?

    These two lines do just two things: 

    add_filter( ‘wp_smush_convert_to_jpg’, ‘__return_true’ );

    Right above it there’s internal Smush function used “should_convert()” and that function checks if PNG conversion option is enabled in Smush settings and if yes, if image that’s about to be converted is transparent or not. If option is disabled or it’s enabled but image is transparent, it returns “false” telling Smush not do converstion.

    Then this line overrides result of that funciton so it just tells Smush to do PNG conversion “no matter what” – no matter if it’s enabled or disabled in plugin and if image is transparent or not. But that’s the only thing it does.

    This line then 

    add_filter( ‘wp_smush_bg’, function( $color ) {
return ‘ffffff’;
} );

    only overrides the color value in internal settings but, again, it doesn’t do anything else.

    My point is, these are “filters” and apart from changing some “values” (color, option true/false) they don’t really modify plugin’s “code” so that’s why I’m a bit surprised.

    Now, if you keep this first line it will still do conversion because it’s “hard-coding” PNG conversion option.

    I’m wondering about one thing, though, and it would be great if you could test it: set the all as it was (so the issue happens) but only remove this single line: 

     add_filter( ‘wp_smush_bg’, function( $color ) {
return ‘ffffff’;
} );

    As a result conversion should be happening and transparent PNGs should be converted and optimized, they just should have black background. But I’m wondering if there’ll still be that “-1” added or not then. The reason for my question is that I’m thinking if maybe it’s not really WP or Smush but something specific to the PHP/server library that’s used (imagick or GD, depending on server) for that, maybe there is some kind of “glitch” or “quirk” that we’re not aware of.

    One way or another, I’ll bring it again to our developers for consultation but if you could first, please, test that and let me know about results, it would be great!

    Best reagrds,
    Adam

  • Sascha
    • WPMU DEV Initiate

    Good Morning Adam.

    To make sure that I get that right: you have confirmed by testing that even with that SEO option enabled the “-1” is not added if you remove those custom lines from “functions.php”, right?

    With this setup:
    – no lines in the funtions.php
    – PNG conversion activated in SMUSH
    – SEO lines in All Import set

    Result:
    PNGs with the right SEO names, etc. – because the PNGs have transparency they won´t be converted.

    As a result conversion should be happening and transparent PNGs should be converted and optimized, they just should have black background. But I’m wondering if there’ll still be that “-1” added or not then.

    This is kind of strange! All is set as You explained. The line…

    add_filter( ‘wp_smush_convert_to_jpg’, ‘__return_true’ );

    is in functions.php. Auto-convert is active in SMUSH but… no conversion happens. Tested it 2 times. Always receive still PNGs?!?

    Here You find our functions.php : https://own.faunt.de/s/GSuvIME46aCT1Jt

    Was there any change in the last update of SMUSH?

    Best & Thx / Sascha

  • Adam
    • Support Gorilla

    Hi Sascha

    Thanks for response!

    I think you might want to repeat the test, just in case, because there’s an error in your functions.php in that smush line:

    add_filter( ‘wp_smush_convert_to_jpg’, ‘__return_true’ );

    It should be

    add_filter( 'wp_smush_convert_to_jpg', '__return_true' );

    I think the difference might not be easy to notice above so the point is that should be “straight apostrophes” (not sure what’s the proper word in English) instead of “single quotes” (those “skewed” ones) around both wp_smush_convert_to_jpg and __return_true

    That makes a different as the way it is now it should actually generate some error (which might not be visible on site; it might be going into debug.log or error_log instead) and essentially it makes this line not work at all.

    But if that doesn’t make a difference then you actually might be right about update. There’s nothing that is “supposed” to cause that “-1” issues “on purpose” in last updates but I can’t rule out that it’s some sort of a “side effect” so it might, indeed, be worth testing older version.

    I’d skip the previous update and test with one before last version which you can download from this link:

    https://wpmudev.com/download/smush-pro-3.6.3.zip

    If it works fine again with that version then we know that you’re right and it’s related to one of last two updates. In such case, update plugin by one version (to 3.7) and test again. If starts to fail we know it’s 3.7 update. If it’s still fine, we know it’s the last update.

    Best regards,
    Adam

  • Sascha
    • WPMU DEV Initiate

    Hey Adam.

    I took some days to test it.

    To keep things short. With the SMUSH version downgrade and an active cronjob that imported the products this night we recieve JPGs with black background as it shold be.

    But… All thumbnails also have the initial issue ‘-1’ attached.

    I will now give this a testdrive on a WP All Import sandbox version. Let´s see if this happens in combination with WP All Import.

    Stay tuned for my next message…

    Best / Sascha