@pbouchereau

Wow. #25 sounds so rude and so dense (and actually wrong) compared to how things were said by others.
What reaction was he looking for?
Maybe he just expected you to admit you did not do things the best way and to consider doing them differently next time?
I'm not sure what's worse here, the way you handled this technically or your reaction.
I will certainly be less inclined to recommend the use of this module after reading this.

Great news!
Thanks for fixing this.

This matches the definition of major bugs → :

Trigger a PHP error through the user interface, but only under rare circumstances or affecting only a small percentage of all users, even if there is a workaround.

Since I can't change the status to "closed (won't fix)" I change the title to what was actually fixed.

Thanks @guptahemant but if I got it right your module doesn't prevent queueing to happen, which is what I want.

Here's the backtrace:

#0 /var/www/html/web/modules/contrib/bricks/src/Bricks.php(33): Drupal\bricks\Bricks::newElements()
#1 /var/www/html/web/modules/contrib/bricks/bricks.module(18): Drupal\bricks\Bricks::nestItems()
#2 [internal function]: bricks_preprocess_field()
#3 /var/www/html/web/core/lib/Drupal/Core/Theme/ThemeManager.php(261): call_user_func_array()
#4 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(491): Drupal\Core\Theme\ThemeManager->render()
#5 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(504): Drupal\Core\Render\Renderer->doRender()
#6 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(248): Drupal\Core\Render\Renderer->doRender()
#7 /var/www/html/web/core/lib/Drupal/Core/Template/TwigExtension.php(476): Drupal\Core\Render\Renderer->render()
#8 /var/www/html/vendor/twig/twig/src/Environment.php(391) : eval()'d code(141): Drupal\Core\Template\TwigExtension->escapeFilter()
#9 /var/www/html/vendor/twig/twig/src/Template.php(393): __TwigTemplate_7657e38b4f6b3ec0ecd5db3f277a5355->doDisplay()
#10 /var/www/html/vendor/twig/twig/src/Template.php(349): Twig\Template->yield()
#11 /var/www/html/vendor/twig/twig/src/Template.php(364): Twig\Template->display()
#12 /var/www/html/vendor/twig/twig/src/TemplateWrapper.php(35): Twig\Template->render()
#13 /var/www/html/web/core/themes/engines/twig/twig.engine(33): Twig\TemplateWrapper->render()
#14 /var/www/html/web/core/lib/Drupal/Core/Theme/ThemeManager.php(348): twig_render_template()
#15 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(491): Drupal\Core\Theme\ThemeManager->render()
#16 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(248): Drupal\Core\Render\Renderer->doRender()
#17 /var/www/html/web/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(238): Drupal\Core\Render\Renderer->render()
#18 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(638): Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}()
#19 /var/www/html/web/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(231): Drupal\Core\Render\Renderer->executeInRenderContext()
#20 /var/www/html/web/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(128): Drupal\Core\Render\MainContent\HtmlRenderer->prepare()
#21 /var/www/html/web/core/lib/Drupal/Core/EventSubscriber/MainContentViewSubscriber.php(90): Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse()
#22 [internal function]: Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray()
#23 /var/www/html/web/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111): call_user_func()
#24 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(186): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch()
#25 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(76): Symfony\Component\HttpKernel\HttpKernel->handleRaw()
#26 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/Session.php(53): Symfony\Component\HttpKernel\HttpKernel->handle()
#27 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle()
#28 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/ContentLength.php(28): Drupal\Core\StackMiddleware\KernelPreHandle->handle()
#29 /var/www/html/web/core/modules/big_pipe/src/StackMiddleware/ContentLength.php(32): Drupal\Core\StackMiddleware\ContentLength->handle()
#30 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\big_pipe\StackMiddleware\ContentLength->handle()
#31 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass()
#32 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\page_cache\StackMiddleware\PageCache->handle()
#33 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle()
#34 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/AjaxPageState.php(36): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle()
#35 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/StackedHttpKernel.php(51): Drupal\Core\StackMiddleware\AjaxPageState->handle()
#36 /var/www/html/web/core/lib/Drupal/Core/DrupalKernel.php(741): Drupal\Core\StackMiddleware\StackedHttpKernel->handle()
#37 /var/www/html/web/index.php(19): Drupal\Core\DrupalKernel->handle()
#38 {main}

IMO there is no fix here, only workarounds and for a specific use case on top of that.
The commit retitles the issue to "provide a mechanism to programatically alter purge plugins" which has a substantially different meaning.
The altering doesn't help me as I don't have steady cases where the queuer should be active or inactive.
I have a nightly migration so the queuer has to be deactivated before and activated after.
Correct me if I'm wrong, but If I used the "p-queuer-rm" and "p-queuer-add" commands I'd still have to configure the queuer.
For that I'd either have to proceed to a disproportionately resource intensive full config import, or duplicate the related config files in a separate directory (with the maintenance complication it implies) to do a partial import.
Hopefully I missed something and the issue is actually fixed for all use cases?

@japerry
How is this fixed?
What is the command to disable a queuer?
Per #4, the available solution "isn't a full fix".

Needs steps to reproduce.

Hi,
Sorry I can't do that, as mentioned in #7. My employer forbids it.
I'll try to find time for testing it on a vanilla Drupal installation and confirm whether or not it's related to my project specifically.

Rerolled patch #70 for 10.3.x.
I don't provide an interdiff.txt file, see: https://www.drupal.org/docs/develop/git/using-git-to-contribute-to-drupa... →

The layout entites are Drupal\eck\Entity\EckEntity. Not sure about the formatter, sorry ("container_layout" is selected in the options, is that it?).

I noticed something that might be of interest.
There are actually two bricks fields on this content type. I just tested (module unpatched) creating a new node with multiple instances of the same layout in only one field and the items in the first instance of the layout were missing as "expected", but no error was thrown. I then added an instance of the same layout in the other field and then the error was thrown.
I checked and indeed the already existing node uses the same layout in both fields.

Hi, thanks for your reply.
Sorry, maybe the "needs review" status was misleading.
My post and patch were not supposed to be a solution, it's the start of an investigation and a POC to help you as I can't send you a database dump.
As I said (and you confirmed) I'm not the one who should work on this because I don't know the intricacies (and I don't have time to learn them).
I just want to help move things forward.

About your changes proposal, I don't need to test it because as I explained in #7 the problem lies in the fieldItem() function, which you don't touch in this piece of code. It's just a better version of AndrewsizZ's patch.
Sure, it would not throw an "Object not found" error anymore, but just by concealing the issue, not actually fixing it. With this fix I would still have missing items on my page.
Have you seen what I get when I dump the return of fieldItem() ? One instance of the same layout is replaced with another instance, it's completely abnormal and why I get an "Object not found" error.
This function must get fixed.

Let me know if there's anything else I can test to help you.

Sorry, I just noticed that I didn't make it clear in #4 what I was reproducing.
It's just the error in the title of the issue, not the IS.

Hi,
Thanks for your proposal but it's a customer site and sharing a database is not an option.
I tracked it down to the fieldItem() function.
In newElements() I dumped $parent_items before the foreach() loop and got this:

SplObjectStorage {#6765 ▼
  storage: array:4 [▼
    0 => {▼
      object: Drupal\bricks\Plugin\Field\FieldType\BricksTreeItem {#3433 ▶}
      info: class@anonymous {#6770}
    }
    1 => {▼
      object: Drupal\bricks\Plugin\Field\FieldType\BricksTreeItem {#3435 ▶}
      info: Drupal\bricks\Plugin\Field\FieldType\BricksTreeItem {#3433 ▶}
    }
    2 => {▼
      object: Drupal\bricks\Plugin\Field\FieldType\BricksTreeItem {#3437 ▶}
      info: class@anonymous {#6770}
    }
    3 => {▼
      object: Drupal\bricks\Plugin\Field\FieldType\BricksTreeItem {#3439 ▶}
      info: Drupal\bricks\Plugin\Field\FieldType\BricksTreeItem {#3437 ▶}
    }
  ]
}

Where objects are #3433, #3435, #3437, #3439 and where #3433 and #3437 are two instances of the same layout.

Then in the foreach() loop I dumped the return of static::fieldItem($content) and got this:

Drupal\bricks\Plugin\Field\FieldType\BricksTreeItem {#3437 ▶}
Drupal\bricks\Plugin\Field\FieldType\BricksTreeItem {#3435 ▶}
Drupal\bricks\Plugin\Field\FieldType\BricksTreeItem {#3437 ▶}
Drupal\bricks\Plugin\Field\FieldType\BricksTreeItem {#3439 ▶}

Where the first layout instance #3433 is replaced with the second one #3437.

I don't know all the intricacies of the module and the need behind the fieldItem() function, but we already have the BricksTreeItems in the $items variables, so I simply fixed both bugs (object not found + 3301816) by replacing "$field_item = static::fieldItem($content)" with "$field_item = $items[$key]".

I join a patch that is working in my case.

+1

Re #11, #19, #20, #29.
It seems established that, and I confirm it, opinion and needs on this subject vary depending on the user.
Why is this forced on users then? Is this a CMS or a dictatorship?
A "do not limit editing form width" checkbox in the theme parameters would be nice.
To me white space around the form looks as much silly as inside it.
And it's worse from an ergonomic point of view when you use the Bricks module for example.

I found this issue that is related, the patch seems to have similarities with your major depth fixing patch.
You might want to close it.

https://www.drupal.org/project/bricks/issues/3295645 →

Hi,

I'm reproducing this after a D9 > D10 upgrade, updating Bricks from 2.0.1 to 2.1.2, but only on one page so far.
After quickly fixing this error to see if the page would load, I noticed another issue that should normally be fixed in this version of the module: only the "latest" reuse of a layout have its children visible (reported here: https://www.drupal.org/project/bricks/issues/3301816 🐛 Repeated layouts are missing their children Fixed ).

Let me know what information you'd need to investigate on this.

Hi,

Thanks for the fast reply.
I actually had this mixed up in my head. The issue I was facing was solely due to the customer's configuration.
Sorry for bothering you, I'll check thrice before posting next time.
Have a nice day.

Hi.

Isn't this wrong?
If I understand well, what was committed is checking for a difference of the "allowed terms" field in the user form before rebuilding content access.
But doesn't this module work the other way around too? With a "roles allowed" in the term form?
If that's the case, by restricting the checking of difference in the user form to terms for performance reasons, isn't a security issue introduced?
If I change the roles of a user, shouldn't content access be rebuilt to match the roles eventually assigned to terms?

Wow... I really need some sleep.
I confused the "Working as expected" comment with the status.
Sorry for the noise on this issue.
I suppose it's ok to unassign @kuldeep_mehra27 ?

Ok. The title and description are broad.
The patch though is very specific and now that I've looked at it I understand why the issue was closed.
I still leave it open for visibility.

No, it doesn't.
See https://www.drupal.org/project/captcha/issues/3375618#comment-15333248 ✨ Allow using "default" #captcha_type for the captcha form element Active

Hi,

The mentioned code snippet was executed in image_captcha.module file in previous versions.
It hasn't been ported to the imageCaptchaAfterBuildProcess() function in ImageCaptchaRenderService.php.

Because of this my setup partly broke when I updated.
I had "Image captcha" set as default in captcha global settings and "default" set in a captcha point for my user login form.
After updating the reload button was not displayed anymore because the image captcha type was not detected.

Hi.
Without a related issue it's not really a duplicate.

Isn't this a duplicate of 2973478 🐛 Aliases are not created for affected translations RTBC ?

Hi.
This has broken ajax in 'modules/ajax_quiz/ajax_quiz.module' :

    // Add ajax to each submit button.
    $nav_children = Element::children($form['navigation']);
    foreach ($nav_children as $nav_child) {
      if (isset($form['navigation'][$nav_child]['#type']) && $form['navigation'][$nav_child]['#type'] == 'submit') {
        $form['navigation'][$nav_child]['#ajax'] = $ajax;
      }
    }

@j-ayen-green did you notice that it's precisely what the first reply was suggesting?
Sorry, I'm digging this up... but it's never too late to learn from your mistakes, right? ;)

If I got it right, it seems to work as designed.

Patch #16 doesn't apply to version 3.1.22.
Just a re-roll.

Here's patch #33 re-rolled without mysterious filename change...

Rerolled patch #33.

Ok, I think I see.
The issue's title and summary focus on the backend part of the problem, which should indeed be handled by validation.
But what brought me here is the mess caused by this bug on frontend: when it occurs, the whole paragraph/brick subform gets replaced by other unrelated fields.
What can be lost is not saved data, just contributed content.
Unless I miss something, I don't think this will get fixed with 📌 Offer concurrent editing protection for all entities by including the changed timestamp to each entity form Needs work , will it?
If not, what's the best way to handle this, change this issue's title and summary or create a new one?

This is not fixed, I'm still experiencing this on a Drupal 9.4.9 project with bricks form and on a Drupal 9.5.9 project with paragraphs.
And how could this be marked as a duplicate of an issue tied to the entity system component? That's disregarding the comment in #41 about non-entity forms that made catch move this to the forms system component.
I also disagree about the category change. To me, if a form breaks when clicking on a button, it's a bug (sorry if there's something I'm not aware of about issues categorizing).

Hiding patch per #49.

Hello.
I'm not used to versioning, would you please explain to me why this hasn't landed in a stable 8.x-3.x version?

Rerolled patch #80.

@sleitner
And without a missing file too... learning the hard way.
Thanks.

Rerolled patch with git format.

Rerolled patch.