Cloudflare R2 problem

  • gosiaeu

    (@gosiaeu)


    1 week, 2 days ago

    Hello Thomas,

    I have a problem with importing files from Cloudflare R2 using External files in Media Library 5.3.0 together with the S3-compatible platforms extension.

    The connection to Cloudflare R2 works correctly. The plugin connects to the bucket, displays its directories and files, and allows me to select files for import.

    The R2 bucket is publicly available through a Cloudflare R2 Custom Domain.

    However, when I add a file from R2 to the WordPress Media Library, with “Import the external file as a real file” disabled, the plugin still downloads the physical file to the local WordPress uploads directory.

    In File Info the file is correctly recognized as:

    Source: Cloudflare R2
    External file: Yes

    but at the same time it shows:

    Hosting: File is locally hosted

    I would like the physical files to remain exclusively in Cloudflare R2 and WordPress Media Library to reference them as external files, without creating local copies.

    I have also checked the plugin code while troubleshooting. It appears that the Cloudflare R2 integration determines whether a file is public by checking the R2 storage/API endpoint. In my configuration, however, public access is provided through a Cloudflare R2 Custom Domain, so the file appears to be classified as non-public and consequently as locally hosted.

    Could you please confirm whether Cloudflare R2 Custom Domains are currently supported for external files without local copies?

    If so, how should the Custom Domain be configured in the plugin?

    If this is currently not supported, would it be possible to add support for a Cloudflare R2 Custom Domain / public URL?

    My intended setup is to use one central Cloudflare R2 media repository for several WordPress/WooCommerce websites, with each website referencing the same external media files without storing its own physical copies.

    Thank you for your help.

Viewing 10 replies - 1 through 10 (of 10 total)
  • Plugin Author threadi

    (@threadi)

    1 week, 1 day ago

    Hey,

    thanks for your question and the detailed description. Actually, it’s not yet possible to use Cloudflare’s custom domain for external files.

    I just added that feature to my development environment. With the next update to the AWS plugin, you’ll be able to specify the custom domain for Cloudflare R2 as well. Once it’s specified and reachable, the files will be treated as externally hosted.

    If you want to offload images this way, I’d at least point out the proxy included in the plugin. This ensures that the files are still stored locally in a cache so they can be delivered to website visitors efficiently and in compliance with data protection regulations. The original files, of course, remain with Cloudflare. If you want to disable the proxy, you can do so in the plugin’s settings. Please note, however, that in that case, the images will not be resized and will no longer be delivered to visitors in a way that complies with data protection regulations.

    I’ll need to run a few more tests before I can release the update with the above-mentioned change. I hope to get that done over the weekend and will check in with you again 🙂

    Plugin Author threadi

    (@threadi)

    5 days, 8 hours ago

    With the recently released version 1.1.0 of the AWS plugin, you’ll be able to connect to Cloudflare R2 using a custom domain. If you already had a connection saved, delete it and create a new one (since the custom domain is being added as a new value).

    It would be great if you could let me know if this works for you. 🙂

    Thread Starter gosiaeu

    (@gosiaeu)

    4 days, 15 hours ago

    Hi Thomas,

    I did some more testing with version 1.1.0 and I think I have now narrowed the issue down much more precisely.

    The new Cloudflare R2 custom domain support does work, but only under a specific condition.

    My custom domain is correctly configured and saved. I have also verified directly from the WordPress server that a newly uploaded R2 file is publicly accessible through the custom domain and returns HTTP 200.

    What I am seeing is:

    1. If I open the Cloudflare R2 connection, enable “Save these credentials as external source”, save it and then import a file, everything works correctly:

    • the External URL uses my custom domain,
    • Hosting shows “File is extern hosted”,
    • no local copy or thumbnails are created in /wp-content/uploads/.

    I verified the last point directly on the server via SSH.

    2. However, when I return to the Cloudflare R2 connection later, “Save these credentials as external source” is disabled again.

    The Custom Domain field itself is still populated, so the custom domain setting has been saved.

    If I then perform another import without enabling and saving “Save these credentials as external source” again, the file is once again treated as locally hosted and WordPress creates local copies in /wp-content/uploads/.

    If I enable and save “Save these credentials as external source” again immediately before importing, external hosting works again.

    So at the moment it appears that I would have to enable and save “Save these credentials as external source” before every import in order for the configured custom domain to actually be used for external hosting.

    Could you please check whether the state/data required for the custom domain is not being persisted or passed correctly between requests?

    I can provide screenshots and logs if needed.

    Thank you!

    Thread Starter gosiaeu

    (@gosiaeu)

    4 days, 14 hours ago

    Hi Thomas,

    thanks again for adding the custom domain support in version 1.1.0. I have now tested it further and found two issues.

    1. Custom domain / external hosting setting is not persistent

    When I connect to Cloudflare R2, enter the custom domain and enable “Save these credentials as external source”, the imported file is correctly recognized as externally hosted.

    The file info then shows:

    • Source: Cloudflare R2
    • Hosting: File is extern hosted
    • Proxy: disabled
    • External URL: the correct URL using my R2 custom domain

    However, when I return to the Cloudflare R2 connection screen, “Save these credentials as external source” is disabled again.

    If I import another file without enabling and saving this option again, the file is copied to the local WordPress uploads directory and is treated as locally hosted.

    So at the moment it looks as if I have to enable/save this option again before every import in order to get a truly externally hosted file.

    2. Externally hosted images do not display correctly as WooCommerce product images

    I also tested an image that was successfully imported as externally hosted and used it as a WooCommerce product image.

    The custom-domain URL itself works correctly. The browser requests the image directly from the custom R2 domain and receives HTTP 200.

    The generated HTML also contains the correct external URL, for example:

    src="https://[custom-domain]/test.jpg"

    However, the generated <img> element has:

    width="0"
height="0"

    As a result, the product image is invisible on the frontend.

    I tested this directly in Chrome DevTools. When I temporarily override the image dimensions, for example:

    width: 400px !important;
height: 400px !important;

    the externally hosted image immediately becomes visible and is loaded correctly from Cloudflare R2.

    So the R2 URL and delivery through the custom domain appear to work correctly, but the image dimensions/metadata provided to WordPress/WooCommerce seem to be 0 × 0.

    I am currently using:

    • External files in Media Library: 5.4.0
    • External files from AWS S3-compatible platforms: 1.1.0
    • Cloudflare R2 with a custom domain
    • image proxy: disabled

    Could you please check whether both behaviours are expected, or whether there is still an issue with saving the R2 external-source configuration and/or generating image metadata for externally hosted R2 images?

    If useful, I can also provide screenshots, logs or the attachment metadata from WordPress.

    Thanks again for your help and for implementing the R2 custom-domain support.

    Plugin Author threadi

    (@threadi)

    4 days, 5 hours ago

    Hi,

    Thanks for your feedback. I’ll try to address each point individually.

    However, when I return to the Cloudflare R2 connection later, “Save these credentials as external source” is disabled again.

      The toggle “Save these credentials as external source” cannot be disabled. It’s not even programmed that way. So I’m wondering where you were returned from? Under Media Library > Add External Files > Cloudflare R2? The form should look completely blank.

      If you navigate to your saved external source and click “Open now” you shouldn’t see a form at all, but rather the files in your Cloudflare bucket. Feel free to show what you mean with a screenshot. See: https://wordpress.org/support/forum-user-guide/block-editor/#adding-screenshots

      So at the moment it appears that I would have to enable and save “Save these credentials as external source” before every import in order for the configured custom domain to actually be used for external hosting.

      That’s also the purpose of saving sources as “external sources”. They are your starting point whenever you want to connect after the first connection. It saves you from constantly entering connection details. You can also configure automatic file synchronization and exporting files to this location.

      If you choose not to use this feature, you will have to re-enter the connection details before every import. That is tedious and not particularly practical. However: the access credentials are stored in encrypted form in compliance with ISO/IEC 27001 standards.

      If I import another file without enabling and saving this option again, the file is copied to the local WordPress uploads directory and is treated as locally hosted.

      I can’t reproduce this behavior on my system, despite several attempts. The file handling is always identical, regardless of whether the checkbox is selected or not. Nothing else is implemented here.

      So the R2 URL and delivery through the custom domain appear to work correctly, but the image dimensions/metadata provided to WordPress/WooCommerce seem to be 0 × 0.

      I can’t reproduce this behavior on my system either. However, it could be related to the specific file and what MIME type R2 returned for it. What does the “Save” box in WordPress’s Media Library show for the file in question? These are the values ​​that were read, and they should never be 0 for images.

      A tip for you for further analysis:
      Activate the plugin’s debug mode under Settings > External Files > Advanced in the “Log Mode” field. Select “log all” here. Then go to Settings > External Files > Logs and clear the logs to get a fresh view. Next, try a) re-establishing a connection to import the files and b) importing an image. The log will then contain a lot of data, including detailed information about what data was passed from Cloudflare R2 and how it was processed.
      Hint: Do not leave this log mode permanently enabled, as it logs a significant amount of data.

      Plugin Author threadi

      (@threadi)

      4 days, 4 hours ago

      Update: I think I’ve identified the issue with the image dimensions. It stems from how R2 handles mime types for any file. Unless you explicitly set the mime type in R2, it defaults to a generic “octet-stream”, which is what we get via API. I’ve now modified the code so that, in such cases, the actual mime type is determined using WordPress’s built-in functions. It’s working without any issues for me now.

      However, I do need to make minor adjustments to both plugins to accommodate this. Before I do that, I’d like to look into something from your description that really puzzled me: the fact that the “Save these credentials as external source” button is disabled on your end. As I mentioned, that feature isn’t even programmed into the system; I’d love to see a screenshot of it and understand exactly the context in which you’re seeing it.

      Thread Starter gosiaeu

      (@gosiaeu)

      4 days, 4 hours ago

      Thank you – that would explain the 0 × 0 issue perfectly. Regarding “Save these credentials as external source”, I meant that the checkbox appears unchecked again, not that the feature itself becomes disabled. I’ll attach a screenshot showing exactly where I see this.
      https://ibb.co/XxtHKhtS

      Plugin Author threadi

      (@threadi)

      4 days, 4 hours ago

      Yes, the checkbox is always unchecked. It’s never automatically checked, so you can actively choose whether to check it. What would you have expected here? That when you open the login form in R2, you’d see your login credentials already filled in?

      Thread Starter gosiaeu

      (@gosiaeu)

      3 days, 15 hours ago

      Thanks, I understand what you mean now. I did not expect the R2 credentials themselves to be automatically filled in, and I now understand that this checkbox is intentionally always unchecked in the new connection form.

      I think my original description may have caused some confusion. What puzzled me was the behavior of the saved external source, rather than the checkbox itself.

      After saving the Cloudflare R2 connection as an external source, I expected to be able to return to that saved source and use it for subsequent imports without creating/re-entering the connection again.

      This is also why I initially interpreted the unchecked checkbox as if the previously saved setting had not been retained.

      After the recent update, however, I can no longer find where the previously saved Cloudflare R2 external source and its settings are located in the interface.

      Could you please tell me where I should now find and manage an already saved external source in the current version?

      Once I know the correct location/workflow, I can check this again and confirm whether there is actually any issue with the saved source.

      Thank you for your patience and for investigating the R2 MIME type issue as well.

      Plugin Author threadi

      (@threadi)

      1 day, 1 hour ago

      You can find your saved external sources at any time under Media > Your external sources. From there, you can open them again at any time without having to re-enter your login credentials. You can also manage their automatic synchronization and exports from WordPress to these sources from this location.

    Viewing 10 replies - 1 through 10 (of 10 total)

    You must be logged in to reply to this topic.