I had a similar issue after updates where direct file links in body texts were no longer tracked for usage through HtmlLink. After debugging this issue, it turned out that the public file regex pattern in PublicFileIntegration was changed as part of https://www.drupal.org/project/entity_usage/issues/3514883 → and now no longer matches file paths like "/sites/default/files/imagename.jpeg".
I made a patch that re-adds the optional leading slash which was present in earlier versions. I also made sure we never get a double trailing slash. (which I got at one point during testing).
This new pattern should now handle both external and local file systems.
On one of our projects we were using one of the earlier patches (I think from #109). After upgrading from 6.1.7 to 7.0.7 I removed the changes since this ticket was closed, but unfortunately we once again had issues with matching nodes from different languages (through their path).
I noticed that a test was added for this exact case and I can confirm that the test did run correctly on our site. One key difference however (and what I think might be the cause of the issue) is that the test takes one node and adds translations to it, while on our specific site we have separate nodes for each translation. When testing with these nodes I failed to get a match through the findEntityIdByUrl method. Diving into the Url::fromUserInput() method, it seems that the core path validator fails to retrieve the proper URL from creating a request using the path (in correct cases you get a canonical URL but in these cases I got an "unrouted" URL making it so that the node ID couldn't be retrieved.
In case anyone has a similar issue, I added a patch for 7.x that reintroduces the findEntityIdByUrl method that uses the alias manager service, since this does work for our use case (and might help others in a similar situation). Not looking to reopen this ticket, just wanted to share my findings.
Rerolled the last patch for 7.0.7.
Rerolled patch for 3.0.2 .
Rerolled patch for 2.1.
Rerolled patch for 3.0.2
Rewritten patch for 2.0.0-beta2.
Rerolled latest patch for 10.3.
Rerolled the latest patch for 2.0.0-beta2.
Adding a patch in case someone needs these changes for 2.39 (patch from MR diff didn't apply for me).
Pushed proposed change to fork and also uploading a patch in case someone needs it. Please review.
Now also with added packaging info
The latest patch still causes type errors. I extended the latest patch to also update references in ChainGroupPermissionCalculator.
The change is applied to horizontal_toolbar.scss, but this CSS is only used when you are specifically using the horizontal toolbar (which is a theme setting).
For me this doesn't fix the issue, since I am using the standard toolbar. But I assume it would be sufficient to apply the same changes to toolbar.scss as well.
Chewi3 → created an issue.
This is also currently an issue on webforms when offcanvas is enabled for editing. For now we can switch to dialogs using webform settings, but would be nice if this could be fixed (or at least patched for now).
Patch in #42 no longer applied for me in 10.2, so I rerolled it. Uploading in case someone else needs it for now.
I updated the patch from #9 so that it applies against 4.0 release. I did notice that EncloseField is marked as deprecated, so we should probably look into a more long term solution before we can think about merging this.
In my previous comment I forgot to account for node creation (which seems to correspond to the "default" operation). Which also means my fix needs to be slightly adjusted (I guess I can specifically add a "delete" content form mode instead and do it the other way around).
Adding an updated patch.
I haven't tested from a clean Drupal install, but the way it is currently set up does seems like a possible problem.
The entity_form_steps_form_alter hook checks if the form object is an instance of ContentEntityFormInterface. ContentEntityConfirmFormBase extends ContentEntityForm, so the node delete form is also altered.
Usually you only have the "default" form display mode. So if this is the form mode that has the step field groups, they will also be retrieved for the delete form (since it tries to look for a "delete" form mode, but defaults to the "default" form mode.
I did fix our problem by adding an extra content form mode next to the default. By adding an "edit" form mode with the steps and removing the steps from the default, the issue is fixed.
Not sure what a good fix would be, if it is even needed. I did add a patch with a possible solution (checking the form state operation and only altering the form when in 'edit mode'), so feel free to review if something like this could be helpful to add.
Added patch with my temporary solution (as mentioned in issue description).
I added a patch that changes the logic on the disable form cancel callback to be similar to the TfaSetupForm cancel callback logic.
Chewi3 → created an issue.
I came across the same problem today and had to use an AJAX callback as an alternative. You should probably make an actual ticket for this (not sure how much traction this forum post will have).
Chewi3 → created an issue.