Panels' recent beta release 8.x-3.0-beta5 claimed to have implemented the Wizard API, which would lead me to believe that this issue was resolved. Well, I updated Page Manager to 8.x-1.0-alpha24 and Panels to 8.x-3.0-beta5 at the same time and, things appears all good immediately following the updates. I went to edit one of my page's that used a panel variant, and the UI had changed, reflecting the new Wizard API layout, and I was actually able to view the panel variant properly and see all of my content blocks, which was not the case under the circumstances which caused me to originally open this issue.

However, once I tried to add a block to my panels variant and click "Update and save", all hell broke loose. It brought me to the dreaded Nginx 502 Bad Gateway error screen. I hit the back button and tried to just click "save" instead of "Update and save", and that brought me back to the nginx 502 error page. And now I get the nginx 502 error page whenever I try to hit any url on my site. Trying to make sense of the error logs now, but they are kind of cryptic.

Clearing cache through stale tab using admin toolbar's "Flush all caches" resulted in 502 error page. Clearing site caches through Pantheon site manager also did not work. The only way I could get the site to operate was by drush cr (using Terminus, since its a Pantheon site). However, once I tried to navigate to my page with the Panel variant, the 502-on-every-page issue came back. This time I couldn't even view the variant edit page. So i ran drush cr to bring the site back, then played around with a page that did NOT include a panel variant. I was able to edit the content, save and update--there was some quirkiness, but it worked. I then went to my page with a panel variant, and I could now access that page. I could event access the Panel variant's content section. However, upon hitting "Update and save", the same 502-on-every-page issue came back. And now, running drush cr will not bring my site back to life.

I'll need to roll back to a backup. But Id suggest anyone running a production site to not move forward with these updates. Or, if you have done so (production or not), I'd love to hear feedback from people who aren't experiencing this issue.

EDIT: changed title according to comment #12 in related issue. I did manage to test the ability to add a new page with panel variant, as my site became completely non-functional, but @andypost reports in the linked comment above that the issue is tied specifically to editing pages with panel variants that existed before the update to Page Manager 8.x-1.0-alpha24 and Panels 8.x-3.0-beta5

CommentFileSizeAuthor
#3 2016-10-27.png96.17 KBidcm
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

xeM8VfDh created an issue. See original summary.

xeM8VfDh’s picture

xeM8VfDh CreditAttribution: xeM8VfDh commented
Title: Saving changes to Page with Panels Variant crashes site (Page Manager to 8.x-1.0-alpha24 + Panels to 8.x-3.0-beta5) » Saving changes to preexisting page with preexisting panels variant crashes site after updating to Page Manager 8.x-1.0-alpha24 and Panels 8.x-3.0-beta5
Issue summary: View changes
idcm’s picture

idcm CreditAttribution: idcm commented
FileSize
2016-10-27.png96.17 KB

I just experienced this issue. I also had an issue prior to adding to a pre-existing.

I started by creating a page. I added a block, then tried to add another. When I clicked on a block to add, I get a quick glimpse of the icon indicating processing, then nothing.

I saved the page and returned, thinking maybe it needed to be saved. That triggered the 502 issue. See screen shot attached.

I am on core 8.2.1
Panels 8.x-3.0-beta5
Panels IPE
Page manager and UI 8.x-1.0-alpha24
Layout plugin 8.x-1.0-alpha23

xeM8VfDh’s picture

xeM8VfDh CreditAttribution: xeM8VfDh commented

Thanks for corroborating @idcm!

idcm’s picture

idcm CreditAttribution: idcm commented

Update. I can no longer click edit for any of the page templates (custom or node view) it goes straight to 502.

@xeM8VfDh - no worries :-)

idcm’s picture

idcm CreditAttribution: idcm commented

Another update. I just created a page but instead of using standard, i set it to IPE. Then went to page url and used IPE to set blocks. When I returned to Pages, i was able to click edit for the this test page and it did not go to the 502 issue.

xeM8VfDh’s picture

xeM8VfDh CreditAttribution: xeM8VfDh commented

hmm, that might be a good clue into how the devs might be able to fix this. As usual, thanks for the very helpful info!

nplowman’s picture

nplowman CreditAttribution: nplowman at FFW commented

I'm experiencing similar symptoms. However, rather than getting a 502 Bad Gateway page, I'm getting this error:
Warning: htmlspecialchars() expects parameter 1 to be string, array given in Drupal\Component\Utility\Html::escape() (line 421 of core/lib/Drupal/Component/Utility/Html.php)

Afterwards, I'll get this on basically every single page load:
PHP Fatal error: Aborting! The New Relic imposed maximum PHP function nesting level of '5000' has been reached. This limit is to prevent the PHP execution from catastrophically running out of C-stack frames.

Restarting Apache will resolve the issue. But as soon as I go back to a Panels page and try to update and save, it returns.

xeM8VfDh’s picture

xeM8VfDh CreditAttribution: xeM8VfDh commented

Thanks for the infor @nplowman! I have not seen that error, but have seen similar errors after accidentally setting up bad alias/redirect combinations that ended up being self-referential. Sorry I don;t have more concrete info to provide for fixing your specific issue.

It sounds like Page Manager 8.x-1.0-alpha24 + Panels 8.x-3.0-beta5 is a problematic release combo various ways. For the time being I'll stick to Page Manager 8.x-1.0-alpha23 + Panels 8.x-3.0-beta4. It lacks the API wizard, but does seem to work without all of the headaches mentioned above.

g3r4’s picture

g3r4 CreditAttribution: g3r4 at Bixal commented

Hey guys, I've been experiencing this from previous versions as well hoping that it would get fixed in this dev-version, I try to did a little bit of debugging and there is something definitely messing up with php-fpm service, whenever I get the 502 error I restart my php-fpm service most of the times once, but could take a couple of restarts and eventually the page would load and the site would work, I am using PHP 7 now, but it breaks on PHP 5 as well, the only thing I run is:

sudo service php7.0-fpm restart

And sometimes clearing the cache after that works:

drupal cr all

This happens to me with Page variants saved from previous versions, as well as new Page variants being created with this version, sometimes I only get this error when creating a new variant:

The website encountered an unexpected error. Please try again later.

Hope this helps someone having this problem and the maintainers to find this bug.

PS: I am using the latest dev versions of Panels, Page Manager, and Layout Plugin.

xeM8VfDh’s picture

xeM8VfDh CreditAttribution: xeM8VfDh commented

thanks for the info @g3r4. Does the fpm restart actually fix the problem (are you allowed to save pre-existing Panel variants after doing so?), or does it just make the endless 502 error go away so you can continue using other parts of the site?

g3r4’s picture

g3r4 CreditAttribution: g3r4 at Bixal commented

Hi @xeM8VfDh. The fpm restart fixes the problem, meaning that the panel variant gets saved after restarting the fpm service and reloading the page, it has been my workaround in order to save and modify the variants and the actual content being put in there, because sometimes I get the same error when I hit update and save after adding or removing a view block for example in the panels interface.

xeM8VfDh’s picture

xeM8VfDh CreditAttribution: xeM8VfDh commented

huh, that's interesting. Do you have to execute this workaround after each edit of said panel variants, or do you just have to do it after the first edit (after updating modules) of the panle, after which you can edit it freely without problems? Thanks again!

g3r4’s picture

g3r4 CreditAttribution: g3r4 at Bixal commented

I execute it whenever it crashes, it does not crash every time I add or save the variant, but when it does, I have to restart the service

falster’s picture

falster CreditAttribution: falster commented

Have also done the upgrades. And I had an rather related issue, if it could be of help.

Created an new page with panels. In it there is an custom block. And I transferred it to my stage-site with config mgmt. On the stage site the custom block was missing, re-created it on the stage site. When I pressed delete on the block, and then tried to add the newly created block, the page went white and I got an "Service Unavailable".

And... now I can't get rid of the "Service Unavailable" on that edit page. Tried emptying cache meny times..

xeM8VfDh’s picture

xeM8VfDh CreditAttribution: xeM8VfDh commented

Thanks @falster for contributing your experience.

Seeing as this is a rather detrimental bug (breaks usability of the site) that many users have corroborated, I'm wondering if any Panels devs care to weigh in. Even a simple acknowledgement of "we recognize this as an issue and will look into it" would be helpful.

xeM8VfDh’s picture

xeM8VfDh CreditAttribution: xeM8VfDh commented

Updating my experience. I tried removing all of my panels variants, then updating Panels and Page Manager modules to the releases discussed here, with the hoped of recreating my panels pages later. This initially seemed to work, but weird behavior ultimately gave way to the dreaded "502 Bad Gateway" error. Internal logging reveals:

[19-Dec-2016 09:39:18 America/Denver] PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes) in [*MY_ROOT*]/core/modules/views/src/Plugin/views/PluginBase.php on line 182
[19-Dec-2016 09:39:49 America/Denver] PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 32768 bytes) in [*MY_ROOT*]/core/lib/Drupal/Core/Cache/Cache.php(57) : assert code on line 1
[19-Dec-2016 09:39:49 America/Denver] PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 4096 bytes) in [*MY_ROOT*]/core/lib/Drupal/Core/Database/Query/Condition.php on line 233
[19-Dec-2016 09:42:13 America/Denver] PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes) in [*MY_ROOT*]/core/modules/views/src/Plugin/views/PluginBase.php on line 182

We could adjust our php.ini to increase memory, but that sounds like a workaround to me, not a fix (unless a project developer can make a compelling case).

Seeing as this issue is preventing people from installing a "Security Update" (Panels 8.x-3.0-beta5), it seems to be a critical issue. Would one of the developers mind chiming in on this?

xeM8VfDh’s picture

xeM8VfDh CreditAttribution: xeM8VfDh commented
Priority: Major » Critical
Berdir’s picture

Berdir
Primary language German
Location Switzerland
CreditAttribution: Berdir at MD Systems GmbH commented

This sounds like it might be another variant of the serialization problems fixed/avoided by #2831521: Avoid unserialization of blockPluginCollection in BlockDisplayVariant. Try the patch there, also make sure you're on the latest core version that has the referenced issue fixed.

xeM8VfDh’s picture

xeM8VfDh CreditAttribution: xeM8VfDh commented

Thanks @Berdir!!! If I am running Chaos tool suite (ctools) 8.x-3.0-alpha27 should I be all good? if so, I will test this out again. If not, can you explain more explicitly what versions of what I need to be on to test this? (sorry for not being able to put it together myself)

xeM8VfDh’s picture

xeM8VfDh CreditAttribution: xeM8VfDh commented

UPDATE: The issue is resolved by implementing this ctools patch mentioned here from Drupal core 8.2.5 . Thank you VERY much @Berdir for the patch, and for chiming in on this ticket after recognizing it's a product of the same root cause!

Hopefully your change in #11802485 gets committed and released soon!

andypost’s picture

andypost
he/him
Primary language Russian
CreditAttribution: andypost as a volunteer and at Skilld commented
Status: Active » Closed (duplicate)
Related issues: +#2831521: Avoid unserialization of blockPluginCollection in BlockDisplayVariant

Duplicate of #2831521: Avoid unserialization of blockPluginCollection in BlockDisplayVariant