KennyLL
Forum Replies Created
-
Forum: Fixing WordPress
In reply to: Adding Background Video on Cover Block Problem – No Bandwidth IssuesThanks for the thorough response, much appreciated!
I think the main issue I was hoping to determine and debug is whether the auto-looping aspect of the video was somehow chewing up increasing amounts of bandwidth if I just had that browser tab in foreground/focus. There were days where there was over 2GB bandwidth with ONLY me viewing/using site, and that ‘might’ have been just leaving the tab in focus when done for the day (I think my computer won’t go to sleep if that video is showing).
I’ll look up samples of loading video from 3rd-party service rather than self-hosting. Was just trying to keep it simple so easy to edit for others, and to see how the ‘built-in’ functionality actually worked, since it is an available option in WordPress. Would it be safe to assume others doing this with WP use a 3rd-party service or just ‘deal with’ the bandwidth issues?!?
And we do have a dedicated server, but like to keep additional non-default apps to a minimum. If there was something that would not have a lot of dependencies, and provide a simple enough view of bandwidth for ONE PARTICULAR site/user, we might be open to checking it out. Our server is running CloudLinux/cPanel.
– Any other tips?
Thanks!
Forum: Fixing WordPress
In reply to: Adding Additional Images to Gallery Block Replaces GalleryOk, thanks for confirming. Is there somewhere this bug should be addressed, if not already?
And I was able to get around it by modifying step 2:
2) When the ‘Add to gallery’ screen first opens, click to switch to ‘Edit gallery’ to see your existing gallery items. Then switch back to ‘Add to gallery’ and continue with step 3.
Hope this helps somebody. It was driving me crazy…
Hi, sorry for the delayed response. Out of curiosity, I put a message in to the maintainer of the Imagick extension about passing the ‘sharp-yuv’ option. I did receive the following response:
`Most of the options can be set through the the set option method, but they also require knowing the appropriate config option which….isn’t always obvious from the docs.
Looking at the code, try:
$imagick->setOption("webp:use-sharp-yuv", "true");
– Does this sound like it might be possible to pass this option when using Imagick to convert WebP’s?
This is the one thing we haven’t been able to test yet in trying to get better quality WebP images. It just happens that the types of images we are uploading really accentuate the issues that WebP can have with certain details, making them fairly unusable.
Let me know if you have any thoughts or insight here.
Thanks!
KennyFantastic! Thank you for the continued great support here. The WebPs made from the originals (largest size) are now cleaner and a bit smaller (prob due to not having to compress all the extra JPEG noise/detail).
I think you should really promote that this plugin has options to allow for better quality thumbnail images than a lot of the competing plugins, which focus 100% on smaller filesizes with less regard for quality. Things like this, sharpening, and color sampling factor, can all be adjusted for better quality. Not aware of other plugins that offer this (we had been using an ancient plugin that allowed for sharpening, but hadn’t been updated in years). Photographers or other image quality geeks (like us) would probably see the value…
Thanks again!
Sorry, my apologies. We were still in the thick of seeing how this plugin could be integrated into our overall workflow. But I’ve added a review and do truly appreciate the support and great plugin!
Thanks.
Hi, thanks for the added clarity here. Sorry for all the questions, just really trying to understand the possibilities and limitations of WordPress/PHP/Imagick/CloudLinux/etc. to get the best possible quality images without them being MASSIVE in filesize. And I know our emphasis on quality may not be as important to most.
It does appear that CloudLinux on our server is using libjpeg-turbo. So we’ll investigate the links you sent to see if we can drop Mozjpeg in without causing everything to go haywire (which happened when trying to recompile Imagick with WebP support).
I think Warps’ workflow of sharpening images after resizing and before compressing is ideal for quality. So will probably produce the best quality JPEGs. And the option for adjusting Color Sampling Factor seems to help a fair amount as well. We’ll start there.
And if the final saved thumbnails are then sent to GD to produce the WebP versions, maybe we’ll just alter turning WebP support on for images that do well with WebP (typical photographs) and turn off for those that don’t (images with small vibrant-colored details, more ‘graphical’ images). We do like the fairly significant reduction in filesize that WebP offers, but at its default it just destroys the quality of very certain types of images.
Couple last questions if that’s OK:
– Is your Color Sampling Factor just adjusting the Imagick Sampling Factors (https://www.php.net/manual/en/imagick.setsamplingfactors.php)?
– What does ‘Compression Type’ alter, and what would be the differences between Imagick & WordPress defaults there?
Thanks again! A ‘hybrid’ approach may be what we’re needing to use to get around limitations of the different processes involved.
Hi, thanks for the quick responses! Much appreciated.
4) Sorry, you did say that above, my apologies. And this makes sense now, too, as to why the WebPs don’t have meta data (including ICC profiles), as GD doesn’t support that. And it also doesn’t look like the imagewebp that GD uses for creating WebPs supports the ‘sharp-YUV’ option, at least not from that PHP info page. That’s too bad…
And since it appears imagewebp/GD doesn’t support lossless encoding, how does Warp handle PNGs? We have a small portion of our images that are optimized as PNGs (things ilke logos, etc.). If Warp would convert these using standard lossy WebP conversion, I suppose we’d have to disable WebP when uploading PNGs. In checking some older files, it looks like WebP versions of PNGs are just a few KB smaller, with zero difference to image.
7) Thanks fo the clarification. It looks like the other sharpening plugin we were using uses UnsharpMask, which has a few additional options.
See: https://www.php.net/manual/en/imagick.unsharpmaskimage.phpHaving a hard time finding pros/cons to each method. And if Warp is doing the sharpening BEFORE the image is compressed with Imagick, where our plugin is after (I’m not sure how to figure this out for sure), that would be a big advantage either way as it wouldn’t be sharpening all of the Imagick jpg artifacts & noise.
4C) I’ll have to look more into how libjpeg-turbo and/or Mozjpeg could/would work in this workflow. I believe the other optimization plugin we’ve been using does use Mozjpeg, but just applies it to the already resized/optimized/saved Imagick thumbnails. So it’s just re-compressing the already compressed thumbnail files, resulting in no quality gains, just a tiny bit of additional filesize reduction.
I guess I’m realizing just how it seems that WordPress appears to be ‘hard-wired’ in using Imagick or GD to do the initial resizing & compressing of all images. This means anything else just happens in addition to this, and nothing would be able to actually ‘improve’ quality once the compression and image degradation has taken place. But I may be wrong here, still learning…
Hi, thanks for the updates here! I have updated Warp Imagick and re-activated it to do some testing with the additional options you’ve added. The added sharpening, especially with the option to adjust, is VERY welcomed and could eliminate our dependency on a different plugin just for that feature. And not sure if the Color Sampling adjustments were in there before, but another welcome option to gain better quality for users like us!
So I’ve ran tests on a few sample images we use and comparing with the current optimization and sharpening plugins we use. After checking the results, which look very promising, I just have a couple follow-up questions if that’s OK.
7) Is your sharpening using a default ‘0’ for the threshold value? Our other plugin allows adjusting that (along with sigma and a couple other things), but not sure it’s mandatory. Just wondering so I know if I’m comparing apples-to-apples.
4) What does Warp use for WebP conversions? Is it a local install of cwebp, or does/can it use the WebP features of Imagick if it is compiled with it? And is it still converted after Imagick resizes the original and adds it’s own compression?
4b) Could it be possible (with a function or in a future release) to apply the option of using ‘sharp-YUV’ in the conversions of WebPs? I know cwebp, and even Imagick (if compiled with WebP) ‘can’ support it (see: https://titanwolf.org/Network/Articles/Article?AID=65aba585-2bd1-4977-8798-7db7502a7b1c#gsc.tab=0).
In our testing, we were surprised to see how much of a difference changing the chroma subsampling from 4:2:0 to 4:4:4 made, especially on certain types of images. Globally, the files were just cleaner, color edges a bit sharper. But on one ‘stress-test’ image we use that is of a package design with a vibrant red solid background with black, yellow, and white reversed type over it, the difference in quality is MASSIVE! I had to go back and check the settings and images to make sure I didn’t open the wrong image. And this image is also the one that shows the most degradation on the WebP versions. If it didn’t have a photo of the package contents (mixed nuts) in it, we might go PNG.
So we’re really wondering if the main issues we’re seeing with WebPs (besides them re-optimizing the already downsampled JPGs) is the known issues they have with fine details and certain vibrant colors. This is what ‘sharp-YUV’ is supposed to help, though not sure it will be as significant as going from 4:2:0 to 4:4:4 on JPGs. We just really want to see if this could make WebPs the optimal size AND quality option.
4c) Regarding the use of libjpeg-turbo / Mozjpeg, does this work to better the compression quality and results of the resizing Imagick does? Does Imagick need to be compiled to support it?
We’ve spent the last couple weeks working with our server IT staff to get the install of Imagick on PHP 7.4 compiled with WebP support, but its looking like on our server (cPanel; CentOS/CloudLinux), trying to get anything other than the default packages installed & working is just not possible and causes errors. So we are ‘stuck’ with either Imagick 3.4.4 running ImageMagick 6.9.10-68 Q16 with NO WEBP support, or a CloudLinux ‘alt’ PHP version which has ImageMagick 7.0.10-10 Q16 and DOES support WebP. The latter is what I was using in today’s tests.
Thanks again! Sorry for the long post. My head has been swimming in all the technical details of image conversions & techniques possible with WordPress the last few weeks…
Hi, thanks for the quick & thorough responses! Much appreciated. I just had a couple follow-up notes.
1) So sorry, it did appear that the sharpening plugin we were using was using the GD library, and therefor stripping the profiles. I tried a different sharpening plugin, that uses ImageMagick and has parameters that can be adjusted, and it does appear to retain the ICC profiles, at least on the JPEGs. I’m testing in Adobe Bridge, which shows the proper profiles now for all of the JPEGs. But it still shows the WebP versions as ‘Untagged’. Not sure if Bridge just doesn’t really understand WebP images (there are no thumbnail previews), or if the WebP’s truly don’t have profiles.
– Do you happen to know a better method to verify WebP profiles, and ‘should’ they retain the profiles if the JPEGs have them?
2) Would love to see the option for sharpening here. It could be off by default (to save space), but nice for some to have the option if they need it. And it could be as simple as some basic defaults that are toggled on/off, or a couple choices (like heavy, mild, off).
4) Ah, thanks. That’s too bad. It would probably produce much better images if the higher quality WebP compression was used alone, rather than on the thumbnails that already have all the poorer JPEG compression artifacts added. Might defeat a lot of the benefits of WebP compression quality. With so many browsers now supporting WebP, those images would probably be seen by the vast majority of visitors over the fallback JPEGs. Even when trying to make pretty ‘high-quality’ images, the WebPs are still a fair amount smaller than the JPEGs.
We have a dedicated server that runs CloudLinux. We just had the support team add PHP 7.4.x to use as an option, and that’s what I’m using on the site I’m running these tests on. We had them install ImageMagick and the Imagick module, but don’t know anything about how it was compiled. Not sure if there are ‘defaults’. All I can tell is that its using ImageMagick v.6.9.10-68 Q16, and Imagick module v.3.4.4.
Thanks again for the support and a very nice plugin!
Forum: Installing WordPress
In reply to: Temp index.html page / View WP site while developingThanks for the response. Unfortunately, I don’t have access to the cPanel, otherwise I probably would have done the install into a subdirectory using Softaculous. It’s been too much of a hassle to try to get in touch with the person who is in control of this, as it goes through a middle-man, etc.
– Any other options for working WITHOUT moving WordPress to a subdirectory (which I’d have to re-migrate back to root anyway when done)?
Hi Angelo,
Thanks for the response, it’s much appreciated!You simply click the link to media on Blubrry button and upload…
We’re not using the plugin currently, but we imagine this must be something PP adds to the CPT editing page, correct?
What do you mean by this? If you are using post types you still have posts in your post type they are just not WordPress “Posts”.
Sorry, we just weren’t sure if ‘attaching’ PP to a CPT would mean that the content of the post would be completely handled by PP (e.g., podcast title becomes CPT title, description becomes main content, etc.). We didn’t think so, but the documentation isn’t completely clear here.
We’re just wanting to incorporate the audio player, a download link, and a global ‘subcribe’ link from PP to the posts made in this one specific CPT. There will be other features we will be customizing, using ACF for specific fields the client will fill in (e.g., scripture chapter & verse), etc.
– We imagine there is at least some control over where the audio player displays (i.e., order – before/after other custom or basic WP content), both on the archive and CPT single pages, correct?
– And do we need PP to generate or display the ‘subscribe to podcast’ links? We’re thinking just a single simple ‘Subscribe’ link at the top of the CPT archive pages, as well as the top of each CPT single page. We’re hoping it would be smart enough to launch either the ‘Apple Podcasts’ or ‘Google Podcasts’ players depending on platform. But not sure if we have to (or should) create this ourselves, or if PP creates this in a simple enough manner.
Thanks again for any insight here! Forgive my lack of understanding on how podcasts work, I don’t actually have a ton of experience in that area as of now.
Hi Gerroald, thanks for the thorough reply here.
Well, we’ve disabled & re-enabled WordFence a number of times over the last week, but the ‘wordfence_daily_cron’ time always ends up being somewhere between 11am-1pm our local time (PST). As 12pm noon is our peak traffic time of the day, these times are just far from ideal.
So, unfortunately, we’ve just had to leave WordFence disabled for now. Hopefully at some point in the future it will actually activate at a time a bit more inline with the recommendations (after hours, middle of the night, etc.). But until then, we’ve had to weigh the load on the server vs. the security that WF adds.
But can you let me know what the ‘wordfence_start_scheduled_scan’ cron is doing? Maybe it’s just the name that was throwing me…
Thanks!
Hi Gerroald, thanks for the response.
We are not using Query Monitor (had never heard of it).
– So to be clear, you’re stating that whenever we deactivate & reactivate WF, a different randomly generated scheduling may/will be applied to all WF cron tasks??
– Does the time that we reactivate WF have anything to do with the scheduling, or is it all completely random?
– Would we be able to see the newly applied time by checking the ‘Diagnostics > Cron Jobs’ tab?
When I check the current ‘Cron Jobs’ tab, it appears to only show jobs that have not run yet, but are scheduled to. Is this correct? Any way to see past jobs to see if the coincide with our server memory errors (I’ve written down the currently scheduled ones)?
I see a couple main WF cron jobs listed:
A) wordfence_daily_cron – this is scheduled for tomorrow at 9am EDT.
B) wordfence_start_scheduled_scan – this is scheduled for 5/10 & 5.13 at 2:20am EDT.Can you let me know the difference between what those 2 do? The one at 9am EDT is our main concern, as that coincides with when email blasts are sent out that drive a lot of legitimate traffic to the site. Wondering if the traffic hitting while WF is busy is causing the issues.
Thanks for the additional insight here.
Thanks for the reply. Hmm, I was thinking ‘manually scheduled scans’ were different from the auto scans. The documentation seems to indicate that the frequency (how often) scans run is what the Premium upgrade offers.
If what you’re stating is true, that is unfortunate and very misleading according to what the documentation states.
– So we are stuck with Wordfence scheduling its scans at a random and very inopportune time unless we pay for a premium subscription?
The documentation goes so far as to recommend scheduling scans for the middle of the night, but for a free user its scheduled at 9am (which is prime-time for our site)?!? I suppose that’s a really good way to force people to upgrade, but just seems a bit shady.
– Are there any other ways (programmatically) to alter this, or any, cron tasks in WordPress??
Thanks.
Wow, thanks for the fast & helpful support here! Swapping those hooks was all it took and our original functionality appears to be working now in TablePress!
I’m very impressed (and a bit surprised) how smooth the migration from such an old plugin went. We’ll definitely try to include a donation when we bill for the final work.