500 Internal Server Error

It would be helpful if you could write about your Drupal version and the error that you must get at admin/reports/dblog

Zeg, had the same issue and was about to use your workaround when I noticed the comment at the top of development.service.yml: "To activate this feature, follow the instructions at the top of the 'example.settings.local.php' file, which sits next to this file." It reminded me that I enabled "settings.local.php" a while back when I began my project so that I could disable some caching systems. I just deleted settings.local and everything seems to work now. So, perhaps caching ultimately has something to do with this or there's another setting in settings.local that causes this issue. If you're not using settings.local then this is probably not a fix and I'll probably see this 500 error again. If so, I'll use your workaround.

The workaround worked for me.

We have a local-only services.local.yml file with twig debugging settings that can be uncommented when in use. So our services.local.yml file looks like when in use:

# Do not commit the changes on this file.
parameters:
  # Resolves 500 error for edit pages: https://www.drupal.org/project/paragraphs/issues/3197720
  http.response.debug_cacheability_headers: false
  # Uncomment the lines below to enable debugging.
  twig.config:
    debug: true
    auto_reload: true
    cache: false

Within the settings.php file, there is a check to verify if this is a local environment. If so, something like this recognizes the local file:

if (file_exists($app_root . '/' . $site_path . '/services.local.yml')) {
  $settings['container_yamls'][] = $app_root . '/' . $site_path . '/services.local.yml';
}

Has anyone confirmed for certain that the problem is only from http.response.debug_cacheability_headers:true and that the other developer settings aren't also interfering? If so, it might be possible for Entity Reference Revision or Paragraphs to work around this setting, or at least display a warning that it's set.

Same problem here, unfortunately removing or changing the code doesn't work for me.
http.response.debug_cacheability_headers: true
Any suggestions on how to solve this?

FWIW once you set http.response.debug_cacheability_headers to "false", or remove the line from all services.yml files loaded on the site, you have to rebuild the caches in order for Drupal to pick up the changed value.

Thanks for the reply, I found out my problem was because of an infinite loop.

To reproduce:

• Add one paragraph
• Add a field to add a nested paragraph
• On node level add a paragraphs field

Because there is one paragraph this is added by default and because the paragraph has a nested paragraph it keeps adding paragraphs till a 500 error occurs. So if this is your setup make sure the paragraph is not added by default.

Has anyone confirmed for certain that the problem is only from http.response.debug_cacheability_headers:true and that the other developer settings aren't also interfering?

I can confirm that the http.response.debug_cacheability_headers setting is indeed what's causing the issue for me. Never ran into this before today.

To trigger the issue, I added a boolean field to one paragraph and all was well. However if I added that same field (e.g. reused the field) to another paragraph that appears within a 'field_flexible_content' field (which is a entity_reference_revision field), I got the whitescreen/500 error. Both paragraphs are nested within the same node and both have content, fwiw.

This is my development.services.yml:

# Local development services.
#
# To activate this feature, follow the instructions at the top of the
# ‘example.settings.local.php’ file, which sits next to this file.
parameters:
  http.response.debug_cacheability_headers: false  #<-when this is true i get a whitescreen/500 error on node/edit
  twig.config:
    # Twig debugging:
    #
    # When debugging is enabled:
    # - The markup of each Twig template is surrounded by HTML comments that
    #   contain theming information, such as template file name suggestions.
    # - Note that this debugging markup will cause automated tests that directly
    #   check rendered HTML to fail. When running automated tests, ‘debug’
    #   should be set to FALSE.
    # - The dump() function can be used in Twig templates to output information
    #   about template variables.
    # - Twig templates are automatically recompiled whenever the source code
    #   changes (see auto_reload below).
    #
    # For more information about debugging Twig templates, see
    # https://www.drupal.org/node/1906392.
    #
    # Not recommended in production environments
    # @default false
    debug: true
    # Twig auto-reload:
    #
    # Automatically recompile Twig templates whenever the source code changes.
    # If you don’t provide a value for auto_reload, it will be determined
    # based on the value of debug.
    #
    # Not recommended in production environments
    # @default null
    auto_reload: null
    # Twig cache:
    #
    # By default, Twig templates will be compiled and stored in the filesystem
    # to increase performance. Disabling the Twig cache will recompile the
    # templates from source each time they are used. In most cases the
    # auto_reload setting above should be enabled rather than disabling the
    # Twig cache.
    #
    # Not recommended in production environments
    # @default true
    cache: false
services:
  cache.backend.null:
    class: Drupal\Core\Cache\NullBackendFactory

Interesting...

I had to add that reused field to yet another paragraph (so now 3 paragraphs have that field). Truth be told, I need to add it to at least 4 more.

After adding it to the 3rd one, the 500 error is back on node/edit regardless of the http.response.debug_cacheability_headers setting (true or false).

EDIT: After uninstalling pantheon_advanced_page_cache I'm back in business.

I also ran into this problem with an infinite recursion loop with a self-referencing paragraph.

Seems like there might be two issues discussed in this thread. I don't think my issue had anything to do with caching.

For me, I had a paragraph that had a paragraph field that only included the same paragraph type (to create a tree/hierarchy). Creating the default paragraph in the widget caused a loop and the process runs out of memory. It can be fixed by just not including a default paragraph form.

1. Under "Manage form display" for the paragraph type, edit the widget settings for the paragraph field.
2. Set "Default paragraph type" to. "--none--".

This is a quick workaround if you notice the issue but the error isn't obvious. It would be nice if the module identified this kind of reference cycle and did not generate a default paragraph in the field if it will cause the error.

I'm happy to come take a look at this but it will be a bit before I can dedicate time to it.

I also ran into this problem with an infinite recursion loop with a self-referencing paragraph.

...

2. Set "Default paragraph type" to. "--none--".

Workaround from above worked.

Stack trace:

Error: Xdebug has detected a possible infinite loop, and aborted your script with a stack depth of '256' frames in Drupal\Core\TypedData\TypedData->getRoot() (line 163 of core/lib/Drupal/Core/TypedData/TypedData.php).
Drupal\Core\TypedData\TypedData->getRoot() (Line: 165)
Drupal\Core\TypedData\TypedDataManager->getPropertyInstance() (Line: 123)
Drupal\Core\TypedData\Plugin\DataType\Map->get() (Line: 40)
Drupal\Core\Field\Plugin\Field\FieldType\StringItemBase->isEmpty() (Line: 93)
Drupal\Core\Field\FieldItemList->Drupal\Core\Field{closure}()
call_user_func() (Line: 278)
Drupal\Core\TypedData\Plugin\DataType\ItemList->Drupal\Core\TypedData\Plugin\DataType{closure}()
array_filter() (Line: 277)
Drupal\Core\TypedData\Plugin\DataType\ItemList->filter() (Line: 92)
Drupal\Core\Field\FieldItemList->filterEmptyItems() (Line: 179)
Drupal\Core\Field\FieldItemList->applyDefaultValue() (Line: 271)
Drupal\Core\Entity\ContentEntityStorageBase->initFieldValues() (Line: 129)
Drupal\Core\Entity\ContentEntityStorageBase->doCreate() (Line: 94)
Drupal\Core\Entity\ContentEntityStorageBase->create() (Line: 1305)
Drupal\paragraphs\Plugin\Field\FieldWidget\ParagraphsWidget->formMultipleElements() (Line: 120)
Drupal\Core\Field\WidgetBase->form() (Line: 1512)
Drupal\paragraphs\Plugin\Field\FieldWidget\ParagraphsWidget->form() (Line: 190)
Drupal\Core\Entity\Entity\EntityFormDisplay->buildForm() (Line: 843)
Drupal\paragraphs\Plugin\Field\FieldWidget\ParagraphsWidget->formElement() (Line: 459)
Drupal\Core\Field\WidgetBase->formSingleElement() (Line: 1390)
Drupal\paragraphs\Plugin\Field\FieldWidget\ParagraphsWidget->formMultipleElements() (Line: 120)
...
Drupal\Core\Field\WidgetBase->form() (Line: 1512)
Drupal\paragraphs\Plugin\Field\FieldWidget\ParagraphsWidget->form() (Line: 190)
Drupal\Core\Entity\Entity\EntityFormDisplay->buildForm() (Line: 121)
Drupal\Core\Entity\ContentEntityForm->form() (Line: 134)
Drupal\node\NodeForm->form() (Line: 107)
Drupal\Core\Entity\EntityForm->buildForm()
call_user_func_array() (Line: 536)
Drupal\Core\Form\FormBuilder->retrieveForm() (Line: 375)
Drupal\Core\Form\FormBuilder->rebuildForm() (Line: 633)
Drupal\Core\Form\FormBuilder->processForm() (Line: 326)
Drupal\Core\Form\FormBuilder->buildForm() (Line: 73)
Drupal\Core\Controller\FormController->getContentResult()
call_user_func_array() (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber{closure}() (Line: 638)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 121)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber{closure}() (Line: 181)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle() (Line: 116)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 90)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 741)
Drupal\Core\DrupalKernel->handle() (Line: 19)

I had a 500 error when loading multiple nested paragraphs and removing `http.response.debug_cacheability_headers: true` ended up fixing this issue for me.

Edit: I'm guessing this is actually indirectly related to the quantity of cache tags being added to the page by the paragraphs since the error I was seeing in the logs were related to proxy_fcgi headers ie.
```
Premature end of script headers: index.php
AH01070: Error parsing script headers
```