Cannot update the order weight using complex form widget

I'm also having this issue, happening on both Drupal 8.6 and 8.7-beta.

Same issue here. It seems that editing at least one of the referenced entities THEN reordering and hitting save does work.

Just a note that this is happening for me in a Block added via Layout builder.

EDIT: This is only happening in the Complex widget.

EDIT2 2: I've found the cause of the bug, it's to do with extractFormValues and this check if (empty($triggering_element['#ief_submit_trigger'])) {

When you edit a complex widget and do nothing but reorder the field values, $triggering_element['#ief_submit_trigger'] is not set which means it never gets down to the uasort function.

Doing anything in the form, for example editing a field value (without even changing any values) or adding a new value and then removing it will set this key and therefore will run the full extractFormValues function and save the updated weights.

This is because InlineEntityComplex::addSubmitCallbacks doesn't run until either an existing value is edited, or a new value is added. That callback is what sets
$element['#ief_submit_trigger'] = TRUE;

Recently ran into this on a new D9 build. We have a custom block that references another custom block using the Complex form widget. Basically, Content Cards use the Content Card to create a component. The cards should be edited on the form so we're using the complex widget. When a user goes to update the order of an already existing set the order isn't update. Thanks @acbramley for the discovery. As you noted this is only IF the content isn't updated, which for us is a pretty normal use case. i.e. we want to highlight this piece of content so we're dragging it to the top of the list.

As noted in EDIT 2 this is happening because of the check that is watching for only ief changes. Based on what I can find this was added with this issue https://www.drupal.org/project/inline_entity_form/issues/2730759 but I can't quite figure out why this was needed to begin with. I'm assuming its a performance check; if ief wasn't touched don't bother with all this. Unfortunately that means just updating the order isn't possible.

I've removed that check in this patch and I've tested updating the content, updating the sort order only, etc. It appears to work and doesn't throw any errors. The only thing I'm concerned about is whether or not that check was required to prevent messing up the data, or adding duplicate entries, or or...

I've updated the title to more closely match the exact issue as discovered by @acbramley

Just a note to say this patch is working well for me.

We have a live site working with this module for a year now.

This appears to be reviewed, can we get this merged?

Thanks for discovering, describing and nailing this! Esp for the verbose comments.
Looks to me like it makes a lot of sense.
The tests are green, but this may cause regressions. Do you run the patch in production?
Ideally more than one agency does, which can give us confidence to commit.

The most important thing: We don't want this to break again.
Sounds like a pretty simple set of actions is needed to provoke the bug.
Can you extend test coverage to cover the use case?

Thanks for providing the patch. It's working for me.

This is a duplicate of #3136514: IEF complex widget: Re-ordering / weight sometimes not updated. Both issues have patches with widely different solutions. We need to figure out which one to implement (if any). Both patches need tests. The less desirable solution's issue needs to be closed after granting credit to all contributors in the other issue.

For what it's worth, I think that this is the patch we use on my sites, but I'll have to verify that sometime when I'm at work. Edit: Nope, I was wrong. We use the other issue's solution.

Also, if this doesn't cause regressions, then it may indicate that this code is unnecessary. And I'd rather remove unnecessary code than add the new code that's in the other issue's patch.

Just FYI, I tried to reproduce the issue on a fresh install so that I could write a test, but I couldn't make it happen. And yet I know that we've had this problem at work. I have actually seen this problem in action. So if anyone can provide us with reliable steps to reproduce, then I'll volunteer to take care of writing a test.

@dcam: Sounds very reasonable. Rock on!

This needs a patch for the 3.x branch.

The MR should contain the same change as https://www.drupal.org/project/inline_entity_form/issues/3033241#comment...

Our use case has shown up again on a new D10 site we have.
We have a Block as the parent block.
We have other Blocks as child blocks as entity reference revisions fields.
We use the Inline Entity Form - Complex to allow adding/editing the blocks in the block.
When you Edit the Parent block and do nothing other than reorder the child blocks and save.
The order is not updated.
You have to actually make a change to the child blocks in order to get it to see you made a change.

The patch (from MR) applies clean, and fixes the issue.
Now when I reorder the items without making any other change the new order is saved.

I'm facing the same error with D11 and I'm using layout builder otherwise it worked fine,
Applied above patch #4 and now it's working for me.

Thank you!

Is this enough review on this? Do we need more testing?

@ishani patel, @jlockhart: As explained in #10 and noted in the "Needs test" tag, this issue is waiting for someone to write an automated test.

@geek-merlin Thank you, I missed that. I'll try to work on a test over the next week or so.