Fox Lee
Forum Replies Created
-
Forum: Plugins
In reply to: [Getwid - Gutenberg Blocks] Section Block has stopped working in back-endQuite a late reply, but in case it’s still useful: when I got this error with section blocks, it appeared to be connected to disabling the Image Hotspot block. (I’ve shared this with the team in another thread.)
Of course your problem might be something different! But, if you have also disabled some blocks, that might be a worth looking into at least.
Okay, thanks for the update 🙂
Forum: Plugins
In reply to: [Getwid - Gutenberg Blocks] advanced heading / google fontsHi, I’m not the original poster but I’m interested in this too. For me, the purpose would be:
- encouraging clients to stick to the unified look & feel of the theme, rather than splashing different fonts all over the place, and
- preventing clients from loading a bunch of additional fonts, which will slow down load times.
I realise I can just explain to a client why they shouldn’t use a ton of mismatched fonts, but frankly that’s a lot of work and it never sticks. I’d rather just not present them with the option in the first place.
- This reply was modified 6 years, 8 months ago by Fox Lee.
Ah. I’ve got it.
I’d forgotten that back in beta, I included code to modify MetaSlider’s output. I wasn’t happy with MS lacking srcset markup when cropping was turned on—autocropping is a great idea, but not if it means loading an oversized image on mobile—so I added it myself. And in that code, I made the mistake of calling “large” rather than “full” as my max size. I also needed to set my content width to a larger size.
Why it would load full in Chrome (but not Firefox) regardless of that setting is… anyone’s guess, I suppose. I assume the two browsers just implement srcset differently. Obviously a complete red herring in this case :\
In any case, I’ve modified my code and there are no problems now. Thanks for your help, and I do apologise for forgetting that I had added unexpected code to the scenario. I hope you’ll consider adding srcset markup natively in the future though <:)
Hello again,
Sorry for the delay, I was off work for a few days. I’ve looked into it further and it really does seem to be specific to Firefox; testing on other browsers and other computers, and having friends test it for me, it seems to always load the downsized version in FF and always load the proper version in Chrome. Are you completely certain you are seeing the full-sized version in Firefox?
I’m seeing in the page source that max-width:1024px is there in both browsers, but it only seem to affect the displayed image in FF. Maybe the two browsers treat that condition differently?
(For reference, the crop setting has been on Standard since before my last response. I have tried disabling every other plugin except Metaslider, but I’ve seen no changes.)
- This reply was modified 7 years, 1 month ago by Fox Lee.
Thanks for your help. I see what you’re saying, it makes sens to think it must be the full-size version. However, if I isolate the image that’s actually displayed (by right-click > display image) I can see it’s only the 1024 version. It’s also evident if I use an inspector to change the sizes=”(max-width: 1024px) 100vw, 1024px” property of the srcset to sizes=”(max-width: 1920px) 100vw, 1024px” on the fly; it’s clear from the change in image quality that the intial image displayed is an upsized 1024w, not the full size version.
Is this the not case when you check it? If it isn’t, perhaps it’s a browser-dependent issue.
Here’s a screenshot of my network tab, showing that same image loaded in 1024×192: https://nonsense.munchlax.org/temp/fgc-metaslider-load.jpg
You can see the full size version load as well, earlier in the sequence. But it’s the later one that’s being displayed, at least for me.
“WP will use the main image you upload if an image size doesn’t exist. It appears to be using the full size image now.”
No, it’s using the 1024w generated size. That’s the whole problem. What makes you think it’s using the full size?
I don’t believe I need to add an extra image size, because as you say, the full-size image should be returned if the generated sizes aren’t large enough. I need to figure out why that isn’t happening, not do a workaround with a larger image.
I understand you’re saying that it’s handed off to WP in the case of no-cropping. However, it doesn’t matter whether I have cropping turned on or off. The slider uses the 1024w size on every possible crop setting (yes, I tried them all).
“If you enable cropping, we crop it based on the height and width of the setting you have at the top of the settings area. So if you set that to 1920px then it should crop to that.”
This is exactly what I did before contacting you. It’s using the 1024w size.
All right, thank you for letting me know. 🙂
Forum: Plugins
In reply to: [Autoptimize] Lazy load not catching all images?I think GPSI is correct about those images not lazyloading; if I use the “Network” developer tool, I can see that those ones do load up front, despite having the right classes.
It’s definitely related to W3TC though. AO works completely when W3TC is deactivated, and GPSI then sees those images as being lazyloaded. It seems there’s still some conflict between the two plugins. Hopefully, that will be resolved when W3TC updates their code.
In any case, it’s better this way than to have images not load at all 🙂
- This reply was modified 7 years, 1 month ago by Fox Lee.
Forum: Plugins
In reply to: [Autoptimize] Lazy load not catching all images?Sorry, it looks like I spoke a little too soon—I forgot I was trying out Litespeed Cache instead of W3TC. If I reinstate W3TC (with its minification turned off, of course), the images do load and receive the “lazyloaded” class. However, Pagespeed Insights still reports that certain images (the “mysterious teacups” and the second and third slider images) aren’t being lazy loaded.
Forum: Plugins
In reply to: [Autoptimize] Lazy load not catching all images?Okay, I checked out my header code and though it doesn’t cause errors, it was a bit outdated. I was adding the header using header_image(), which seems to have stopped AO from accessing it. I switched to using the_custom_header_markup() instead, and now AO is successfully loading the header image too. Hopefully this info will be useful if anybody has a similar problem in the future.
Anyway, that means everything is now working smoothly under your AO beta! Thanks for sticking with me until everything was solved. I really appreciate your hard work 🙂
Forum: Plugins
In reply to: [Autoptimize] Lazy load not catching all images?My apologies for the late reply—I had an unexpectedly busy week. After updating Autoptimize to 2.5.1-beta-2, I’m getting the same results as you—only the header image is having a problem now. I’ll compare my header code to the default themes and see if there’s anything that might be circumventing AO.
Thank you!
Forum: Plugins
In reply to: [W3 Total Cache] Interference with Autoptimize minificationSorry for the late response, thank you to both of you for your help with this 🙂
Forum: Plugins
In reply to: [Autoptimize] Lazy load not catching all images?I’m afraid I don’t see any difference using the beta, compared to live version.
Forum: Plugins
In reply to: [Autoptimize] Lazy load not catching all images?That’s correct, even with W3TC’s minification turned off, it appears to force its way in. If I disable W3TC entirely, AO’s minification works as expected. I’ll raise the issue in W3TC support too, since presumably this is really their problem.
Thank you for the beta, I’ll try it out and report back!
