Sometimes, Drupal is rendering a paragraph many times but it isn't technically recursive. For instance, you may have a paragraph that embeds a call-to-action block on lots of different pages. If you are indexing pages for search, you may end up rendering that block more than 20 times in the same PHP process. That is what happened to me while migrating hundreds of pages. A similar thing can happen if you have the same webform on many pages.
I am sure there are other scenarios where you can trip the recursive rendering failsafe, but you aren't technically caught in a loop.
I just saw this error with version 5.0.4 doing the same steps as described in the description:
- Click on "Reset Last Pull Date"
- When the page reloads, click on "Reset Last Deleted Date"
My guess is that the form key is not getting reset the right way after clicking the first button, and when the page reloads it has an expired/invalid form key, or something like that. Here is a full backtrace:
#0 /var/www/html/web/core/lib/Drupal/Component/Plugin/LazyPluginCollection.php(80): Drupal\Core\Plugin\DefaultLazyPluginCollection->initializePlugin(0)
#1 /var/www/html/web/core/lib/Drupal/Component/Plugin/LazyPluginCollection.php(149): Drupal\Component\Plugin\LazyPluginCollection->get(0)
#2 /var/www/html/web/core/lib/Drupal/Core/Plugin/DefaultLazyPluginCollection.php(114): Drupal\Component\Plugin\LazyPluginCollection->getIterator()
#3 /var/www/html/web/core/lib/Drupal/Core/Config/Entity/ConfigEntityBase.php(352): Drupal\Core\Plugin\DefaultLazyPluginCollection->getConfiguration()
#4 [internal function]: Drupal\Core\Config\Entity\ConfigEntityBase->__sleep()
#5 /var/www/html/web/core/lib/Drupal/Component/Serialization/PhpSerialize.php(14): serialize(Array)
#6 /var/www/html/web/core/lib/Drupal/Core/KeyValueStore/DatabaseStorageExpirable.php(111): Drupal\Component\Serialization\PhpSerialize::encode(Array)
#7 /var/www/html/web/core/lib/Drupal/Core/KeyValueStore/DatabaseStorageExpirable.php(127): Drupal\Core\KeyValueStore\DatabaseStorageExpirable->doSetWithExpire('form-K9Pyone5pz...', Array, 21600)
#8 /var/www/html/web/core/lib/Drupal/Core/Form/FormCache.php(193): Drupal\Core\KeyValueStore\DatabaseStorageExpirable->setWithExpire('form-K9Pyone5pz...', Array, 21600)
#9 /var/www/html/web/core/lib/Drupal/Core/Form/FormBuilder.php(463): Drupal\Core\Form\FormCache->setCache('form-K9Pyone5pz...', Array, Object(Drupal\Core\Form\FormState))
#10 /var/www/html/web/core/lib/Drupal/Core/Form/FormBuilder.php(441): Drupal\Core\Form\FormBuilder->setCache('form-K9Pyone5pz...', Array, Object(Drupal\Core\Form\FormState))
#11 /var/www/html/web/core/lib/Drupal/Core/Form/FormBuilder.php(633): Drupal\Core\Form\FormBuilder->rebuildForm('salesforce_mapp...', Object(Drupal\Core\Form\FormState), Array)
#12 /var/www/html/web/core/lib/Drupal/Core/Form/FormBuilder.php(325): Drupal\Core\Form\FormBuilder->processForm('salesforce_mapp...', Array, Object(Drupal\Core\Form\FormState))
#13 /var/www/html/web/core/lib/Drupal/Core/Controller/FormController.php(73): Drupal\Core\Form\FormBuilder->buildForm(Object(Drupal\salesforce_mapping_ui\Form\SalesforceMappingEditForm), Object(Drupal\Core\Form\FormState))
#14 [internal function]: Drupal\Core\Controller\FormController->getContentResult(Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Routing\RouteMatch))
#15 /var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array(Array, Array)
#16 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(627): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#17 /var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(121): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
#18 /var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array)
#19 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(181): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#20 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(76): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#21 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/Session.php(58): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#22 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#23 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/ContentLength.php(28): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#24 /var/www/html/web/core/modules/big_pipe/src/StackMiddleware/ContentLength.php(32): Drupal\Core\StackMiddleware\ContentLength->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#25 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\big_pipe\StackMiddleware\ContentLength->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#26 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#27 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#28 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#29 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/AjaxPageState.php(36): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#30 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/StackedHttpKernel.php(51): Drupal\Core\StackMiddleware\AjaxPageState->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#31 /var/www/html/web/core/lib/Drupal/Core/DrupalKernel.php(704): Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#32 /var/www/html/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#33 {main}
I was experiencing this issue and the patch fixed it. This is probably only happening because I am running PHP 8.2+.
I also agree that this might not be the best long-term solution
Here is a link to the quirk mentioned in the summary.
https://www.php.net/manual/en/function.empty.php#:~:text=named%20arguments.-,Note%3A,-When%20using%20empty
RoloDMonkey → created an issue.
If you are running 4.0.x with PHP 8.2 you may still see this error. If so, you can use this link to patch it.
https://git.drupalcode.org/project/smart_date/-/merge_requests/63.patch
The other error when $element[0] is empty is not directly related to this one.
I created 🐛 Javascript warning from content language and translation page Fixed for that error, and provided a fix.
As far as I can tell, this issue is not fixed by 🐛 contentTranslationDependentOptions behavior doesn't check if found element array is empty RTBC . That is a very similar issue in the same file, but not in the same place.
The merge request "failure" was just some suggested whitespace changes. I have made those changes and everything is passing now.
Since it has been more than a year since this was marked RTBC, and people are still actively debating the correct solution, I am bumping this back down to "Needs work".
RoloDMonkey → created an issue.
I have applied this patch while running Drupal 10.2.0 and it works.
Expected behavior:
When the main entity type, like Article, is translatable the fields under the article should always be expanded. On the other hand, if the translatable checkbox next to an entity type is not checked then its fields should not be visible.
The fields will become visible if you are clicking the translatable checkbox for the first time, or if you turn it off and then back on again. But, they are not expanded when the page first loads. That is why I marked this as a major issue, because right now there isn't a way to accurately view and manage which fields are translatable through the UI.
RoloDMonkey → created an issue.
Is the 4.1 branch set up for automated testing? If so, the patch needs to be submitted in the correct way so that it will trigger automated testing.
This is a duplicate of 🐛 User deprecated function - warning Needs review .
I also couldn't make heads or tails of those tables. Right now, it looks like someone copied and pasted the tables without changing the release versions. Either that, or there were going to be multiple releases of the same versions on completely different schedules.
We definitely need to include some way to let visitors know that each table is a possible release schedule.
RoloDMonkey → created an issue. See original summary → .
This looks like a duplicate? 🐛 Error: Call to a member function getKeyValue() on null and Deprecated function: strlen(): Passing null to parameter #1 ($string) Active
TLDR:
- I was also able to make these errors go away by clicking on "Check manually".
- This might be a problem with how Drupal provides dev versions of modules via Composer
I just saw this when checking /admin/reports/translations. Six modules threw this warning. In four cases, we required a dev version in composer.json. In one case it was a module that had not been in the codebase for months. I don't know how to explain that.
For the four cases where we were pulling dev versions of modules, the .info.yml files did not have a project, for instance:
name: Admin Toolbar
description: Provides an improved drop-down menu interface to the site Toolbar.
package: Administration
type: module
configure: admin_toolbar.settings
core_version_requirement: ^9.2 || ^10
dependencies:
- drupal:toolbar
In other cases, the project was added when pulling the module from Drupal, like so:
name: 'Block Class'
type: module
description: 'Allows assigning the classes to Blocks.'
package: User interface
configure: block_class.settings
core: 8.x
core_version_requirement: ^8 || ^9 || ^10
dependencies:
- drupal:block
# Information added by Drupal.org packaging script on 2022-12-26
version: '2.0.11'
project: 'block_class'
datestamp: 1672065315
The last case was CTools, which was surprising. It looks like our composer.lock file still thought that CTools was required by Pathauto, even though that is no longer the case, and we did not have CTools enabled.
This is still an issue. If you have this module installed, and you enable Actions, then when you go to configure actions (/admin/config/system/actions) you get a fatal error.
This module needs to be compatible with core. A hidden requirement for Views Bulk Operations is not good.
See also: https://www.drupal.org/project/views_bulk_edit/issues/3173187#comment-14... →
Attended
Thanks to everyone for fixing this! I have been putting up with my terminal being flooded by duplicate messages while I tested and re-tested a pretty complex migration. I never had time to look into why it was happening.
Today, it took me a moment to realize that I only saw one line/notice in my terminal for each migration. What a pleasant surprise!