When removing a file from an entity then uploading one with exactly the same name the following error is produced when trying to save the entity:

The website encountered an unexpected error. Please try again later.

Drupal\Core\Entity\EntityStorageException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'SomeHash' for key 'hash': INSERT INTO {redirect}...

Filefield Paths generates a hash for each redirect it creates and uses it to check if the redirect already exists. Currently Filefield Paths generates this hash using the target or destination path, while the Redirect module uses the source path with the leading slash removed.

This results in Filefield Paths never finding the existing redirect and trying to create a new one.

To resolve this, the module needs to generate a hash the same way as Redirect does. See Drupal\redirect\Entity\Redirect.

CommentFileSizeAuthor
#7 incorrect_redirect_hash_generated-3045063-7.patch836 bytesw.drupal
#6 incorrect_redirect_hash_generated-3045063-6.patch696 bytesw.drupal
#2 incorrect_redirect_hash_generated-3045063-2.patch623 bytesimclean
incorrect_redirect_hash_generated-0.patch622 bytesimclean

Issue fork filefield_paths-3045063

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

imclean created an issue. See original summary.

imclean’s picture

imclean commented
StatusFileSize
new incorrect_redirect_hash_generated-3045063-2.patch623 bytes

Added a space.

imclean’s picture

imclean commented
Issue summary: View changes
imclean’s picture

imclean commented
Issue summary: View changes
brooke_heaton’s picture

brooke_heaton commented

Tested #2 - working well for me.

I came across this issue when running Behat tests to create File Media entities - I use the same source file in my tests. The patch resolves the duplicate hash issue.

w.drupal’s picture

w.drupal commented
StatusFileSize
new incorrect_redirect_hash_generated-3045063-6.patch696 bytes

Patch re-rolled to be consistent with the last dev version

w.drupal’s picture

w.drupal commented
StatusFileSize
new incorrect_redirect_hash_generated-3045063-7.patch836 bytes

Also the language was not taken into account

chrisck’s picture

chrisck
he/him
Location BC, Canada
commented

Tested patch #7 and it works well on D9.1

chrisck’s picture

chrisck
he/him
Location BC, Canada
commented
Status: Needs review » Reviewed & tested by the community

Setting to RTBC.

voleger’s picture

voleger
he/his
Primary language Ukrainian
Location Ukraine, Rivne
commented
Status: Reviewed & tested by the community » Needs work
Issue tags: +Needs tests

Need to add tests for that case

junaidpv’s picture

junaidpv
Location Kannur, Kerala
commented

#7 works.

imclean’s picture

imclean commented 
+++ b/src/Redirect.php
@@ -79,9 +79,10 @@ class Redirect implements RedirectInterface {
+    $redirect->setLanguage($language->getId());    ¶

This looks like an unrelated change so should probably be a separate issue.

nicklasmf’s picture

nicklasmf commented

I have an issue where this duplicated hash happens when trying to upload a file multiple times to different directories using Media Library.
Patch #7 works for me as well.

imclean’s picture

imclean commented
Title: Incorrect redirect hash generated » Change redirect hash to match the Redirect module

Title should reflect what's actually being proposed. "Incorrect" is a judgement call in this case, not a statement of fact.

imclean’s picture

imclean commented

In addition to tests, this may need an upgrade path. The hash for each currently stored redirect will need to be updated.

deciphered made their first commit to this issue’s fork.

deciphered opened merge request !79

deciphered’s picture

deciphered
Primary language English
Location Ballarat, Victoria, Australia
commented
Status: Needs work » Needs review

MR opened from w.drupal's patch in #7, with the setLanguage() call from #12 dropped and two kernel tests on top.

#12: agreed, the language change is a separate concern. The pre-check now reads the language already set on the redirect entity, which is the value Redirect::preSave() hashes. The lookup matches what the save writes, and which language a redirect is stored under does not change.

#15: no upgrade path needed. Filefield Paths has never written the hash column. Redirect::preSave() writes it on every save, from the source path, so every stored redirect already has the right hash. The bug was in the lookup only, which hashed the destination path and so never matched. Existing rows are found once this is merged.

#10: the tests save the same redirect twice, once with the default language and once with de, and assert one row. Both fail on the unique hash index without the fix.

imclean’s picture

imclean commented

The bug was in the lookup only, which hashed the destination path and so never matched.

Of course, this is what led me to the problem in the first place. It has been a while since I looked at it.

  • deciphered committed bf84bb34 on 8.x-1.x 
    fix(#3045063): build the pre-check hash from the entity's own language

  • deciphered committed 632b8876 on 8.x-1.x 
    fix(#3045063): generate the dedup hash from the source path and language
deciphered’s picture

deciphered
Primary language English
Location Ballarat, Victoria, Australia
commented
Status: Needs review » Fixed

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.