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.This is related to #2122237: Compatibility problem with Media module's media browser popup
I have a node with two rich text areas, one in a field collection (loaded when the page is loaded) and one in a multi-value inline entity form (loaded via ajax). The inline entity form is totally broken when using advagg (the first entity will not even open).
This is because line 416 of wysiwyg.module adds wysiwyg.js to the footer, but it is not included in the ajaxPageState list of javascript files, so it is included again when the inline entity form is loaded over ajax.
I was able to solve this by removing the if ($scope != 'header') from the $javascript_settings_data logic in advagg.module. I don't really understand what that code is doing though, so I'm not sure if that's the best fix.
My understanding reading the code is that the 'final' list of javascript is retrieved in _advagg_process_html (commented 'Get the raw JS variable.'), then it calls advagg_get_js separately for the footer and header javascripts. It looks to me that the purpose of $javascript_settings_data is to pass additions to $javascript[...]['settings] from the footer region to the header region, as the static in drupal_add_js is not re-read after making the additions. The comment says $javascript_settings_data is for performance reasons, but I don't understand that at all.
I'll create a patch to just remove the if.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | advagg-2184375-5-no-drupal-settings-html-ajax-output.patch | 3.81 KB | mikeytown2 |
| #3 | advagg-2184375-3-fix-footer-js-ajax.patch | 2.56 KB | mikeytown2 |
| #2 | 2184375-footer-js-1.patch | 1.08 KB | ianthomas_uk |
| #1 | feeds-2168083-batch-logging-1.patch | 505 bytes | ianthomas_uk |
Comments
Comment #1
ianthomas_ukSlightly bigger changes than I originally suggested, but they seem to work for me.
Basically this either stores settings in $javascript_settings_data, or pulls them out and clears it. There is no need for the !empty any more, as I'm setting it back to an empty array now rather than unsetting it, so php will just foreach over nothing.
Comment #2
ianthomas_ukMaybe it will be more helpful if I upload the correct patch ;)
Comment #3
mikeytown2 CreditAttribution: mikeytown2 commentedThanks for debugging this. This is definitely related to the fix I put in #2122237: Compatibility problem with Media module's media browser popup, as this bit of code was added in that patch.
Comment #4
mikeytown2 CreditAttribution: mikeytown2 commentedHaving some issues with ctools popups. Will need to look into this more.
Comment #5
mikeytown2 CreditAttribution: mikeytown2 commentedFollowing patch has been committed. Was having issues with jQuery.extend(Drupal.settings) getting outputted as html as well as being a setting. This was causing errors inside of jquery in the extend function.