Cross-Origin Request Blocked Error

  • Hi, we’re running WP 6.5.5 and SEOPress 7.9.2. While testing some new content, I noticed the editor is throwing a couple of SEOPress-related errors in the console:

    • Blocked loading mixed active content “https://(sitename-redacted)/wp-content/uploads/twitter-card.jpg”
    • Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://(sitename-redacted)/wp-content/uploads/twitter-card.jpg. (Reason: CORS request did not succeed). Status code: (null).

    When I go to the Social tab of the SEO fields on the editor screen, I see the message “File error. Please choose another image.” (The image is displaying, though, despite the error.)

    This looked like a minor fix that I hope you’ll be able to address in an upcoming release. Thanks!

    Edited to add: it looks like variants of the issue are cropping up. Just created a new page as a test, and I’m getting a 404 in the console. This is before saving/publishing the page. The Facebook image is missing, with the message “File error. Please choose another image.” Looking at the source code for the image, the img tag is coded as a relative path, src=”assets/images/fb-card.png”, so the browser is trying to look in /wp-admin/assets/ for the file. The Twitter image is also missing, with the img tag src=”” and the error message “File URL is not valid.”

    When I save/publish the page, these errors are replaced with the one I initially reported.

    Images were uploaded for these in the global settings, BTW.

    The page I need help with: [log in to see the link]

Viewing 3 replies - 1 through 3 (of 3 total)
  • Plugin Author Benjamin Denis

    (@rainbowgeek)

    Hi,

    can you share the post URL with the issue please?

    Do you use a CDN or something similar that changes the default URL of a media file when you upload it to the media library?

    Thx

    Thread Starter susanwrotethis

    (@susanwrotethis)

    1. Well, no, seeing as it’s a problem in WP Admin, specifically on the post.php screen.
    2. It may help you to know that this is not an issue for higher-level roles (Editor, Administrator) but is for custom roles. We have a series of custom roles that have Editor-level access to create, edit, delete, and see private entries, but only for the specific custom post type the role is associated with. (It doesn’t seem to be a CPT issue, as the custom role for editing Posts is having the same problem.) If you recently made a change involving a current_user_can() check, it may be looking for standard caps only. I reported similar issues to another plugin at the same time where that was the case.
    Plugin Author Benjamin Denis

    (@rainbowgeek)

    Can you confirm your user role has the edit_post capability?

    Can you share the associated caps of your user role with the issue?

    Can you share the URL of your site to check how your URL are built please?

    Thanks

Viewing 3 replies - 1 through 3 (of 3 total)
  • You must be logged in to reply to this topic.