Forum Replies Created

Viewing 15 replies - 196 through 210 (of 1,795 total)
  • Plugin Author linux4me2

    (@linux4me2)

    Hi Vishan,

    If you can set up a menu for the listing pages in WP Admin > Appearance > Menus, then I don’t see why it wouldn’t work.

    Thread Starter linux4me2

    (@linux4me2)

    Okay, thanks for letting me know. I will take a look at the EWWW Image Optimizer.

    Plugin Author linux4me2

    (@linux4me2)

    I’m glad you like the plugin.

    You can add CSS to customize the look of the menus in WordPress Admin > Appearance > Customize > Additional CSS, or in the style.css of your child theme.

    Arranging the 3-4 drop-down menus horizontally is also something you would do with custom CSS. If you provide a link to the page you’re working on, I, or someone else here, will take a look and try to help you out.

    While you’re doing this kind of thing, you will find the developer tools that come with Chrome and Firefox very helpful. You can right-click an element on a web page–like one of your drop-down menus–and choose “Inspect” from the pop-up menu to open the Developer Tools panel, which will show you the CSS assigned to any particular element as well as allow you to add your own CSS to test live before you add anything to your site.

    I suspect the developers will fix this eventually, so I recommend altering the file in the parent theme, /wp-content/themes/twentyten/functions.php by changing line 743 from this:

    
    require get_stylesheet_directory() . '/block-patterns.php';
    

    to this:

    
    require get_template_directory() . '/block-patterns.php';
    

    The function get_template_directory() will “[i]n the case a child theme is being used, the absolute path to the parent theme directory will be returned,” which will resolve the error for now, and won’t leave you with a potentially outdated copy of block-patterns.php in your child theme folder.

    Once the developers release a fix, the edited file will be overwritten, and you’ll be all good.

    Forum: Plugins
    In reply to: [Menu In Post] Mobile View
    Plugin Author linux4me2

    (@linux4me2)

    I don’t like the look of a wrapping horizontal menu. I think what I would do is wrap your custom code in a media query, so that the menu displays vertically unless the device/display is wide enough for the menu to display horizontally without wrapping.

    For example, say your menu starts wrapping when the display is less than 768 pixels wide, your CSS would look something like:

    
    @media only screen and (min-width: 768px) {
        .inlinemenu {
            float: none;
          padding-right: 25px;
          padding: -20px;
          padding-bottom: 10px;
          width: -3px;
          height: 0px;
          top: 9px;
          margin: 0px;
          list-style: none;
        }
    }
    

    You can use your browser’s developer tools’ mobile view to test the width to see what you need to substitute for the 768 pixels. Both Chrome and Firefox have that capability.

    Plugin Author linux4me2

    (@linux4me2)

    I’m glad you got it working. Thanks for posting your CSS.

    I switched themes to a child theme of Twenty Twenty, and the snippet worked, so I think that particular problem was at my end.

    I also tested with 5.8-RC4, and the compression at default settings is now much better; I got the following with a 76.4 KB, 1280 x 642 pixel, original WebP image:

    800×401.webp 51.0 KB
    768×385.webp 48.2 KB
    300×150.webp 10.9 KB
    150×75.webp 4.2 KB

    However, if I attempt to change the quality to 50%:

    
    function filter_webp_quality($quality, $mime_type) {
        if ('image/webp' === $mime_type) {
            return 50;
        }
        return $quality;
    }
    add_filter('wp_editor_set_quality', 'filter_webp_quality', 10, 2);
    

    I’m still getting the same file sizes, so it looks like it’s not possible to set the quality in my child theme’s functions.php with that code snippet.

    It turns out that libwebp is a red herring. It’s installed as a dependency for a number of necessary packages on my system. Cwebp is part of libwebp-tools for me, which is not installed, and I think only relevant for the command line. I also checked on an account running PHP 8.0 via phpinfo() that WebP is supported in PHP, and tested again with WP 5.8, but I still got the large file sizes for the images it creates.

    I’m wondering if the large images that are generated are due to our server environments? Surely, the WP developers would have noticed if they were creating smaller-dimension images that are four times the file size of the originals?

    I downloaded the WebP images created by my test, and they do show they are of the type “image/webp”.

    I SSH’d into an account on my server and ran the Imagick “identify” command to see what I’d find, and it doesn’t show WebP capability:

    
    $ identify -version
    Version: ImageMagick 6.9.10-68 Q16 x86_64 2021-02-24 https://imagemagick.org
    Copyright: © 1999-2019 ImageMagick Studio LLC
    License: https://imagemagick.org/script/license.php
    Features: Cipher DPC Modules OpenMP(3.1) 
    Delegates (built-in): bzlib cairo fontconfig freetype gslib jng jp2 jpeg lcms ltdl lzma openexr pangocairo png ps rsvg tiff wmf x xml zlib
    

    Next, I set up a test script to output the PHP Imagick formats supported on my test site using the example here.

    The table it output does not list WebP under the supported PHP Imagick formats, so that tells me that WP’s report that my server supports WebP via Imagick is probably incorrect.

    I uploaded a test JPEG file to the server to try conversion to WebP via the command line with Imagick’s convert command, and I found something interesting that may be part of the problem. When I ran the convert command, I got the following error:

    
    convert: delegate failed 'cwebp' -quiet %Q '%i' -o '%o' @ error/delegate.c/InvokeDelegate/1928.
    

    That makes it look like Imagick’s convert command is using CWebP to do WebP conversions, and CWebP’s command structure is different than Imagick. I wonder if I removed CWebP (libwebp) from the server, if it would fix the issue with the large file sizes WP creates with WebP, and/or no longer list WebP as a compatible format for Imagick?

    Do you happen to have libwebp installed on your server?

    According to this article, there is a way to tweak WebP’s quality settings, but it doesn’t seem to help with the problem you’ve discovered.

    I noticed the same thing. I uploaded a 1240 x 682 WebP image that is 76.4 KB, created locally by using Imagemagick from a JPEG using a quality setting of 50.

    Without touching WP’s WebP settings the filesizes after upload are:

    test-150×75.webp 17.7 KB
    test-300×150.webp 57.7 KB
    test-768×385.webp 293.3 KB
    test-800×401.webp 313.3 KB
    test.webp 76.4 KB

    The smaller-dimension images created by WP are larger in size than the original. Just out of curiosity, I added the following to my functions.php to alter the quality from the default to 50:

    
    // Use a quality setting of 50 for WebP images.
    function filter_webp_quality( $quality, $mime_type) {
        if ('image/webp' === $mime_type) {
            return 50;
        }
        return $quality;
    }
    

    After that, I re-uploaded the same file and got the same file sizes as before.

    I verified that I have ImageMagick/Imagick installed on my server:

    
    ### wp-media ###
    
    image_editor: WP_Image_Editor_Imagick
    imagick_module_version: 1692
    imagemagick_version: ImageMagick 6.9.12-17 Q16 x86_64 2021-06-25 https://imagemagick.org
    imagick_version: 3.5.0
    file_uploads: File uploads is turned off
    post_max_size: 8M
    upload_max_filesize: 8M
    max_effective_size: 8 MB
    max_file_uploads: 20
    imagick_limits: 
    	imagick::RESOURCETYPE_AREA: 62 GB
    	imagick::RESOURCETYPE_DISK: 9.2233720368548E+18
    	imagick::RESOURCETYPE_FILE: 768
    	imagick::RESOURCETYPE_MAP: 62 GB
    	imagick::RESOURCETYPE_MEMORY: 31 GB
    	imagick::RESOURCETYPE_THREAD: 1
    imagemagick_file_formats: 3FR, 3G2, 3GP, AAI, AI, APNG, ART, ARW, AVI, AVS, BGR, BGRA, BGRO, BIE, BMP, BMP2, BMP3, BRF, CAL, CALS, CANVAS, CAPTION, CIN, CIP, CLIP, CMYK, CMYKA, CR2, CR3, CRW, CUR, CUT, DATA, DCM, DCR, DCX, DDS, DFONT, DNG, DOT, DPX, DXT1, DXT5, EPDF, EPI, EPS, EPS2, EPS3, EPSF, EPSI, EPT, EPT2, EPT3, ERF, EXR, FAX, FILE, FITS, FRACTAL, FTP, FTS, G3, G4, GIF, GIF87, GRADIENT, GRAY, GRAYA, GROUP4, GV, H, HALD, HDR, HISTOGRAM, HRZ, HTM, HTML, HTTP, HTTPS, ICB, ICO, ICON, IIQ, INFO, INLINE, IPL, ISOBRL, ISOBRL6, J2C, J2K, JBG, JBIG, JNG, JNX, JP2, JPC, JPE, JPEG, JPG, JPM, JPS, JPT, JSON, K25, KDC, LABEL, M2V, M4V, MAC, MAGICK, MAP, MASK, MAT, MATTE, MEF, MIFF, MKV, MNG, MONO, MOV, MP4, MPC, MPG, MRW, MSL, MSVG, MTV, MVG, NEF, NRW, NULL, ORF, OTB, OTF, PAL, PALM, PAM, PANGO, PATTERN, PBM, PCD, PCDS, PCL, PCT, PCX, PDB, PDF, PDFA, PEF, PES, PFA, PFB, PFM, PGM, PGX, PICON, PICT, PIX, PJPEG, PLASMA, PNG, PNG00, PNG24, PNG32, PNG48, PNG64, PNG8, PNM, POCKETMOD, PPM, PREVIEW, PS, PS2, PS3, PSB, PSD, PTIF, PWP, RADIAL-GRADIENT, RAF, RAS, RAW, RGB, RGBA, RGBO, RGF, RLA, RLE, RMF, RW2, SCR, SCT, SFW, SGI, SHTML, SIX, SIXEL, SPARSE-COLOR, SR2, SRF, STEGANO, SUN, SVG, SVGZ, TEXT, TGA, THUMBNAIL, TIFF, TIFF64, TILE, TIM, TTC, TTF, TXT, UBRL, UBRL6, UIL, UYVY, VDA, VICAR, VID, VIDEO, VIFF, VIPS, VST, WBMP, WEBM, WEBP, WMF, WMV, WMZ, WPG, X, X3F, XBM, XC, XCF, XPM, XPS, XV, XWD, YCbCr, YCbCrA, YUV
    gd_version: 2.3.2
    gd_formats: GIF, JPEG, PNG, WebP, BMP, XPM
    ghostscript_version: unknown
    

    I’m not sure what the issue is with the large files.

    Plugin Author linux4me2

    (@linux4me2)

    I had to test the plugin for WP v. 5.8 and update the “tested to” version, so I went ahead and added this functionality to version 1.1.8 of Menu In Post which should be available for download momentarily. Thank you @oliveirataquari for the request and @kojotkk for the code snippet.

    Plugin Author linux4me2

    (@linux4me2)

    @kojotkk Is this functionality you want for the plugin too, or are you just being helpful?

    Either way, thanks for the code suggestion.

    Thread Starter linux4me2

    (@linux4me2)

    I figured out what the problem was.

    I looked at the phpinfo for the system version of PHP, and found out there should be a specific section for Zip, which the system PHP phpinfo has, but the specific versions of PHP did not. I compared the system php.ini to the PHP 7.4 php.ini, and there was no module declaration for Zip. That made me wonder if there was an update that didn’t propagate to the multi-PHP system. Looking over recent software updates, I noticed that all the Zip extensions were updated on 6/19/2021. I restarted PHP-FPM, a voila! All the warnings in WordPress Site Health are gone, there is now a Zip section in the various PHP-version-specific php.ini files, and all is good.

    Thanks for your help, @fierevere. You got me thinking in the right direction.

    Thread Starter linux4me2

    (@linux4me2)

    You got me thinking about how to see what extensions are loaded other than using the command line. I wrote this little PHP script to check:

    
    <!DOCTYPE html>
    <html>
    	<head>
    		<meta charset="UTF-8">
    		<meta name="viewport" content="width=device-width, initial-scale=1.0">
    		<title>Test Page</title>
    		
    	</head>
    	<body>
    		<div id="wrapper">
    			<div id="container">
    				<div id="header"><h2>Test Page</h2></div>
    				<div>
    					<?php
    					if (extension_loaded('zip')) {
    					    echo "Zip is loaded.";
    				    } else {
    				        echo "Zip is not loaded.";
    			        }
    			        echo '<br><h2>Loaded Extensions</h2>';
    			        $loaded = get_loaded_extensions();
    			        foreach ($loaded as $key=>$val) {
    			            echo $val . '<br>';
    		            }
    					?>
    				</div>
    			</div>
    		</div>
    	</body>
    </html>
    

    It shows that Zip is not loaded, so I guess there’s my answer. I still have to figure out why.

Viewing 15 replies - 196 through 210 (of 1,795 total)