🇺🇸United States @RoloDMonkey

I had this error. I reviewed and tested the patch, and it all looks good to me.

rolodmonkey → created an issue.

I fixed a few minor issues left over from the merge request.

But, I did find some other problems.

First, the check for the new setting needs to be more careful, both where the default value is set in the form builder and in the ContentSyncHelper->nodeAllowMenuLinkExportEnabled()
If the configuration is not set at all, then it should default to true. Even though it is supposed to be set to true in an update hook, there are cases where that update hook can immediately be overridden; for instance by importing the old config immediately after the update.

Second, there are changes in single_content_sync_preprocess_links__dropbutton__operations() that look like they are from a different issue. Unless these are necessary for this issue to be resolved, they should not be included.

I updated merge request 69 with the latest from 1.4.x and fixed the merge conflicts.

I am going to try using a patch from merge request 69 locally, but I will need other people to review this and see if it is ready.

rolodmonkey → made their first commit to this issue’s fork.

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

This looks like a duplicate? 🐛 Deprecated Function: strlen(): Passing null to parameter #1 ($string) of type string is deprecated in Drupal\key\Plugin\KeyType\EncryptionKeyType->validateKeyValue() (line 124 of modules/contrib/key/src/Plugin/KeyType/EncryptionKeyType.php) Fixed

TLDR:

1. I was also able to make these errors go away by clicking on "Check manually".
2. 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!