- I suppose your solution is to use @htmldecode function. Well, that may working for now, but actually it must be used if you take a parameter from some URL, and that parameter is actually an http address to somewhere. And in that case you can use @htmldecode. But in other cases (like http://знаки-зодиаков.рф) it's not safe actually. Cause there could be a special page like `http://знаки.рф?p=(html encoded special parameter that changes the page displayed)`. That's an example but the idea is like that.
I know a way how to overcome this, but anyway, it looks like a hack. If you copy and paste the link from the preview in Google Chrome, it will show you the image without any problems:
What I think here is the same situation as with the <audio> tag. It wasn't supported four days ago, but now telegram can handle it. Why there should be an excepti
- Type of issue
- IV not generated for target page
- Feb 11, 2019
From The Checklist:
"Important: We will accept issues requesting to generate IVs for pages with content previously deemed unsupported if you include a link to a template that fully supports the content in question"
Some articles of the site contain images which "src" attribute refers to cyrillic domain (знаки-зодиаков.рф). IV engine consistently fails to retrieve such images.
In my opinion:
IV engine should handle such urls by itself, but it does not.
We would have a right to give up if the case was unique, but quick google search gives other articles with such images:
These are RECENT articles - the end of 2018 (and I believe more are coming soon).
Template authors can handle such cases in t