Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
So the issue here is that the dialog api and jquery.ui insert the elements into the dom as a child of the tag which means they are no longer part of the
tag. Hence submitting the form in the modal doesn't result in the form being rebuilt.
So we have a few options here, none of them too pleasant
1) We use a temp store object for the display entity and each settings form modal is a separate page callback/form that manipulates this temp store object, updating the object used to generate the display overview - only updating the display entity when submitted, this seems the most robust and mimics views, but is fairly involved
2) We use some javascript to close the dialog, attach the elements inside the
tag before the modal form is submitted, this smells hacky to me
3) Leave it as is and avoid the modal
2 is indeed hacky all the way, I don't we'll be able to sell that one, plus I don't like it anyway :)
I'm also not sure whether this works then if you don't have javascript enabled ?
So, a separate callback, using the tempstore, just like all callbacks in views, seems the one that will make sure it works in javascript or non javascript, no.
Additionally, we *could* also use this on manage fields too for the field settings. But let's try one step at the time.
I'm all for it, but I'm not sure, as you mention, how fast we can convert this. Maybe we should talk to the VDC guys how hard this conversion would be/is.
As an addition, amateescu and I had a talk with Bojhan on IRC and only doing formatters for now is fine. So not for fields as dialog is not for wizards or long forms and a mix of both isn't ideal.
Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.
Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.
Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)
Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)
Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)
Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)
Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.
Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.
Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.
Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.
Comments
Comment #0.0
swentel CreditAttribution: swentel commentedUpdated issue summary.
Comment #1
larowlanTagging
Comment #2
larowlanComment #3
larowlanGiving this a shot
Comment #4
larowlanSo the issue here is that the dialog api and jquery.ui insert the elements into the dom as a child of the tag which means they are no longer part of the
tag. Hence submitting the form in the modal doesn't result in the form being rebuilt.
So we have a few options here, none of them too pleasant
1) We use a temp store object for the display entity and each settings form modal is a separate page callback/form that manipulates this temp store object, updating the object used to generate the display overview - only updating the display entity when submitted, this seems the most robust and mimics views, but is fairly involved
2) We use some javascript to close the dialog, attach the elements inside the
tag before the modal form is submitted, this smells hacky to me
3) Leave it as is and avoid the modal
thoughts?
Comment #5
larowlanHere's the patch if you want to see what I'm talking about.
And some screenshots.
Comment #6
swentel CreditAttribution: swentel commented2 is indeed hacky all the way, I don't we'll be able to sell that one, plus I don't like it anyway :)
I'm also not sure whether this works then if you don't have javascript enabled ?
So, a separate callback, using the tempstore, just like all callbacks in views, seems the one that will make sure it works in javascript or non javascript, no.
Additionally, we *could* also use this on manage fields too for the field settings. But let's try one step at the time.
I'm all for it, but I'm not sure, as you mention, how fast we can convert this. Maybe we should talk to the VDC guys how hard this conversion would be/is.
Comment #7
yched CreditAttribution: yched commentedAgreed. The tempstore seems like the most reasonable approach...
Comment #8
swentel CreditAttribution: swentel commentedAs an addition, amateescu and I had a talk with Bojhan on IRC and only doing formatters for now is fine. So not for fields as dialog is not for wizards or long forms and a mix of both isn't ideal.
Comment #8.0
swentel CreditAttribution: swentel commentedUpdated issue summary.
Comment #9
swentel CreditAttribution: swentel commentedtagging
Comment #10
swentel CreditAttribution: swentel commentedupdating tags
Comment #11
larowlanComment #11.0
larowlanUpdated issue summary.
Comment #12
amateescu CreditAttribution: amateescu commentedI wanted to check if #2094499: Convert "Manage (form) display" forms to be the official entity edit forms for EntityView[Form]Display objects will be of any help here, but the modal submit buttons are not doing anything (not even closing the modal).
Anyway, here's a reroll on top of #2094499: Convert "Manage (form) display" forms to be the official entity edit forms for EntityView[Form]Display objects if anyone wants to play with it.
Comment #25
tim.plunkett