Attachment custom fields not rendered after upload

[trepmal]

This is a follow-up to #40909.

Attachment custom fields added via attachment_fields_to_edit are no longer rendered just after an image is uploaded.

Clicking away and back will restore the custom field markup, but is quite inconvenient.

[trepmal]

demonstration of behavior

[joedolson]

Possible ideas include reinitializing the frame after an upload, reverting the change in 40909, and providing the initialize method that was removed with context for where focus should be. But this needs further exploration.

Trac ticket: https://core.trac.wordpress.org/ticket/58051

[adamsilverstein]

@joedolson what about something like 58051.diff​ which triggers the render on the add callback instead? I tested this (briefly) and I see the fields (immediately after uploading completes) - also the focus issue from #40909 still appears resolved.

@trepmal does this fix your issue or cause any unexpected side effects?

[joedolson]

Test steps:

Failure case:

1) Set up custom fields using code sample on #40909
2) Go to add a featured image to a post.
3) Upload image by dropping into thumbnail grid within the media modal.
4) Verify that attachment fields do not display.

Success case:

1) Apply patch and build.
2) Go to add a featured image to a post.
3) Upload image by dropping into thumbnail grid within the media modal.
4) Verify that attachment fields do display.
5) Add content to test field 1; tab forward to observed focus. Observe that focus stays in field 2.

Tested patch and verified test results as expected.

Marking for commit.

Test against media changes to render attachment fields on new uploads.

Trac ticket: https://core.trac.wordpress.org/ticket/58051

[joedolson]

In 55649:

Media: Render attachment custom fields for new uploads.

Initialize attachment custom fields during the add callback, so that fields are present as soon as an attachment is uploaded but do not refresh when field values are changed. Follow up to #40909.

Props trepmal, adamsilverstein, joedolson.
Fixes #58051.

[joedolson]

Reopened to backport to 6.2.1

[bbreedlove]

I'm encountering the bug described here and I wanted to pop in and note that I've tested the patch attached on this ticket and it successfully resolves the problem.

[joedolson]

#58210 was marked as a duplicate.

[audrasjb]

In 55735:

Media: Render attachment custom fields for new uploads.

Initialize attachment custom fields during the add callback, so that fields are present as soon as an attachment is uploaded but do not refresh when field values are changed. Follow up to #40909.

Props trepmal, adamsilverstein, joedolson.
Merges [55649] to the 6.2 branch.
Fixes #58051.

[antpb]

This issue seems to still be happening in certain frames. For instance if you upload an attachment using a custom media library button in something like a custom field, a newly uploaded item will not render the custom fields as expected. Moving this to 6.4 for investigation and a fix. I've been working on a fix for a bit now and am close. Marking early.

[hellofromTonya]

I've removed the early keyword. Why?

​The handbook explains the keyword as:

This keyword should only be applied by committers. The keyword signals that the ticket is a priority, and should be handled early in the next release cycle.

early means the commits need to happen during the early part of the Alpha cycle; else, the ticket gets bumped.

Though it would be great to prepare the work for commit as early as possible, commits for this ticket should not be constrained to only happen during the early Alpha phase. Rather, defect commits can happen up to 6.4 RC 1.

To aid in 6.4 tracking and scrubs, I've removed the early keyword.

I've also reset the keywords to reflect the ticket's current state.

[swissspidy]

Since this was already committed in 6.2 / 6.2.1, wouldn't it be better from a workflow perspective to open a new follow-up ticket? IIRC that's how we've done that in the past for such cases.

[archon810]

Related: https://core.trac.wordpress.org/ticket/59308.

[antpb]

This looks to be fixed now. I'm going to dig into what changed but I have been able to verify that custom media library buttons and the featured image flow mentioned in #59308 are working

Here's a video showing newly uploaded files are rendering with the field correctly: ​https://streamable.com/3fieiz

[SeBsZ]

Replying to antpb:

This looks to be fixed now. I'm going to dig into what changed but I have been able to verify that custom media library buttons and the featured image flow mentioned in #59308 are working

Here's a video showing newly uploaded files are rendering with the field correctly: ​https://streamable.com/3fieiz

@antpb, in which version of WordPress are you saying this has been fixed? Your video does not demonstrate that the issue in #59308 has been fixed as it is showing a fresh image upload. My issue only occurs when you click on an already attached featured image in combination with there needing to be many images in the media library such that the image you opened is not on the first page. If you want I can make a video that shows the bug in #59308?

[antpb]

hi @SeBsZ , a video would be very helpful if you could test on nightly. I was using trunk for my tests last night and found that this issue were in now 58051 is no longer reproducible. Could you try it for the featured image flows you mentioned in the other issue and leave a video there? That'll help me find a fix.

[nicolefurlan]

Hi @SeBsZ! Could you take a look at #comment:39?

[archon810]

@nicolefurlan @SeBsZ already provided the screencast and a full repro, but in the appropriate ticket, which is https://core.trac.wordpress.org/ticket/59308#comment:3.

[oglekler]

I used the code from https://core.trac.wordpress.org/ticket/59308#comment:3
and when I had few images uploaded this new field was appeared, but when I added more imaged to the Media library this bug started to appear.

We don't have patch yet and because we have 3 days before RC1, I am moving it into the next milestone.

[rajinsharwar]

There has not been much activity here since the last punt, punting it again for 6.6.

[sabernhardt]

Please feel free to move this back to 6.6 if a patch is ready to commit before the end of the beta phase.

[joedolson]

We're closing this ticket, as it's already a committed ticket. All continuing discussion should happen on the follow-up ticket, #59308.