User tests: Successful: Unsuccessful:
Pull Request for Issue
#21847 .
Modals should be placed before </body>
tag.
Apply patch, check the batch operation on article list view
Status | New | ⇒ | Pending |
Category | ⇒ | Libraries |
Labels |
Added:
?
|
@franz-wohlkoenig check the issue: #19408
Batch operation on article list view works as expected without this PR.
"Fetch Data" in Patchtester works as expected with this PR.
Thats why i was asking.
With this changes you break all structures regarding CSS.
Before you could add the modal code into your extension with a specific "wrapper class" to format e.g. the content of all modals.
Now the modal is never into the extension again.
I am a bit at a loss here.
#21847 and this one work alright.
But,
With this changes you break all structures regarding CSS
@bembelimen
Where do we have to check ?
Before you could add the modal code into your extension with a specific "wrapper class" to format e.g. the content of all modals.
You can still do that now. All modals have an id so in your layout css you could target the modal contents through that selector
Yes and no, if you create modals on the fly, you don't know the ID for the CSS file.
Yes and no, if you create modals on the fly, you don't know the ID for the CSS file.
That's not a problem. You either have a pattern creating the id (eg article_modal_ + artcleId) or you prepend something random and then you take care css in JS.
BTW this is actually something that we need one way or another as the modals will be dialog
tags and the polyfill suggests that all elements should be before the closing body tag. So that was the plan from the beginning, if you have code that depends on specific position of the modals you need to do the adjustments (this is also the case for couple instances in core as well).
Title |
|
I have tested this item
With the patch the patchtesters modal is working again.
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2018-08-29 10:25:06 |
Closed_By | ⇒ | dgrammatiko |
what to look for?