Forum Replies Created

Viewing 15 replies - 16 through 30 (of 99 total)
  • Looks like this may have been fixed in the latest release today (v4.22.0):-

    Fix: Keep the loading=lazy attribute on IMG tags when delivering next-generation images using the picture method

    Thread Starter smartyp

    (@smartyp)

    Thanks ??

    Thread Starter smartyp

    (@smartyp)

    I was trying to avoid creating even more thumbnail images by using the existing ones ??

    ‘Medium’ is one of the built-in WordPress sizes (in Settings/Media) – by default it’s a max 300px wide and max 300px height. But it doesn’t crop to exact size, it keeps ratio – so it’s rarely ever actually 300 x 300.

    Thread Starter smartyp

    (@smartyp)

    Yes, all internal images do use the CDN.

    Ah, lots of useful filters, thanks ??

    So I’ve now used the crp_get_image_attributes filter to switch the output back to the CDN url. So posts using featured images now work as expected.

    For ‘use first image in the post’ (no featured image set) I also had to use the crp_thumb_url filter to switch the url from ‘www.’ to ‘cdn.’ so they would be treated as local urls. But I then hit a problem with wp_calculate_image_srcset (in crp_get_image_html) – which doesn’t return anything as there is no 300 x 300 image. So the full size image still gets output for these. It looks like wp_calculate_image_srcset only works on an explicit pixel size array too rather than any option to use named sizes!

    Thread Starter smartyp

    (@smartyp)

    I hard coded all the wp_get_attachment_image_src calls to use ‘medium’ instead of the width/height array, and that does fix the 1st problem. So the correct size thumbnails get output where featured images have been used (just not using the CDN).

    Re: CDN. I guess one solution might be to have a user option to set a base CDN url, which is then used a) for the check to see if an image is a media library image (i.e. image url is CDN url + ‘/wp-content/uploads’), and b) to also set all the image output URL’s.

    Thread Starter smartyp

    (@smartyp)

    OK, I dug into the code a bit.

    [1] In e.g. crp_get_the_post_thumbnail, wp_get_attachment_image_src isn’t returning the correct thumbnail url. Not sure if this is a WP bug or intended behaviour, but if you pass the named thumbnail in (“medium” in this case) it works, but if you pass an explicit size (300×300 – as CRP is doing) it doesn’t. Both return the correct thumbnail image sizes (in the test case I was looking at, 300×164) but the source url returned is the full size image if you pass 300×300 and the correct thumbnail url if you pass “medium”.

    [2] Not 100% sure on this one yet – but this site is using a CDN for images. And in crp_get_attachment_id_from_url there is a check for attachment_url against baseurl – but in this case attachment_url = cdn.example.com which doesn’t match the baseurl of www.example.com. I think that causes some problems, but the full size image output is then also being served from the site itself and not the CDN.

    Hope that helps ??

    • This reply was modified 3 years, 8 months ago by smartyp.
    Thread Starter smartyp

    (@smartyp)

    I can’t share the url, but let me know what details/source code would be useful.

    Settings are:
    Location of the post thumbnail: Display thumbnails inline with posts, after title
    Thumbnail size: medium (300×300)
    Thumbnail width: 300 (or blank as above)
    Thumbnail height: 300 (or blank as above)
    Hard crop thumbnails: off (tried on)
    Generate thumbnail sizes: off
    Thumbnail size attributes: Use HTML (tried CSS and none)
    Get first image: on

    Forum: Plugins
    In reply to: [Yoast SEO] Indexing error

    Or you could just click the ‘Page changed? Request Indexing’ link.

    Forum: Plugins
    In reply to: [Yoast SEO] Indexing error

    If you check again now, this page has been indexed by Google ??

    Same here. Given the lack of support here in general from the developer, and in particular no reply at all on this highly concerning issue AND no response by email either, I’d strongly recommend everyone not only disable but fully delete this plugin. There are other options.

    Thread Starter smartyp

    (@smartyp)

    You missed the point completely, again. This is the problem when one person doesn’t own a support thread and everyone just randomly chimes in, there’s no continuity, no consistency.

    Read the QUOTES in my previous comment. One of you says you’ll pass it on to the devs – so I say thanks – then the next one of you says file a bug report..!?

    Fix it or don’t – I’m done.

    Thread Starter smartyp

    (@smartyp)

    You: it’s something that we can bring to the attention of the developers.

    Me: thanks

    You: we’d love to forward this to our development teams… so please submit a bug report…

    …sound of head bouncing off bricks…

    Thread Starter smartyp

    (@smartyp)

    …what you’re asking for — plugin changes and specific code for your site…

    Almost walked away, but that’s just not reflective.

    I’m not asking for changes – I’m pointing out a bug (or ‘functional gap’ if you prefer).

    Nor am I asking asking for specific code for my site – it’s generic code applicable to thousands of sites (that are either not using the Yoast breadcrumbs or don’t realise/care that their breadcrumbs don’t work properly).

    If you’re able to refer this to the developers that would be useful – thank you.

    Thread Starter smartyp

    (@smartyp)

    In regards to WordPress being installed in a subfolder, there are many types of users who use WordPress exclusively for a blog and have their main site in the root of the domain.

    Not a surprise to me given that’s the specific case we’ve been talking about here…

    In addition, some other users install the WordPress core files into a subdirectory but still have the site served from the main domain

    Yes, that’s the ‘other’ case I alluded to above…

    So for all of that you’re just agreeing with me then? There aren’t “many other reasons” – there’s just 1 (…bangs head against wall again…).

    Yup, same link again – not very helpful.

    New link – partial solution on stackexchange..!

    You’d think given “there are many types of users who use WordPress exclusively for a blog and have their main site in the root of the domain” that either Yoast would work for this use case, or you would have published a functioning workaround specifically for it.

    Thread Starter smartyp

    (@smartyp)

    I appreciate the detailed steps, but unfortunately Solution #2 doesn’t really work because it doesn’t do anything to fix the schema, which is of course important.

    Solution #1 might work – but it seems you don’t have a working example anywhere.

    I don’t think there are ‘many other reasons’ for WP being in a subfolder though – I can think of only 1 other reason and that’s very rarely done compared to what’s discussed here. So whilst it may not be safe to assume every subfolder install is the same, it’s wrong for this setup.

    But I’ve beaten my head against the wall enough so I’ll politely decline the invitation to create a ‘feature request’ ??

Viewing 15 replies - 16 through 30 (of 99 total)