WordPress.org

Make WordPress Core

Opened 5 months ago

Last modified 5 months ago

#47296 new defect (bug)

Attachments with very long filenames fail to save to the database

Reported by: mboynes Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Upload Keywords:
Focuses: Cc:
PR Number:

Description

When an attachment is uploaded and the attachment post is inserted into the database, the guid is set to the attachment URL. The guid database column is limited to 255 characters, so a very long domain/filename combination can result in the post failing to save to the database with the vague message "Could not insert post into the database". The uploaded file does not get deleted from the uploads directory, and further attempts to upload the same file without renaming it will result in a different error, "The uploaded file could not be moved to {location}".

The issue occurs in wpdb::strip_invalid_text() and wpdb::process_fields(). wpdb::strip_invalid_text() trims the field contents down to 255 characters, and wpdb::process_fields() fails as a result of this data change.

The root cause is the same as #32315, though I believe this should still be tracked and handled separately. Judging by the trajectory of #32315, the user would be presented with a cryptic database-focused error message, whereas a better solution for this problem would be that the attachment successfully inserts.

To Replicate

  1. Create a file and give it a name composed of 240+ characters (the "tipping point" length depends on the site's domain, amongst other factors, so this error can occur with shorter filenames).
  2. Upload the file to WordPress anywhere media can be added.
  3. The database insert should have failed with the error message, "Could not insert post into the database".
  4. Attempt to upload the same file again to observe the error message, "The uploaded file could not be moved to..."

Change History (1)

#1 @ianbelanger
5 months ago

  • Version 5.2 deleted

Removing the Version as this was not introduced in 5.2. I am not sure in which version this problem was introduced, so leaving it blank for now.

Note: See TracTickets for help on using tickets.