joejoe04

HI @tlcjohn,

Glad to hear you were able to resolve the issue and thank you for posting the solution!

Feel free to mark the thread as resolved if you’d like.

Hi @supr3m3dalek,

Glad you found the solution! Feel free to mark the thread as resolved if you’d like.

Glad to hear it worked for the navigazione element!

Regarding the navigation under the primary element, I do see you added the navigazione2 CSS, but I don’t see an HTML element with that class applied, so I think that’s why it’s not working.

I think the solution to this one might be a bit more complicated because the margin in this case is being applied to each of the cards with either .page or .post classes applied as we see here:

View post on imgur.com

The reason that it’s a bit more complicated is that depending on the screen width, there may be 1, 2, or 3 of those elements in the bottom row. Above we see 2, but here in a wider screen, it’s 3:

View post on imgur.com

So we need to use come media queries to adapt the CSS based on screen width. I think something like this could work:

@media only screen and (min-width: 1421px) {
  main .post:nth-last-of-type(-n+3), main .page:nth-last-of-type(-n+3) {
      margin-bottom: .5em;
  }
}

@media only screen and (min-width: 701px) {
  main .post:nth-last-of-type(-n+2), main .page:nth-last-of-type(-n+2) {
      margin-bottom: .5em;
  }
}

@media only screen and (max-width: 700px) {
  main .post:last-of-type, main .page:last-of-type {
      margin-bottom: .5em;
  }
}

In my testing, this applied the .5em margin-bottom to the correct number of the cards depending on the width of the screen.

Let me know how it works for you and we can make some changes if needed.

Hi @therobgregory,

I took a look at the CSS files being loaded for the page you mentioned, and I only see this one:

https://caslweb.magnifica-online.co.uk/wp-content/uploads/siteground-optimizer-assets/siteground-optimizer-combined-css-d0f60c7921fe4b04a701639003ad3a8a.css

View post on imgur.com

It looks like your site is using Siteground’s Optimizer plugin. Their documentation shows that they have an option to combine all CSS files into just one single file.

It’s possible this optimization isn’t being applied when it comes to your localhost site, so that could explain why you still see the individual CSS files you mentioned being loaded there.

Combining CSS files can be somewhat helpful for optimization, however, with HTTP2 (which your site does use), that’s not nearly as important as it used to be.

If this combination of CSS files is causing you issues or you’d just prefer it’s not done, I think you could try disabling this option in the Siteground Optimizer plugin settings and see if that gets the individual CSS files loading for the live site.

Let me know how it goes. I’m happy to help further if needed!

@sacconi,

I don’t see anything related specifically to numbers in the WordPress guide on sanitization, so I think using sanitize_text_field should be used.

If needed, you might also do some validating that the value submitted is acceptable. This would likely be unique based on what your application requires. The documentation linked above contains some examples of how that can be done.

The link to the page you submitted isn’t a valid page that I can use (https://user-edit.php/?), so if you’d like to share that, I’d be happy to take a look and see if there’s anything else to add.

Hi @sacconi,

It looks like there is margin-bottom: 25px; style applied to the div element with a class of navigazione. Here is where I’m seeing applied only for desktop view (minimum of 769px width):

https://i.vgy.me/ZSWQvy.png

The style is added inline in the HTML source on line 669:

https://i.vgy.me/mcaTzn.png

I don’t see this style being applied for mobile views with smaller screen widths.

I’m not sure it’s possible for me to know how this style is being added there. It’s just there in the HTML and I don’t see any clues about what is adding it.

If you know what is adding that (seems likely it could be your theme), then you can see if there’s a way to change it using the theme or plugin settings.

Otherwise, you might try using your theme’s customizer or a plugin that allows for adding custom CSS to add styles to override this. Maybe something like this could work:

@media only screen and (min-width: 769px) {
  .site .navigazione {
    margin-bottom: 0px;
  }
}

You could set the margin to whatever value you’d prefer.

Let me know if there is any part of your question I misunderstood or did not address and I’ll be happy to help further if needed.

@kevinc81

No problem about the delay, and I would agree, those kinds of modifications would not be worth it to me either. Glad we could at least get you to full optimization of images and display of most in WebP format.

Best of luck to you with your website!

@kevinc81,

Glad to hear you have gotten most of your images to load properly in WebP format!

Those last 2 images might be tough to load in WebP format though, since they are CSS background images. The rewrite rules option would work for both <img> tags in HTML and CSS background images, but since you are using a CDN, this is not an option.

I noticed the CSS background images are being added inline in the HTML. Is your theme doing this via the customizer?:

<div class="image-slider clearfix rocket-lazyload lazyloaded" title="Hokkaido - Sapporo: Hokkaidō-jingū" style="height: 575px; background-image: url(https://cdn.karnoden.fr/wp-content/uploads/2019/11/hokkaido-sapporo-hokkaido-jingu-kevin-carol-min.jpg);" data-ll-status="loaded"><div class="container"></div>

If it is your theme doing this, you may want to contact the theme developer and request they add support for WebP with a fallback to JPG or PNG for browsers that don’t support it.

Given that all your other images are now loading properly as WebP, I don’t know that you need to do anything else with query strings, but I’ll explain what I’d do in case you need to test something out in the future. Wherever you are entering the image URL, just add a unique query string at the end. For example, if you were going to enter https://cdn.karnoden.fr/wp-content/uploads/2019/11/hokkaido-sapporo-hokkaido-jingu-kevin-carol-min.jpg, I would enter something like https://cdn.karnoden.fr/wp-content/uploads/2019/11/hokkaido-sapporo-hokkaido-jingu-kevin-carol-min.jpg?test=123. Then each time you want to test a change you made, just change that number to something new, and you’ll be sure you’re being served a non-cached image.

Hope this helps, and let me know if you have any other questions.

Hi Kévin,

No problem at all, I’m happy to help if I can, and hopefully we can get you to an acceptable solution. I’m not sure you’re going to be able to get to 100% of your images being served as WebP if you are using both a CDN and CSS background images, being that the rewrite rules option is needed for CSS background images and rewrite rules are not compatible with CDNs.

I see that you tried disabling your CDN and using the rewrite rules, which did not work for you. I would ask though, did you try appending a query string to the background image URLs (like https://cdn.karnoden.fr/wp-content/uploads/2019/11/hokkaido-sapporo-anciens-bureaux-du-gouvernement-de-hokkaido-kevin-carol-min.jpg?test=123)? I ask because I know browser caching can really be stubborn in using images already cached (in this case the JPG version), even if you have the developer tools panel open with cache disabled, and you do an “Empty cache and hard reload.” Might be worth testing.

How were you testing whether the images were served as WebP? I ask this because when using the rewrite rules option, the image URLs will still show in the source code as though the JPG version is being linked to. To test if WebP images are loading for sure, you’d want to add a unique query string to the CSS background URLs (to prevent any caching issues like above), go to the “Network” tab in developer tools, and click the “Img” or “Images” tab, then reload. You should see your CSS background images in the list of images that show up, and the “Type” should show as webp, if it’s working properly. You may already know this, but figured I’d make sure.

I really can’t be sure what’s happening when you have the <picture> tags option enabled that would cause your <img> tags to not be converted to <picture> tags. Could have something to do with a LazyLoading option enabled, either through your theme or WP Rocket maybe? There could also be some issue with how your theme and Imagify are interacting. Sometimes, themes load the HTML after Imagify has already checked for <img> tags (though I’m not sure that’s the case here because while no <picture> element is created, the URLs are being changed from the JPG ones to the WebP ones, I assume by Imagify or WP Rocket).

I can say, when I test similar code to yours in my test page:
<img width="455" height="341" src="https://mydomain.com/wp-content/uploads/2020/07/fireworks-01.jpg" class="lazyloaded" alt="test" title="test" sizes="(max-width: 455px) 100vw, 455px" srcset="https://mydomain.com/wp-content/uploads/2020/07/fireworks-01.jpg 455w, https://mydomain.com/wp-content/uploads/2020/07/fireworks-02.jpg 300w" data-ll-status="loaded">

I get the following output:

<picture>
<source type="image/webp" srcset="https://mydomain.com/wp-content/uploads/fireworks-01s.jpg.webp?x=3737 455w, https://mydomain.com/wp-content/uploads/fireworks-02s.jpg.webp?x=3737 300w" sizes="(max-width: 455px) 100vw, 455px">
<img src="https://mydomain.com/wp-content/uploads/fireworks-01s.jpg?x73403&x=3737" sizes="(max-width: 455px) 100vw, 455px" srcset="https://mydomain.com/wp-content/uploads/fireworks-01s.jpg?x=3737 455w, https://mydomain.com/wp-content/uploads/fireworks-02s.jpg?x=3737 300w">
</picture>

This output uses the <picture> element to solve the issue you are having with the lack of support for Safari and IE11-, as the first <source> element serves the WebP image for browsers that support it, while the <img> element serves the JPG image for browsers like Safari and IE11-.

However, when I try the same bit of code as above, only I change the URL so it’s linking to an image on a subdomain, like https://sub.mydomain.com/wp-content/uploads/fireworks-01s.jpg?x=3737, I get a similar output to what you currently get (No <picture> element), only my image URLs are not converted to the WebP versions and the JPG image is loaded. So I think possibly the fact that your image urls are not on your primary domain could be causing issues. I tried adding https://sub.mydomain.com to Imagify’s CDN URL specification field in options, and that didn’t help.

I might try uploading a test image to your primary domain, https://karnoden.fr, making sure it’s optimized by Imagify and has a WebP version created, and then creating a test page with the same HTML code you are using for the images on your home page (only in this case, you’ll be linking to an image on your primary domain), to see if your <img> gets converted to a <picture> element in that scenario, as is supposed to happen. If that works, then at least we’d know the subdomain is the issue.

If that doesn’t work, and since you are using a CDN, what I would probably try next is to disable other plugins one by one, while also appending a unique query string to one of the images to break any caching issues, and then test refreshing the page to see if a <picture> element is created, as it is supposed to be. There could be some interaction between another plugin and Imagify that is causing issues. You could also try temporarily changing to a backup theme to see if <picture> elements are then generated.

Let me know what, if any, of this helps, and we can keep trying to get closer to a solution that works for you.

• This reply was modified 4 years, 4 months ago by James Huff.
• This reply was modified 4 years, 4 months ago by joejoe04.
• This reply was modified 4 years, 4 months ago by joejoe04.

Hi @kevinc81,

I have a couple suggestions based on what I can see. I would start by asking which option you are using for display of WebP images, <picture> tags or rewrite rules? I’m not entirely sure either would work, though, given other elements of you setup. I see that you are using a CDN (though I know you said you disabled for now) and that you are storing your images on a subdomain, https://cdn.karnoden.fr. I tried doing that on my test setup (storing and linking images from cdn.mydomain.com), and neither option would result in WebP images loading. I think for this to work properly, the images either need to be stored on the same domain as your main website installation (for the rewrite rules option), or (for the <picture> tag option) on your main website installation or on a Pull type CDN (and you need to enter the CDN URL in the Imagify options page).

I would also say if you use the <picture> tags option, then there is no way to get the 1st and 2nd images you linked to display in WebP format, because they are displayed as CSS backgrounds. The <picture> tag option replaces tags with <picture> tags and provides elements inside for both browsers that support WebP and those that don’t. There is no way this option can swap out CSS background images. Given you are planning to use a CDN, you can’t use the rewrite rules option, which limits solutions for these 1st two images you linked.

Another question I would ask is are you entering the following HTML manually?

<img width="455" height="341" src="https://cdn.karnoden.fr/wp-content/uploads/2019/11/hokkaido-sapporo-toyohira-gawa-kevin-carol-455x341-min.jpg.webp" class="attachment-post-thumbnails size-post-thumbnails wp-post-image lazyloaded" alt="Hokkaido – Sapporo : Aper?u de la ville" title="Hokkaido – Sapporo : Aper?u de la ville" sizes="(max-width: 455px) 100vw, 455px" srcset="https://cdn.karnoden.fr/wp-content/uploads/2019/11/hokkaido-sapporo-toyohira-gawa-kevin-carol-455x341-min.jpg.webp 455w,https://cdn.karnoden.fr/wp-content/uploads/2019/11/hokkaido-sapporo-toyohira-gawa-kevin-carol-455x341-min-300x225.jpg.webp 300w" data-ll-status="loaded">

I ask this because I’ve never seen Imagify output something like that before, as they typically replace tags with <picture> tags that have <source> elements for WebP and a fallback tag for JPG or PNG when browser support requires it. I don’t believe the code I pasted above from your site will provide support for browsers without WebP capability, which according to https://caniuse.com/#feat=webp is about 20% of people (IE11-, iOS Safari, and Safari). I think the fact you’re using a subdomain may be preventing Imagify from replacing your image tags as <picture> tags, but even if that weren’t the case, you’d want to have your image tag with your src attribute pointing to the original JPG version of the image. Then Imagify takes care of formatting the <picture> element as needed to use WebP when possible, and JPG when not.

Hope I could at least provide some help. Let me know if I made any incorrect assumptions about your setup, and also if you have any questions about anything I posted.

• This reply was modified 4 years, 4 months ago by joejoe04.
• This reply was modified 4 years, 4 months ago by joejoe04.

Hi @brenew,

I have a couple ideas that might help.

Have you tried deleting the plugin, downloading a new copy, and then re-installing it, just in case what your plugin download was corrupted somehow?

Also, what method did you use to install this helper plugin, originally? I see that you linked to the .php file above. Did you try downloading the .zip file here to install the plugin?

I just installed the helper plugin using the .zip file and it installed without any errors on my end. I don’t have a multi-site setup to test at the moment, though. In searching about this specific error, for most other people, it’s due to the plugin being corrupted or downloaded incorrectly in some way or another.

Let me know if none of this solved your issue and I’ll try to come up with something else.

Joe

Hi @bobsouza,

I’d like to try and help if you’re still having this issue.

Have you tried testing if the webp version is being loaded by the page it’s supposed to be displayed on (even though you can’t see it on the page), by checking in the network tab of developer tools or in the HTML source code? Is a <picture> element there in the source code at all, or is there just nothing?

When you include the image in the page/post editor, are you using a simple <img> element linking to the jpg image, or are you using a <picture> element? I ask because I found that no image is displayed if I do something like the following:

<picture>
  <source type="image/webp" srcset="https://example.com/wp-content/uploads/2020/07/img-02.jpg.webp">
</picture>

I believe you’re suppposed to just use a simple <img> element, then Imagify takes care of converting that to the <picture> with all the different sources. I found that it will still work as long as you have an <img> element inside the <picture> element, but just mentioning this on the off chance it could apply to your situation.

Have you tried switching to the “Use rewrite rules” option instead of the “Use <picture> tags” option? If you try this, the image will still show up as the jpg file in the HTML source code, but the .htaccess rules will cause the webp image to actually be served. This might be the best option if possibly your theme or something else is leading to this issue.

It is a bit odd that it’s working fine on your testing server, but then not on the production server. Are there any differences between the two that you can think of that might cause this?

Could you provide a link to a live example of this so I could dig around a little bit and see if I can come up with any other ideas?

Joe

Yes, that worked.

Thanks for the quick response! I’ll give your plugin a nice review.

I can’t say that I’ve confirmed that relative URLs are acceptable, unfortunately. Would really be nice if the options page stated the acceptable or required format(s). It would also be nice if they just answered people’s questions on here. For being such a popular plugin, I am very surprised at how many questions go unanswered by them. This is not the first question I’ve asked which received no response.

I ended up using {wp_content_dir}/../sitemap_index.xml. If you view the settings file, other options use the {wp_content_dir} variable and ../ is valid URL syntax, so I’m just assuming it’s okay. I still don’t know how to test whether this is properly directing this option to my sitemap_index.xml file to specify which pages/posts to prime though.

Okay, got it. Thanks for all the help, you’ve been great. Honestly, I’d much prefer you told me this was a dumb question than simply ignoring me.

• This reply was modified 7 years, 9 months ago by joejoe04.