Simple test:
Create some entity ( I am using an ECK entity ), add a popup field group.
Now create a view using the entity display with your popup field group, add a pager, enable ajax. ( The same problem is evident with other ajax situations, like exposed filters )
Visit your view ( in my case a block ).
When you inspect the popup button, you have a url for the current route, plus the #open-popup fragment. In my case /contacts/115#open-popup.
Finally, advance the pager, then click the popup link.
You will see the dialog load right before the page redirects to /views/ajax/XXX#open-popup ( which is not found ).
I think this problem can be addressed in 2 ways:
In src/Plugin/field_group/FieldGroupFormatter/Popup.php
/**
* Generate link for open popup.
*
* @return array
* Link for open popup render array.
*/
protected function generateOpenPopupLink() {
return [
'#type' => 'link',
'#title' => $this->getSettingValue('popup_link', 'text'),
'#url' => Url::fromRoute('<current>', [], [
'fragment' => 'open-popup',
'query' => $this->requestStack->getCurrentRequest()->query->all(),
'attributes' => [
'data-target' => $this->getGroupId(),
'class' => array_merge(
[$this->openPopupCssClass],
explode(
' ',
$this->getSettingValue('popup_link', 'classes')
)
),
],
]),
];
}
The #url attempts to build out the URL based on the currentRoute. I am not sure why the full route is needed here, maybe something to do with the link render element? I don't believe it's ever actually needed, just the fragment. Maybe use instead of ? Maybe this won't work or causes another issue?
At any rate, I think this can all be mitigated with a small change to the javascript. /js/popup_field_group.js around line 30.
- link.click(function () {
+ link.click(function (e) {
+ e.preventDefault();
if (popupSettings.modal) {
dialog.showModal();
}
else {
dialog.show();
}
});
This would at least intercept the click and prevent the page from redirecting.
Comments
Comment #2
scottsawyerComment #4
antonnaviHello, Scott Sawyer (scottsawyer)!
Thank you for a note!
Described issue was fixed in 8.x-1.4 module version.
Comment #5
scottsawyerAntonnavi! You rock! That fixed it. I looked at the commit, looks like it was a much bigger issue than I suspected! Great job.