Contrib.social

File field AJAX wrapper always targets first instance on the page

Open on Drupal.org →
Created on 12 October 2012, over 12 years ago
Updated 26 February 2023, almost 2 years ago

Updated: Comment #N

Problem/Motivation

When a file field is used more than once on a page, the AJAX upload or remove will always target the first instance.
One example for reproducing this is if two entities reuse the same field, and their edit forms are displayed on the same page.

Steps to reproduce in #22

Proposed resolution

Remaining tasks

Find solution.

User interface changes

N/A

API changes

N/A

Original report by @eme →

When you have multiple forms containing the same file, it is not possible to remove it.

Let's take an example : I have nodes with comments and the comment forms on the page, and I have a file field in the comment form. I can load the file, but not remove it.

Why ? Because when you load multiple forms you have additionnal ID, like form-id--x, and this additionnal ID is incremental for any form loaded to make sure they got a unique id. Issue is that when you load the file via ajax, it has the issue of not taking again the original ID, but the normal one, and therefore it acts on the first form ! In some configurations, ajax callback breaks and you are just redirected.

Note that this does not happen to the first one that has no additionnal id and therefore works fine.

Attached is a little video demo.

Must say I'm working on that for some days and it seems quite tricky...

🐛 Bug report
Status

Closed: outdated

Version

9.5

Component
File module  →

Last updated 9 days ago

Created by

🇫🇷France eme

Live updates comments and jobs are added and updated live.
  • Needs backport to D7

    After being applied to the 8.x branch, it should be considered for backport to the 7.x branch. Note: This tag should generally remain even after the backport has been written, approved, and committed.

  • Needs tests

    The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.

  • Needs manual testing

    The change/bugfix cannot be fully demonstrated by automated testing, and thus requires manual testing in a variety of environments.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment almost 2 years ago →
    🇳🇿New Zealand quietone

    I tested this on Drupal 10.1.x, standard install using the steps in #22. It worked fine, there were no errors. The steps in #22 seem different that what is described in the Issue Summary. So, I tried again.

    I made a new content type with two file fields. I tested creating and save with different files for each field, with the same file for each field, and only a file in the first field and only a file in the second field. In all cases, there were no errors and the files were related to the correct field.

    Considering that there has been no discussion here for 8 years, I am going to say that this is now outdated.

    Therefore, closing as outdated. If this is incorrect reopen the issue, by setting the status to 'Active', and add a comment explaining what still needs to be done.

    Thanks!

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024