App for Cloudflare® Pro

App for Cloudflare® Pro 1.8.9

Moving media to R2 missed a couple PDFs

moonlike1871

New member
I migrated all of my media to R2 using the command line. Worked nicely! The migration tool (both the CLI and the web UI) currently says that there are no more files to be migrated.

I have two PDFs in my media library which were not migrated. They are still in my media library, still linked from a couple pages. If I search them out in the media library, it says "Stored in R2: No"

However, there's no way for me to move them. I could manually copy them, of course, but I'd like to know what's going on. The plugin doesn't seem to recognize that they are eligible to move. They exist in the filesystem and inside the media library.

Screenshot 2024-09-05 at 6.54.44 PM.png

Screenshot 2024-09-05 at 6.57.08 PM.png

On that subject, it'd be great to have a way where I could filter the media library for media that has not yet been uploaded to R2. The cloud icons are nice but it's not possible to filter through large amounts of media visually.
 
Small update, I found the manually move to R2 button on the media file. So that worked, but I did leave the second PDF alone for now in case there's some troubleshooting to be done.
 
I poked around on it a bit, and I wasn't able to replicate what you are seeing. I uploaded a PDF, it landed in R2, I manually moved that PDF back to local and then hit the Migrate button and it showed as 1 item in local to migrate (did that and it successfully went back to R2). So from that standpoint it does seem to be working as expected.

Not sure if you have direct database access to your WordPress install (if you are able to view database records or run queries), but if so, this is the query it runs to find the items that are in the local filesystem (but not R2):

SQL:
SELECT COUNT(*)
FROM `wp_posts`
INNER JOIN `wp_postmeta` ON (`wp_postmeta`.post_id = `wp_posts`.ID
    AND `wp_postmeta`.meta_key = '_wp_attachment_metadata')
WHERE `wp_posts`.post_type = 'attachment'
    AND `wp_postmeta`.meta_value NOT LIKE '%inR2\";b:1%'
ORDER BY post_date DESC

My only guess is that maybe something non-standard uploaded the PDF you have that isn't acting "right" and didn't include the expected metadata record (although the fact that it shows the filesize in your screenshot tells me that the record is there, because that's where it comes from).

If you are able to run this query (where {post_id} is the item variable in the URL when you click on the attachment):

SQL:
SELECT * FROM wp_postmeta WHERE post_id = {post_id};

Like that query for my test file after I sent it back to the local filesystem returns this:

Code:
mysql> SELECT * FROM wp_postmeta WHERE post_id = 1444;
+---------+---------+-------------------------+------------------------------------+
| meta_id | post_id | meta_key                | meta_value                         |
+---------+---------+-------------------------+------------------------------------+
|     746 |    1444 | _wp_attachment_metadata | a:1:{s:8:"filesize";i:808939;}     |
|     747 |    1444 | _edit_lock              | 1725585783:1                       |
|     745 |    1444 | _wp_attached_file       | 2024/09/ARC-Application-Master.pdf |
+---------+---------+-------------------------+------------------------------------+
3 rows in set (0.01 sec)

Since the filesize does exist in your screenshot, the only other thing in that query that would make it not return something is if somehow post record for it wasn't "attachment".

If you run this query, what do you get?

SQL:
SELECT post_type FROM wp_posts WHERE ID = {post_id};

It *should* be attachment, but maybe it's something else?
 
I get a count of 0 on that first query.

If I run that second query, I get only 2 out of your 3 rows, no metadata row:

Code:
MariaDB [xxx]> SELECT * FROM wp_postmeta WHERE post_id = 9583;
+---------+---------+-------------------+---------------------------+
| meta_id | post_id | meta_key          | meta_value                |
+---------+---------+-------------------+---------------------------+
|   16364 |    9583 | _wp_attached_file | 2016/12/Packing-List.pdf |
|  250015 |    9583 | _edit_lock        | 1652573113:3              |
+---------+---------+-------------------+---------------------------+
2 rows in set (0.000 sec)

These two files were uploaded directly to a post via the Wordpress front end, because I helped author the post that they're included in.

Oops, missed the second query you wanted me to run. It is, in fact, "attachment" post type.
 
Last edited:
Hmmmm… well that is the issue. Not sure where your install is getting the filesize though because that’s *supposed* to come from the metadata record. Certainly could change the query slightly to take into account the missing record, but honestly I'm not sure if that's a particularly good idea because the record is in fact supposed to be there. 😕

There is a WordPress CLI command to regenerate missing metadata. If you run this does it sort itself out?

Code:
wp media regenerate --only-missing
 
Hmm. Didn't fix it.

The regeneration routine says it regenerated metadata for 1 file. Wordpress now shows 5 separate (but identical) metadata entries in the database for the single PDF file, that all end in .jpg, and the R2 migration utilities (both CLI and web, as well as that SQL query) show 5 things that need to be moved to R2.

Code:
|  260083 |    9583 | _wp_attachment_metadata | a:1:{s:5:"sizes";a:1:{s:4:"full";a:5:{s:4:"file";s:21:"Packing-List.pdf.jpg";s:5:"width";i:1088;s:6:"height";i:1408;s:9:"mime-type";s:10:"image/jpeg";s:8:"filesize";i:97522;}}} |
|  260084 |    9583 | _wp_attachment_metadata | a:1:{s:5:"sizes";a:1:{s:4:"full";a:5:{s:4:"file";s:21:"Packing-List.pdf.jpg";s:5:"width";i:1088;s:6:"height";i:1408;s:9:"mime-type";s:10:"image/jpeg";s:8:"filesize";i:97522;}}} |
|  260085 |    9583 | _wp_attachment_metadata | a:1:{s:5:"sizes";a:1:{s:4:"full";a:5:{s:4:"file";s:21:"Packing-List.pdf.jpg";s:5:"width";i:1088;s:6:"height";i:1408;s:9:"mime-type";s:10:"image/jpeg";s:8:"filesize";i:97522;}}} |
|  260086 |    9583 | _wp_attachment_metadata | a:1:{s:5:"sizes";a:1:{s:4:"full";a:5:{s:4:"file";s:21:"Packing-List.pdf.jpg";s:5:"width";i:1088;s:6:"height";i:1408;s:9:"mime-type";s:10:"image/jpeg";s:8:"filesize";i:97522;}}} |
|  260087 |    9583 | _wp_attachment_metadata | a:1:{s:5:"sizes";a:1:{s:4:"full";a:5:{s:4:"file";s:21:"Packing-List.pdf.jpg";s:5:"width";i:1088;s:6:"height";i:1408;s:9:"mime-type";s:10:"image/jpeg";s:8:"filesize";i:97522;}}} |

If I actually run the migration it says it was successfully completed:
Code:
Are you sure you want to migrate 5 media items from local filesystem to R2? [y/n] y
Migrating media  100% [==================================================================================================================================================================================] 0:01 / 0:02
Success: Done

But the file still doesn't show as migrated in the media library, and the migration utilities still both show 5 files not moved.

I don't mind manually moving it, just wanted to make sure there wasn't something useful for you to troubleshoot.
 
Ya, would be good to know the “why” as far as why that record is missing. Just not sure the “right” thing to do is try to handle an attachment that is internally “broken” as far as WordPress is concerned (missing record that’s supposed to be required for all media).
 
Back
Top