Bloggd

Update:

Fixed it by editing this file, and commenting out the equivalent lines:

wordpress-seo/src/integrations/front-end/category-term-description.php

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

+1

Please add the feature where users can specify a custom sitemap file name.

• This reply was modified 5 years, 11 months ago by Bloggd.

Issue resolved in v3.3.3.
Thank you!

Will do. Thanks, Christine.

Hi Christine,

<quote>Social Warfare takes over only if the Social Warfare custom options are filled in. Otherwise, Yoast takes over.</quote>

However, this is not happening in my case. Yoast generates the OG tags automatically, but Social Warfare overwrites it. Fyi, I started a new post here.

Topic: Social Warfare – Wrong og:Description | www.remarpro.com

Note: This problem happens if I show social buttons at the bottom of the post. If I select “Above” option, then Social Warfare plugin erases the OG:Description tag completely.

Interesting. PHP 7 here. After updating the Plugin, it has “unhidden” all the posts that were earlier hidden. Reverted back to 1.22.

@tesla55: You can get it from the “Developers” tab here.

The latest version didn’t break my site, but it has unhidden *all* the posts which I had hidden so far. Reverted back to 1.22.

Brian, Think you’re correct about the requests. But I’m wondering if there is a filter I can add for CDN Enabler to skip rewriting the assets URL when in preview mode (“?preview=true”)

When I upload an image, it goes to Imagify’s servers, it does the reprocessing and sends back the file. So, that’s the first hit. Second hit is when I preview the post, but it’s only after I optimized the image. That’s what stumps me.

Only possibility I can think of is Imagify is doing 2 requests per file (for some reason) triggering the CDN to cache it.

For now, I’m optimizing the images offline and then uploading it.

Thanks.

I can repro this every time I make a new post. Here is my most recent post.

Image from CDN (46 KB)
Image from original server (20 KB)

This is the procedure I use:

Create a New post > click “Attach file” > Upload the image (it automatically is optimized) > Save the post and Preview it.

I haven’t tried this way though:

First, upload the image via Media Library > Create a New post > Insert the image from library > Save the post and Preview it.

I’ll update this post after doing a bit more testing in all angles to rule out any caching issues here. Request to keep this thread open for 1 more day.

Thanks.

Brian,

I’m uploading PNG files using the Media Library, and Imagify optimizes it as I upload the files. After I craft a post and preview it, the images URLs are rewritten correctly, but the CDN copy has the versions of files that are uncompressed or unoptimized (the ones I initially uploaded).

I’m saying this after comparing the files in the CDN link with the optimized one in the server. I’ve to open the KeyCDN dashboard and purge the image URL every time.

Some suggestions:

1. Try Autoptimize Plugin (which is superb). It can clear up 3 main parameters there. (defer JS, remove query strings, CSS minification, concatenation). Plus reduces the number of requests by a great deal.

2. See if enabling gzip of .WOFF font file helps. GTMetrix says you can save 23 kb there. Or load fontawesome font from global CDN. It can be quicker.

Once you’ve done this next step is to re-test the site and then look at the waterfall report there.

Hi there,

See if info in these links help.

https://stackoverflow.com/questions/29140790/azure-cloud-service-cdn-font-cors-error
https://www.devtrends.co.uk/blog/hosting-web-fonts-in-azure-blob-storage-using-the-new-cors-support

Case resolved. The host seems to have upgraded Apache as of late. Applying the first .htaccess (for Apache 2.3.9 and up) seems to have fixed it. Thanks for the assist!

Thanks Brian. I did that. Upon checking the HTTP headers, it still shows X-Cache-Handler: php. So PHP is not being bypassed by the .htaccess code. (URL) checked with KeyCDN’s Curl tool.