Title: Cloudflare R2 problem
Last modified: August 26, 2026

---

# Cloudflare R2 problem

 *  [gosiaeu](https://wordpress.org/support/users/gosiaeu/)
 * (@gosiaeu)
 * [1 week, 2 days ago](https://wordpress.org/support/topic/cloudflare-r2-problem/)
 * 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](https://wordpress.org/support/users/threadi/)
 * (@threadi)
 * [1 week, 1 day ago](https://wordpress.org/support/topic/cloudflare-r2-problem/#post-19004946)
 * 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](https://wordpress.org/support/users/threadi/)
 * (@threadi)
 * [5 days, 10 hours ago](https://wordpress.org/support/topic/cloudflare-r2-problem/#post-19006766)
 * With the recently released [version 1.1.0 of the AWS plugin](https://github.com/threadi/external-files-from-aws-s3/releases/tag/1.1.0),
   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](https://wordpress.org/support/users/gosiaeu/)
 * (@gosiaeu)
 * [4 days, 16 hours ago](https://wordpress.org/support/topic/cloudflare-r2-problem/#post-19007174)
 * 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](https://wordpress.org/support/users/gosiaeu/)
 * (@gosiaeu)
 * [4 days, 15 hours ago](https://wordpress.org/support/topic/cloudflare-r2-problem/#post-19007226)
 * 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:
 *     ```wp-block-code
       src="https://[custom-domain]/test.jpg"
       ```
   
 * However, the generated `<img>` element has:
 *     ```wp-block-code
       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:
 *     ```wp-block-code
       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](https://wordpress.org/support/users/threadi/)
 * (@threadi)
 * [4 days, 7 hours ago](https://wordpress.org/support/topic/cloudflare-r2-problem/#post-19007749)
 * 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](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](https://wordpress.org/support/users/threadi/)
 * (@threadi)
 * [4 days, 5 hours ago](https://wordpress.org/support/topic/cloudflare-r2-problem/#post-19007789)
 * 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](https://wordpress.org/support/users/gosiaeu/)
 * (@gosiaeu)
 * [4 days, 5 hours ago](https://wordpress.org/support/topic/cloudflare-r2-problem/#post-19007794)
 * 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](https://ibb.co/XxtHKhtS)
 *  Plugin Author [threadi](https://wordpress.org/support/users/threadi/)
 * (@threadi)
 * [4 days, 5 hours ago](https://wordpress.org/support/topic/cloudflare-r2-problem/#post-19007796)
 * 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](https://wordpress.org/support/users/gosiaeu/)
 * (@gosiaeu)
 * [3 days, 16 hours ago](https://wordpress.org/support/topic/cloudflare-r2-problem/#post-19008222)
 * 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](https://wordpress.org/support/users/threadi/)
 * (@threadi)
 * [1 day, 2 hours ago](https://wordpress.org/support/topic/cloudflare-r2-problem/#post-19011100)
 * 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](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fwordpress.org%2Fsupport%2Ftopic%2Fcloudflare-r2-problem%2F%3Foutput_format%3Dmd&locale=en_US)
to reply to this topic.

 * ![](https://ps.w.org/external-files-in-media-library/assets/icon-256x256.jpg?
   rev=3477016)
 * [External files in Media Library](https://wordpress.org/plugins/external-files-in-media-library/)
 * [Frequently Asked Questions](https://wordpress.org/plugins/external-files-in-media-library/#faq)
 * [Support Threads](https://wordpress.org/support/plugin/external-files-in-media-library/)
 * [Active Topics](https://wordpress.org/support/plugin/external-files-in-media-library/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/external-files-in-media-library/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/external-files-in-media-library/reviews/)

 * 10 replies
 * 2 participants
 * Last reply from: [threadi](https://wordpress.org/support/users/threadi/)
 * Last activity: [1 day, 2 hours ago](https://wordpress.org/support/topic/cloudflare-r2-problem/#post-19011100)
 * Status: not resolved