matgas85

Thank you, appreciate that.

Hi, thank you for the latest update, but it looks like there is still a vulnerability with version 11.1.0

https://patchstack.com/database/vulnerability/disqus-conditional-load/wordpress-disqus-conditional-load-plugin-11-0-6-cross-site-scripting-xss-vulnerability

Kind regards

Mat

It’s ok I’ll wait for now and see if you find a solution.
Thanks!

I just checked and on my site, the - becomes -- also on articles that are not converted to blocks.

Right, makes sense!

Now I’m going to close 2019 with an even more silly problem.

I’ve noticed that all my H2 titles that contain one dash (-) now have a double dash (- -).

If I disable the plugin, the double dash reverts to a single dash.

This seems to happen in the text too.

see example here:
https://mirrorlesscomparison.com/sony-vs-sony/a7riii-vs-a9/

Any idea? ??

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

Hi,

I don’t know why but the Firefox inspector shows a different code that the one you see (it’s probably me doing something wrong). It’s only when I click the grey EVENT button that I can find some trace of the nocookie URL.

See screenshots below:
https://www.dropbox.com/sh/qph6a1a4v07yxbv/AAC_ExAhByuf5NoIstPNbtlua?dl=0

If I only click “show source” in Chrome then there is no trace of the nocookie url and that’s what fooled me to begin with.

But when editing the article, I can see that the nocookie code now so I guess it was a false alarm after all.

Many thanks, again! Your patience and prompt support deserves five stars.

Ok, that is clear now.

Well, I might have worried for nothing, but thank you very much for your support. Really appreciate it!

I’m afraid I’m not sure exactly what you refer to when talking about (data-)srcset and (data-)sizes.

But perhaps I’m the one getting confused. If I want to make sure that the article is loading the Large size images (700×400) instead of the full size ones, what is the best method to check that?

I remember that before, it was easy: with any browser, I would just right click on the image and choose either copy image address or open image in a new tab, and the Large size image would appear rather then original one. Perhaps that’s not what happens anymore, and the browsers load the original image instead?

Sorry, I should have been more specific.

If you go here:
https://mirrorlesscomparison.com/galleries/sony-a7r-iv-sample-photos/

and scroll down to the first images (the ones taken in the woods), if I right click on them and choose open image in a new tab, or copy image address, it should show the Large size image that would end with -700×400.jpg. Instead it looks like the full size has been embedded in the article.

In this other example:
https://mirrorlesscomparison.com/guide/sony-a7-a9-astrophotography-settings/

If you scroll down to the image of the milky way with the boat and do the same, you get this:
https://mirrorlesscomparison.com/wp-content/uploads/2019/12/Sony-A7iii-milky-way-photo-sample-1-1536×1024.jpg

It’s https://mirrorlesscomparison.com/

Thanks

Hi, any feedback on this?

I like the plugin and I really want to keep it.

Thanks!

Quick follow-up.
Called Godaddy support again, they disable my htaccess file and the website came back online. At the beginning I could only access the homepage. Every other pages would give a server error and the custom login page wasn’t accessible either (i guess becasue the htaccess file was gone so the itemes options written there as well).

I went into the FTP, disable the plugin by renaming it and the wbesite started to work fine. I then re-install iThemes and disable the option that allows it to write on htaccess file.

So the htaccess file seems to have been the cause although I can’t confirm this 100%.

Perhaps all this could be useful for someone else (but I hope you will never get the same problem).