Social media image URL validation fails after translating post with "Polylang Pro" plugin

[villeveikkoilen]

Describe the bug When a post has social media image URL, and the post is translated to another language with "Polylang Pro" plugin, I can't publish or save the newly created post as draft. Turns out, social media URL is copied when creating the new post. The "input" element "type" attribute value is "url", and clicking publish button triggers browser form validation, which fails, because the input value should be a valid URL. You can't see the form validation error message, unless you happen to have "Some" tab open in SEO-settings. If you want to keep input element type as "url", the value should be an absolute path to image, otherwise the type should be "text", I guess.

https://github.com/sybrew/the-seo-framework/blob/572b9d5660d5d4d26f9c8462053d177109fd76fe/inc/views/edit/seo-settings-singular.php#L547

See MDN docs about element type "url"

How to reproduce the bug Steps to reproduce the behavior:

1. Edit post
2. Select social media image for it
3. Save post
4. Translate post to another language
5. Try to click "Publish" or "Save Draft" buttons

Expected behavior "Publish" and "Save Draft" buttons should work.

Additional context

• WordPress 5.5.3
• The SEO Framework 4.1.1
• Polylang Pro 2.8.4
• Browsers: Firefox 83, Chrome 87

[sybrew]

TSF already has protection for this: You can't change the tab or close the meta box if there are errors in the form. However, this won't help if the inputted data is incorrect when you open the editor.

Is the URL transformed from a fully-qualified URL to something else after you translate the post? If so, could you show me the before and after URLs? Thanks!

[villeveikkoilen]

Hi, the URL stays the same when translating the post, for example: /wp-content/uploads/2020/10/cropped-image_final-1.jpg

I've created a temporary workaround to this by changing the input "type" attribute value to "text", because the value isn't fully-qualified URL.

[sybrew]

Hello!

It's not It should not be possible to save the URL as /wp-content/uploads/2020/10/cropped-image_final-1.jpg, so something must've changed it during the POST-saving request.

Is there a "relative-URL"/"SSL-fixer"-type plugin active on the site?

[villeveikkoilen]

Hi, I'm not aware that there would be plugins like that installed. I have to look into this, and try to find out if some other plugin is causing this.

[villeveikkoilen]

Hi, turns out there's WP_CONTENT_URL constant set in wp-config.php to enable relative URLs to /wp-content directory, so that's why every time the image is chosen, it returns and saves a relative URL to image. For some reason I can save post after setting the image and there's no validation errors. The validation error is triggered only when I translate the post.

I think the plugin should handle relative URLs for the image?

[sybrew]

I missed the follow-up on this issue. Rereading the request, I'll add my closing thoughts from which we can work in a future issue.

Relative URLs aren't possible because not all social networks can interpret that. Still, we could forward a relative URL as-is (without domain) to the og:image tag, but that'd require any parsing platform that supports it (e.g., Facebook, WhatsApp, X, Discord) to be considerate of where the URL is found. When they do not use the canonical URL but the request URL, this may inexorably lead to cache poisoning, where someone points another domain to the site, and then shares the URL with the attachment containing something nefarious. Then, when your real URL is shared, the platform will reuse the nefarious attachment. So, although this is an unlikely scenario, it is still blocking the feature.

Resolving relatively given URLs could be possible, but we have never had this request again. And, resolving relative URLs to fully qualified URLs adds much complexity, for which we need to redesign the image generator, post meta storage sanitization, etc. Relative URLs are often frowned upon for this reason.