Viewing 26 posts - 1 through 26 (of 26 total)
  • Author
    Posts
  • #1070394

    Hi Enfold team, thanks for a truly great theme! Impressive work!

    A question for the Team and a little explanation from me which may help other people on Enfold. As I’ve seen many people on this (and other forums) confused on how to deal with retina/non-retina images.

    I am happy to see that Enfold has taken the same approach I favour for catering to retina screens: upload double-size and let the theme/browser do the downscaling as needed.

    I basically treat images this way in WP:
    – create double-size true width/height
    – save them in Photoshop “save for web” with between 30 and 20% quality
    – run all images through FileOptimizer before upload
    – set WP compression to between 90 and 100
    – set thumbnails in theme functions.php to double-size and regenerate thumbs
    – run all thumbs from WP through FileOptimzer locally and re-upload through FTP

    My question to you:
    Do I need to manually double the sizes of the thumbs in the (child)theme’s function.php for the thumbnails or have your already done this? I would not want to make the thumbs 4x as big as needed :-)

    For Enfold users wondering about the why of this approach:

    Content images in a responsive template have different requirements compared to the traditional “this-is-the-width” approach. But all present attempts to serve up different image sizes to different devices, whether client-side or server-side, are incomplete at best and based on wrong assumptions at worst (apart from most of them not being standards compliant). Including the src-set approach favoured by WP and the plugin Retina approach. Why?

    These factors make the traditional (src-set) approach invalid:
    – the same content image is wider when there is no sidebar present
    – content images in widgets change width on various smaller screens
    – content images in sidebars change width on various smaller screens
    – high resolution / retina screens need a 2x larger image to be sharp
    – smaller screen widths may have higher resolution screens
    – users may always zoom in on each page (on desktop, tablet and phone)

    So we need to serve up much larger images in order to cater for the above. But we have no way of knowing in advance which device has which screen resolution with which layout and which zoom. At present the best solution in my opinion is therefore to serve up one large image and to let the browser do the scaling for us (modern browsers have become quite good at this). Yes, even for phones/tablets.

    This does not mean we need to bother our visitors with large image sizes, more data consumption and slower loading pages.
    High Resolutin/Retina images aren’t necessarily larger files, at least not with JPEGs. Since you have four times as many pixels with a twice larger size, you can get away with a great deal more compression, and the end result is sometimes even smaller than the original. A 400x400px image at 40% quality may appear no more heavily compressed than a 200x200px image at 80% quality, yet may be the same or smaller file size.

    By having a 2x larger image and then scaling down in the browser, it has the effect of reducing the jpeg compression from 8×8 squares to 4×4 squares (giving the compression 64 pixels to work with instead of 16) on standard monitors – even at high compression. This “false resolution” hides the increased numbers of jpeg artifacts. On retina screens the artifacts would double with a traditional size image scaled up.

    This is an interesting and extensive research article showing this option for dealing with highres images:
    https://www.netvlies.nl/tips-updates/algemeen/design-interactie/retina-revolution/

    Basically, it’s saying that, if you make the image quite large (width and height), but then save it at quite low quality, it still comes out very sharp on retina displays. It means that you can use the one same image on all devices, and that  the file size is very low, too, which is an extra bonus. You can set the width (with the height set to auto) of the image in the CSS to get the dimensions needed.

    This is currently my approach for dealing with both retina-friendly and bandwidth-friendly images.

    Example with a test photo with many details:
    Traditional: test-600x375px – 80% quality – size = 87KB
    Retina-friendly: test-1200×750 – 40% quality – size = 96KB
    Retina-friendly: test-1200×750 – 30% quality – size = 79KB
    Retina-friendly: test-1200×750 – 20% quality – size = 67KB

    Usually 30% quality “save for web” in Photoshop is quite enough for a double-sized (retina) image to remain sharp. And many times even 20% quality will work just fine. Try it out yourself.

    For Enfold users on Windows, may I suggest a great tool for (loslessly) compressing PNG and JPG (and many other formats) even further before uploading?

    FileOptimizer
    website: https://nikkhokkho.sourceforge.net/static.php?page=FileOptimizer

    #1072021

    Hi Enfold Team, I tested this out in hte meantime but am baffled by the results :-)
    Can you help me understand?

    I doubled the thumb sizes in the child theme functions.php:

    // – set WordPress compression of image and thumbnails on upload and resize to 90 or higher
    // images are manually resized, compressed and optimized BEFORE upload already
    // WP compression on images on resize/for thumbnails is standard = 82
    add_filter(‘jpeg_quality’, function($arg){return 90;});

    // remove “responsive images” srcset functionality in WP 4.4 and on from this theme
    remove_filter( ‘the_content’, ‘wp_make_content_images_responsive’ );

    // double-size thumbs for Retina screens and zoom
    $avia_config[‘imgSize’][‘widget’] = array(‘width’=>72, ‘height’=>72); // small preview pics eg sidebar news – ORG 36 x 36
    $avia_config[‘imgSize’][‘square’] = array(‘width’=>360, ‘height’=>360); // small image for blogs – ORG 180 x 180
    $avia_config[‘imgSize’][‘featured’] = array(‘width’=>3000, ‘height’=>860); // images for fullsize pages and fullsize slider – ORG 1500 x 430
    $avia_config[‘imgSize’][‘featured_large’] = array(‘width’=>3000, ‘height’=>1260); // images for fullsize pages and fullsize slider – ORG 1500 x 630
    $avia_config[‘imgSize’][‘extra_large’] = array(‘width’=>3000, ‘height’=>3000, ‘crop’ => false); // images for fullscrren slider – ORG 1500 x 1500
    $avia_config[‘imgSize’][‘portfolio’] = array(‘width’=>990, ‘height’=>800); // images for portfolio entries (2,3 column) – ORG 495 x 400
    $avia_config[‘imgSize’][‘portfolio_small’] = array(‘width’=>520, ‘height’=>370); // images for portfolio 4 columns – ORG 260 x 185
    $avia_config[‘imgSize’][‘gallery’] = array(‘width’=>1690, ‘height’=>1368); // images for portfolio entries (2,3 column) – ORG 845 x 684
    $avia_config[‘imgSize’][‘magazine’] = array(‘width’=>1420, ‘height’=>750); // images for magazines – ORG 710 x 375
    $avia_config[‘imgSize’][‘masonry’] = array(‘width’=>1410, ‘height’=>1410, ‘crop’ => false); // images for fullscreen masonry – ORG 705 x 705
    $avia_config[‘imgSize’][‘entry_with_sidebar’] = array(‘width’=>1690, ‘height’=>642); // big images for blog and page entries – ORG 845 x 321
    $avia_config[‘imgSize’][‘entry_without_sidebar’]= array(‘width’=>2420, ‘height’=>846); // images for fullsize pages and fullsize slider – ORG 1210 x 423
    $avia_config[‘imgSize’] = apply_filters(‘avf_modify_thumb_size’, $avia_config[‘imgSize’]);

    Save and regenerate thumbs.
    But then I watch the regenerated thumbnails and they seems to be back to the standard sizes.
    These are the currently registered thumbnail sizes, whether they exist for this attachment, and their filenames:

    thumbnail: 80×80 pixels (cropped to fit)
    medium: 300×300 pixels (proportionally resized to fit inside dimensions)
    medium_large: 768×0 pixels (proportionally resized to fit inside dimensions)
    large: 1030×1030 pixels (proportionally resized to fit inside dimensions)
    widget: 36×36 pixels (cropped to fit)
    square: 180×180 pixels (cropped to fit)
    featured: 1500×430 pixels (cropped to fit)
    featured_large: 1500×630 pixels (cropped to fit)
    extra_large: 1500×1500 pixels (proportionally resized to fit inside dimensions)
    portfolio: 495×400 pixels (cropped to fit)
    portfolio_small: 260×185 pixels (cropped to fit)
    gallery: 845×684 pixels (cropped to fit)
    magazine: 710×375 pixels (cropped to fit)
    masonry: 705×705 pixels (proportionally resized to fit inside dimensions)
    entry_with_sidebar: 845×321 pixels (cropped to fit)
    entry_without_sidebar: 1210×423 pixels (cropped to fit)
    shop_thumbnail: 100×100 pixels (cropped to fit)
    shop_catalog: 300×300 pixels (cropped to fit)
    shop_single: 600×0 pixels (proportionally resized to fit inside dimensions)
    woocommerce_thumbnail: 300×300 pixels (cropped to fit)
    woocommerce_single: 600×0 pixels (proportionally resized to fit inside dimensions)
    woocommerce_gallery_thumbnail: 100×100 pixels (cropped to fit)

    Thanks in advance for your help (I see you’re a bit flooded with help requests now…)

    • This reply was modified 5 years, 7 months ago by rob2701.
    #1072095

    Follow-up:
    Same changes made in parent theme’s functions.php > thumbnails sizes become the way I set them
    Same changes made in child theme’s functions.php > thumbnails sizes stay what is orginally set in the parent theme and do not change the way they should (respecting the child theme’s functions.php).
    Can you help me understand why and provide a solution? Thanks in advance.

    #1072406

    After some more testing, thinking and testing:

    1.
    Changes to the thumbs array in the child theme DO work. I must have done something wrong last time. Sorry.

    2.
    After a bit of thought I’ve decided that its much more efficient for me to do the exact double-size high compression images by hand and then upload.
    While it’s nice to have the theme automatically do resizing and cropping, it just results in much heavier images, most of which I will not use anyway..

    3.
    I have commented out all thumbnails sizes in the child theme functions.php therefore..
    Thus regenerating thumbs loses all other sizes (except the WP ones for the Media Library).
    Going to try just using the full size original and having the theme CSS do downscaling.

    You can mark this topic as solved. I hope. Unless I’ve made a wrong assumption somwhere down the line :-)

    #1072580

    Hi,

    Thank you for using Enfold.

    It looks about right. Have you tried using the “avf_modify_thumb_size” filter to override the default image sizes?
    Usage example can be found here: https://kriesi.at/support/topic/vertical-alignment-of-gallery-images/#post-1066343

    Best regards,
    Ismael

    #1072660

    Hi Ismael,

    Thanks for the response and the tip, will look into it. Still getting to know the theme, so one step at a time :-)

    Regards,
    Rob

    #1073150

    Hi,

    You’re welcome. Please don’t hesitate to contact us if you need further assistance. We’ll keep the thread open.

    Best regards,
    Ismael

    #1077293

    hI,
    For anyone interested in follwoing the same route as me to serve up double-size retina images with high compression to all devices, here’s what I did.

    functions.php in child theme:

    // remove "responsive images" functionality in WP 4.4 and higher
    add_filter('wp_get_attachment_image_attributes', function($attr) {
       if (isset($attr['sizes'])) unset($attr['sizes']);
       if (isset($attr['srcset'])) unset($attr['srcset']);
       return $attr;
    }, PHP_INT_MAX);
    add_filter('wp_calculate_image_sizes', '__return_false', PHP_INT_MAX);
    add_filter('wp_calculate_image_srcset', '__return_false', PHP_INT_MAX);
    remove_filter('the_content', 'wp_make_content_images_responsive');
    
    // Disable loads of Enfold & WP image sizes upon upload
    // do image sizes manually, double-size with high compression for retina screens
    // use Photoshop to set exact double size and quality between Q30 and Q40
    add_action('init', 'remove_enfold_image_sizes');
    function remove_enfold_image_sizes() {
    // do NOT remove widget size, is used in backend portfolio items!
    // remove_image_size('widget');
    	remove_image_size('square');
    	remove_image_size('featured');
    	remove_image_size('featured_large');
    	remove_image_size('portfolio');
    	remove_image_size('portfolio_small');
    	remove_image_size('gallery');
    	remove_image_size('magazine');
    	remove_image_size('masonry');
    	remove_image_size('entry_without_sidebar');
    	remove_image_size('entry_with_sidebar');
    	remove_image_size('shop_thumbnail');
    	remove_image_size('shop_catalog');
    	remove_image_size('shop_single'); 
      remove_image_size('shop_gallery_thumbnail');
    }
    // Remove unneeded WP image sizes
    add_filter( 'intermediate_image_sizes_advanced', 'prefix_remove_default_images' );
    // Remove default image sizes here. 
    function prefix_remove_default_images( $sizes ) {
    // do NOT remove small and medium sizes, they are used in backend Media Library!
    // unset( $sizes['small']); // 150px
    // unset( $sizes['medium']); // 300px
     unset( $sizes['large']); // 1024px
     unset( $sizes['medium_large']); // 768px
     return $sizes;
    }

    List of Enfold/TopMenu image sizes for different image ratios:

    w = standard width Enfold
    Rw = doubled Enfold width for Retina
    GR = Golden Ratio

    ENFOLD WITH Top menu
    
    full width header banner frontpage
    w 1519 x 430 / Rw 3040 x 860
    >>>>> USE:
    4:1 > 3000 x  849
    
    news featured
    w 81 x 81 / Rw 162 x 162
    >>>>> USE:
    1:1 > 180 x 180
    1:1 > 360 x 360
    
    portfolio 2 column featured
    w 758 / Rw 1516
    >>>>> USE:
    4:3  > 1600 x 1200
    3:2  > 1600 x 1067
    16:9 > 1600 x  900
    GR   > 1600 x  991
    
    portfolio 3 column featured
    w 507 / Rw 1014
    >>>>> USE:
    4:3  > 1024 x  768
    3:2  > 1024 x  683
    16:9 > 1024 x  576
    GR   > 1024 x  624
    
    portfolio 4 column featured
    w 378 / Rw 756
    >>>>> USE:
    4:3  >  800 x  600
    3:2  >  800 x  533
    16:9 >  800 x  450
    GR   >  800 x  496
    
    portfolio single full width
    w 1419 / Rw 2838
    >>>>> USE:
    4:3  > 3000 x 2250
    3:2  > 3000 x 2000
    16:9 > 3000 x 1688
    GR   > 3000 x 1858
    
    portfolio single 2/3
    w 918 / Rw 1836
    >>>>> USE:
    4:3  > 1920 x 1440
    3:2  > 1920 x 1280
    16:9 > 1920 x 1080
    GR   > 1920 x 1189
    
    portfolio single 3/4
    w 1043 / Rw 2086
    >>>>> USE:
    4:3  > 2500 x 1875
    3:2  > 2500 x 1667
    16:9 > 2500 x 1406
    GR   > 1920 x 1549
    
    gallery with right sidebar
    w 986 / Rw 1972
    >>>>> USE:
    4:3  > 2000 x 1500
    3:2  > 2000 x 1333
    16:9 > 2000 x 1125
    GR   > 2000 x 1239
    
    store multi product
    w 320 / Rw 640
    >>>>> USE:
    4:3  >  640 x  480
    3:2  >  640 x  427
    16:9 >  640 x  360
    GR   >  640 x  396
    
    store single product 1/2
    w 667 / Rw 1334
    >>>>> USE:
    4:3  > 1440 x 1080
    3:2  > 1440 x  960
    16:9 > 1440 x  810
    GR   > 1440 x  892
    
    5 column featured
    w 216 / Rw 432
    >>>>> USE:
    4:3  >  480 x  360
    3:2  >  480 x  320
    16:9 >  480 x  270
    GR   >  480 x  297
    
    3/5 of page
    w 817 / Rw 1634
    >>>>> USE:
    4:3  > 1800 x 1350
    3:2  > 1800 x 1200
    16:9 > 1800 x 1013
    GR   > 1800 x 1115
    #1077685

    Hi Rob,

    Great, I’m glad that you came up with a solution, and thanks a lot for sharing it!

    Best regards,
    Rikard

    #1125163

    Dear Rob (or Kriesi team),
    thanks a lot for sharing your solution – but still I don’t get the why and how…
    I also have problems with Enfold and image load times and retina displays and I am not sure if I understood your solution right:

    • –> so you disable Enfold from uploading different sizes of images and also WP from creating the three standard sizes
    • –> you deactivate the “responsive images functionality” from WP –> WHY?
    • –> you just look which sizes you need for which area (portfolio, masonry, gallery and so on) and upload the correct Retina size (in width and height) which you prepare with high compression
    • –> in the End, it will always be used this same image no matter if Retina or not, right?

    Sorry, but I really would love to use your solution if it works and results in less loading time and good image quality on Retina, but still I am not sure.
    And also, if I do all of this, when already created a site before –> what will happen to it? hopefully it won’t break and I just would have to select images again?

    Thanks, Tanja

    #1125172

    Dear team Kriesi,

    looking into my pictures more in detail I think a realized, that the image sizes created from Enfold really result in way bigger sizes than the original uploaded image is…!? Also if the image in width and height is originally smaller, the created image of Enfold results in more KB… Can that be true?

    If so, maybe you can up with a solution to avoid this explained in detail (also using Robs input) – I think this is of interest for many Enfold users…

    Thanks, Tanja

    #1125426

    Hi Tanja,
    The whole idea about my solution is to serve up ONE high resolution image to all devices, but to make that image bigger with higher compression (for retina screens and zooming sharpness). This is because on all modern devices images can be zoomed (enlarged), so the “traditional” way of serving smaller images to certain devices would result in blurry images when enlarged or when viewd on retina/high resolution screens.
    That is why I chose to disable the WP responsive images solution and disable the same approach used by Enfold.
    See https://www.netvlies.nl/tips-updates/algemeen/design-interactie/retina-revolution/ for the background on this.

    To take this approach you need to MANUALLY upload the correct size and resolution for each image on that particular page, using Photoshop or similar.

    When you start this on an already existing site the code changes will ONLY affect NEW uploads, i.e. newly uploaded images will not get all of those resized thumbnails created.
    You can then (at your own pace) start to replace the existing images with the new accurately sized ones. I recommend a plugin like “Enable Media Replace” to make this process less “painful”.
    Once you have replaced all existing images with new precisely sized ones, you can then use a plugin like “Regenerate Thumbnails” to recreate the proper thumbnail sizes (without all the additional ones) and get rid of all previously created, now unneeded, thumbnail sizes to save space on the server.

    I have been using this method for several years now, and I am completely happy with both the loading speed and the image quality even when zoomed.

    So try it out and see if it works for you. Hope this helps.

    Regards,
    Rob

    #1125452

    Dear Rob,

    thank you very much again for the explanations!
    I tried your solution know just for one header image and I really have to say it works awesome!

    The only thing now I don’t completely understand and where I would appreciate your input: how do you handle this with masonry gallery or other galleries? I mean the thumbnails before the picture is openend in the lightbox after clicking on it would always have the original size, right? Also, if the thumbnail image container is lets say just 200px width, it would load the big original size?

    Or do you have a solution for that?

    Thanks again, Tanja

    #1125481

    Hi Tanja,
    The images for the gallery are two different ones: one for the preview (the thumbnails), one for the originals (full size).
    Same for shop product previews and full sizes.
    For example:
    I name the ones for the preview strip (example, ftd means featured from featured image):
    <imagename>-ftd-800×533-q30.jpg
    and the ones for the full view:
    <imagename>-1920×1280-q30.jpg
    to distinguish between them in the Media Library.
    The browser takes care of relatively adjusting the relative sizes from the originals in other cases.
    Hope that clears it up.
    Kind regards,
    Rob

    In other words, the principle is always the same: double the actual size with high compression.
    Consult the list above to see the actual pixel sizes for the type of page you create the image for.

    • This reply was modified 5 years, 2 months ago by rob2701. Reason: added some info to clarify
    #1125526

    Hi Rob,
    thanks again.

    So I understand, that there are those two different types of images for the gallery (thumbnail and fullsize). But my question is, how do I tell the system to take the thumbnail picture for the preview strip and the fullsize image for the lightbox?

    Or are you saying, that the browser then decides which one to use and loads the smaller one for thumbnail automatically?

    I mean if I create the Mansonry gallery, I only have the option to choose one image for the gallery and no possibility to distinguish between thumbnail image and fullsize image…

    Aaaah! Or I just select the images in preview size in Masonry gallery and then link each of this pictures to the one in full size in the gallery settings? Is that what you mean??

    Sorry, again…
    Kind Regards, Tanja

    #1125567

    Hi Tanja,
    The featured images setting works only on the portfolios of course.
    For the galleries you just upload the originals and choose for example small thumbnails and “No Scaling”.
    The browser will resize the images for the preview strip from the original and open the original size in the lightbox.
    Just experiment.
    Kind regards,
    Rob

    #1125699

    Ok, thanks, that’s what I meant… In this case, the browser only resizes the images for previews, but still loads the original size I guess.
    Thank you Rob,
    Kind regards,
    Tanja

    #1125948

    Hi Tanja,
    I understand you may be a little worried at the cost of a little more image weight using the non-scaled images also for the preview strip in the galleries…
    You can always try to add one of the size which Enfold recommends in the dropdowns then, of course.
    But I wouldn’t worry about it too much though, that’s why I suggested using the “no scaling” option for the galleries.
    You see, that way the full images to be opened in the lightbox on click are already loaded on the page itself (check the page source), so it saves quite a few extra http requests at the cost of a little more image weight. What you lose on the swings you gain on the roundabouts :-)
    Kind regards,
    Rob

    #1128488

    Hi,
    Rob, thanks again for sharing your solution and explaining, this makes a lot of sense.

    Best regards,
    Mike

    #1214447

    Hi there, I’ve been trying to implement your solution on my website. And I must say I really love it how you approach the problem of duplicated files on your server. That being said, when I use your code, only some thumbnails are removed. Basically those defined by Enfold. But the WordPress registered images sizes are still there. I’m using the Enfold child theme and I have copied your code on the functions.php file.

    Any ideas of why only the image sizes defined by Enfold are removed but not the ones defined by WordPress? Here’s a screenshot of the plugin Regenerate Thumbnails where you can see the currently registered thumbnails:

    Image 2020-05-19 at 10.37.49 PM.png

    And here’s the current code I’m using, just in case it helps:

    // remove “responsive images” functionality in WP 4.4 and higher
    add_filter(‘wp_get_attachment_image_attributes’, function($attr) {
    if (isset($attr[‘sizes’])) unset($attr[‘sizes’]);
    if (isset($attr[‘srcset’])) unset($attr[‘srcset’]);
    return $attr;
    }, PHP_INT_MAX);
    add_filter(‘wp_calculate_image_sizes’, ‘__return_false’, PHP_INT_MAX);
    add_filter(‘wp_calculate_image_srcset’, ‘__return_false’, PHP_INT_MAX);
    remove_filter(‘the_content’, ‘wp_make_content_images_responsive’);

    // Disable loads of Enfold & WP image sizes upon upload
    // do image sizes manually, double-size with high compression for retina screens
    // use Photoshop to set exact double size and quality between Q30 and Q40
    add_action(‘init’, ‘remove_enfold_image_sizes’);
    function remove_enfold_image_sizes() {
    // do NOT remove widget size, is used in backend portfolio items!
    // remove_image_size(‘widget’);
    remove_image_size(‘square’);
    remove_image_size(‘featured’);
    remove_image_size(‘featured_large’);
    remove_image_size(‘portfolio’);
    remove_image_size(‘portfolio_small’);
    remove_image_size(‘gallery’);
    remove_image_size(‘magazine’);
    remove_image_size(‘masonry’);
    remove_image_size(‘entry_without_sidebar’);
    remove_image_size(‘entry_with_sidebar’);
    remove_image_size(‘shop_thumbnail’);
    remove_image_size(‘shop_catalog’);
    remove_image_size(‘shop_single’);
    remove_image_size(‘shop_gallery_thumbnail’);
    remove_image_size(‘1536×1536’);
    remove_image_size(‘2048×2048’);
    remove_image_size(‘shop_single’);
    remove_image_size(‘extra_large’);
    //remove_image_size( ‘large’ );

    }
    // Remove unneeded WP image sizes
    add_filter( ‘intermediate_image_sizes_advanced’, ‘prefix_remove_default_images’ );
    // Remove default image sizes here.
    function prefix_remove_default_images( $sizes ) {
    // do NOT remove small and medium sizes, they are used in backend Media Library!
    // unset( $sizes[‘small’]); // 150px
    // unset( $sizes[‘medium’]); // 300px
    unset( $sizes[‘medium_large’]); // 768px
    //unset( $sizes[‘large’]); // 1030px

    return $sizes;
    }

    Thanks so much for your help.

    #1214506

    Hi dgvicario,

    There have been some changes since then to WP and some additions also by me for some things.
    Below is what I now have in my child theme’s functions.php regarding images and thumbnails:

    // set WordPress compression of image and thumbnails on upload and resize to 90 or 95
    // images are manually resized, compressed and optimized BEFORE upload already,
    // WP compression on images on resize/for thumbnails is standard = 82
    add_filter('jpeg_quality', function($arg){return 95;});
    
    // disable image scaling in WordPress 5.3 update (november 2019)
    // WP added feature that forces images to scale down if larger than threshold (2560px)
    // this interferes with chosen approach for retina images, i.e. serving up
    // double-size images with very high compression...
    add_filter( 'big_image_size_threshold', '__return_false' );
    
    // remove "responsive images" functionality in WP 4.4 and on from this theme
    add_filter('wp_get_attachment_image_attributes', function($attr) {
       if (isset($attr['sizes'])) unset($attr['sizes']);
       if (isset($attr['srcset'])) unset($attr['srcset']);
       return $attr;
    }, PHP_INT_MAX);
    add_filter('wp_calculate_image_sizes', '__return_false', PHP_INT_MAX);
    add_filter('wp_calculate_image_srcset', '__return_false', PHP_INT_MAX);
    remove_filter('the_content', 'wp_make_content_images_responsive');
    
    // Disable WordPress responsive srcset images
    add_filter('max_srcset_image_width', create_function('', 'return 1;'));
    
    // Disable theme thumbnail creation, will do image sizes manually
    // double-size thumbnails for retina screens
    // so we do not use the automatically resized and cropped thumnails from the theme
    // better to create them manually proper size and image compression
    // use Photoshop to set exact double size and quality between Q10 and Q40
    
    // Disable loads of Enfold & WP image sizes upon upload (to save space)
    add_action('init', 'remove_enfold_image_sizes');
    function remove_enfold_image_sizes() {
    // do NOT remove widget size, is used in backend portfolio items!
    // do NOT remove square size, is used in backend portfolio and previous/next buttons!
    //	remove_image_size('widget');
    //	remove_image_size('square');
    	remove_image_size('featured');
    	remove_image_size('featured_large');
    	remove_image_size('portfolio');
    	remove_image_size('portfolio_small');
    	remove_image_size('gallery');
    	remove_image_size('magazine');
    	remove_image_size('masonry');
    	remove_image_size('entry_without_sidebar');
    	remove_image_size('entry_with_sidebar');
    	remove_image_size('shop_thumbnail');
    	remove_image_size('shop_catalog');
    	remove_image_size('shop_single');
        remove_image_size('shop_gallery_thumbnail');
    }
    
    // Remove unneeded WP image sizes
    // updated 2020-01-13 because of additional image sizes
    function remove_default_image_sizes( $sizes) {
      unset( $sizes['thumbnail']); // 80px thumbnail
      unset( $sizes['small']); // 150px thumbnail - (Size based on Media setting)
      unset( $sizes['medium']); // 300px - (Size based on Media settings)
      unset( $sizes['medium_large']); // 768 - (Size based on Media settings)
      unset( $sizes['large']); // 1024
      unset( $sizes['extra_large']); // 1500
      unset( $sizes['1536x1536']);
      unset( $sizes['2048x2048']);
      return $sizes;
    }
    add_filter('intermediate_image_sizes_advanced', 'remove_default_image_sizes');
    
    // Lightbox links default to "large" size thumbnail, we link it to original image size
    add_filter('avf_avia_builder_gallery_image_link', 'avia_change_gallery_thumbnail_link', 10, 4);
    function avia_change_gallery_thumbnail_link($link, $attachment, $atts, $meta) {
       $link = wp_get_attachment_image_src($attachment->ID, "full");
       return $link;
    }
    
    // Disable scrolling of background when lightbox image opened
    add_action('wp_footer', 'custom_lightbox_script');
    function custom_lightbox_script(){
    ?>
    <script type="text/javascript">
    (function($) {
        function a() {
          $('body').on('click', '.lightbox-added', function() {
            if($('.mfp-bg').length >= 1) {
              $('html').css("overflow-y", "hidden");
            }
          });
    
          $('body').on('click', function() {
            setTimeout( function() {
              if($('.mfp-bg').length == 0) {
                $('html').css("overflow-y", "scroll");
              }
            },500);
          });
        }
      a();
    })(jQuery);
    </script>
    <?php
    }

    Hope that helps, try it out.
    Rob

    P.S.:
    Don’t forget to do a further (lossless) compression on the images you created in Photoshop BEFORE upload to WP, using for example File Optimizer on Windows or Trimage on Linux.

    P.S. #2
    Note that the sizes you set in WP Settings > Media Settings affect the sizes for Thumbnail size, Medium size and Large size – and set “Crop thumbnail to exact dimensions (normally thumbnails are proportional)” checkmark.

    • This reply was modified 4 years, 4 months ago by rob2701. Reason: Added remark about Media Settings in WP
    #1214618

    Hi there,

    Thanks a lot for sharing this so fast. I have already tried tried it but it looks like the function to remove the default image sizes is not working for me, because when I check with the plugin Regenerate Thumbnails, those image sizes are already registered as you can see on the following screenshot:

    Image 2020-05-20 at 11.17.40 AM.png

    Any idea why this function is not working?

    Thanks a lot for your help, I really appreciate it.

    Also thanks a lot for your tips on the lossless compression, I will definitely try it.

    #1214625

    AFTER checking the registered image sizes in WP Settings > Media are correct and AFTER setting the code in the child theme functions.php, do this:

    > Tools > Regenerate Thumbnails
    UNcheck: Skip regenerating existing correctly sized thumbnails (faster).
    CHECK: Delete thumbnail files for old unregistered sizes in order to free up server space. This may result in broken images in your posts and pages.

    You should have remaining:
    widget: 36×36 pixels (cropped to fit)
    This is used in the Dashboard for the portfolio items

    square: 180×180 pixels (cropped to fit)
    This is used on the frontend for the Previous/Next buttons to switch between Galleries

    Should work like this, does for me :-)

    • This reply was modified 4 years, 4 months ago by rob2701.
    #1214630

    If that doesn’t do the trick try this (replace the relevant part):

    // Remove unneeded WP image sizes
    // updated 2020-01-13 because of additional image sizes
    function remove_default_image_sizes( $sizes) {
      unset( $sizes['thumbnail']); // 80px thumbnail
      unset( $sizes['small']); // 150px thumbnail - (Size based on Media setting)
      unset( $sizes['medium']); // 300px - (Size based on Media settings)
      unset( $sizes['medium_large']); // 768 - (Size based on Media settings)
      unset( $sizes['large']); // 1024
      unset( $sizes['extra_large']); // 1500
      unset( $sizes['1536x1536']);
      unset( $sizes['2048x2048']);
    // Add these 2 lines to remove the "new" WP default image sizes:
      remove_image_size( '1536x1536' );
      remove_image_size( '2048x2048' );
      return $sizes;
    }
    add_filter('intermediate_image_sizes_advanced', 'remove_default_image_sizes');

    By the way, in Settings > Media I have:
    Thumbnail size 80×80, crop checked
    Medium size 300×300
    Large size 1024×1024
    Check yours before doing the regenerate

    Oh yeah, and you only see the REAL sizes created in an actual image “Regenerate”, the General “Regenerate Thumbnails” setting shows the “default” registered sizes. Strange but true. Perhaps that is the only issue?
    After regenerating you can check this by doing a regenerate on an actual image, and of course by checking the actual files through FTP.

    • This reply was modified 4 years, 4 months ago by rob2701. Reason: Added remark about how to check for ACTUAL created thumbs
    #1214736

    Hi there again,

    First of all thanks for getting back to me this fast. If you have a blog, I would gladly share it :)

    After running some tests uploading a few pictures, it looks like your code (the initial one you provided) actually works. But for some reason the registered image sizes continue to appear on the Regenerate Thumbnails plugin. This is strange because the thumbnails corresponding to those sizes are not created (so your solution works great). I have tried a plugin called Simple Image Sizes, which allows you to remove registered sizes and when you do that with this plugin, then, these sizes won’t show up on the Regenerate Thumbnails plugin. One thing about this plugin is that when I click on regenerate it doesn’t remove the unregistered image sizes. However, there’s another plugin called Regenerate Thumbnails Advanced by Shortpixel that work.

    Anyway, your solution works fine when uploading new images and I’m very happy with that, so thanks for your support.

    Regarding the Trimage software, I have tried to download it for Mac following the instructions they provide on their web but I haven’t been able to do it. Any other alternatives that you know?

    Finally, there’s something else I wanted to ask you. I like your idea very much of being you who controls what image is served (instead of letting WordPress/Enfold choose). But there’s something that I’m not sure if could be improved in this process (just curious to know your thoughts about it). It’s the idea behind the srcset attribute but done deliberately by you. That is, optimize manually the images choosing the dimensions for different devices and then let the browser decide which one of the images that you have created serve. In other words, it would be implementing the srcset but in a controlled way, since it would be us who would decide which image sizes are correct.

    What do you think?

    Again, thanks so much for your help and for sharing your solution.

    Regards,

    #1215045

    Hi,

    Glad to hear the initial code works.

    Like I explained above, for some reason the General settings page in Regenerate Thumbnails keeps showing the default registered image sizes in WP. But when you actually regenerate the thumbnails on an actual image, then it correctly shows the registered ones with a green checkmark and the deregistered ones with a red cross. Don’t know why, you should ask the developer of the plugin. Same for why it doesn’t remove the unused redundant thumb sizes, plugin developer will know more than me. But if the Regenerate Thumbnails Advanced by Shortpixel works for removing the redundant ones, great. Use it once, then after that the Regenerate Thumbnails one will handle the new ones correctly.

    Trimage says it will work an Mac, macOS Trimage is available from Homebrew, to install, type:
    brew install trimage
    Launch by executing trimage in Terminal.

    ImageOptim (For macOS) may be a good alternative. PNG Gauntlet for PNGs.
    Caesium Image Compressor may also be a good choice.

    Regarding my choice to disable WP srcset for now:
    I have opted out of that to be able to serve “1 double size image with high compression for all devices”. It results in sharp images but no extra page weight. At the moment there is no way with Enfold to serve different images to different devices using the Retina approach chosen. If you enable WP srcset it will just create lots of extra image sizes which cannot be used in Enfold effectively anyway now.
    Also don’t be fooled too much by the possibility of using CSS choices for different devices (by duplicating blocks and assigning custom CSS classes to specify the device, it will just result in ALL the images for ALL devices loading on your pages ALL THE TIME (yes, for all devices regardless).
    So no, I don’t know at the moment how you could implement WP srcset while using Enfold.
    Hence my approach: 1 image fits all. Added bonus: less http requests in galleries, even if images are heavier on smaller devices for now.

    Of course, once Enfold implements srcset (which they have promised to deliver at some point) the whole approach changes, as we will hopefully be able to serve different sizes to different devices (but still maintain the double size high compression approach for all of them).

    Kind regards,

    Rob

    • This reply was modified 4 years, 4 months ago by rob2701. Reason: Removed my stupid remark about why Regenerate Thumnails might not be picking up the list of unset image sizes in its on its general page. Turns out others have noticed the same behaviour (on the plugin's Support page)
Viewing 26 posts - 1 through 26 (of 26 total)
  • You must be logged in to reply to this topic.