🇧🇪Belgium @Tim Lammar

Updated patch to work with D10.2.4

Rework of #16 with removal of first (I think debug?) change.
Tested on local D10.2.4.

apparently my previous patch (rename from #40) would not apply to 10.2.x
Made some changes and this one should.

Copy of patch #40 but with correct extension (without the '.txt').
Looks like this patch would be able to work on D10.2.x

Ah yes apologies, my patch is written in D10.

I had the same issue.
I wanted to hook in on layout builder rendering blocks.
The patch was not yet a fix for me, but it might be edge case.
Technically there is a small issue with this patch.
We are launching an alter hook on block_view, but it is launched during the build of the block.
In most cases, that nuance won't make a difference, but in my case it does as our blocks are loading with lazy loading.
In short that makes it go like this
1. Page load
2. hook_block_build to set placeholders for the blocks.
3. Response
4. Ajax calls to set to contents per block
5. hook_block_view to fill the contents
6. Response per block

If you aren't using lazy_builder, it doens't matter whether you hook into block_build or block_view.
But to be correct, it has to be block_build as we are in the build stage of layoutbuilder:

/**
   * Builds render arrays for block plugins and sets it on the event.
   *
   * @param \Drupal\layout_builder\Event\SectionComponentBuildRenderArrayEvent $event
   *   The section component render event.
   */
  public function onBuildRender(SectionComponentBuildRenderArrayEvent $event) {

Hereby a patch that launches block_build_alter instead of block_view_alter.
With this you can make alterations to the page, based on a block, before the page is loaded. (in our case, a page redirect)

typo + fix extra issue: ->guess() => ->guessMimeType()

In general yes of course.
I don't expect this patch to be rolled in.
I am just in the situation where we have to wait to update to 3.1, but have production issues now with 3.0.1 in combination with D10.
I just thought to share the patch in the case there might be others with the same situation.

Extended the patch with Dispatch error (order of arguments changed in symfony) and no default accessChecks anymore on entityQuerries but are required.

Rewrite the JS once functionalities according to the D10 requirements

Exactly, but apparently it did 🤷‍♂️

I don't remember exactly what errors occurred, but it had to do with the fact that in the code there are array methods used on toolbar items. These are in this case non existing and so causing php errors (something like expecting array, got NULL).
The patch I provided in the previous ticket fixed the ones I encountered, but it's possible other places need to be fixed as well (ref: https://www.drupal.org/project/drupal/issues/3372452#comment-15136932 🐛 When a textformat has no text-editor configured ckeditor crashes Closed: duplicate )

@Wim Leers,
Sure :-)
Our use case is we have a text format field and 2 form modes for content editing of that specific node type.
In one form mode, the field may be filled with content generated by editor buttons. In the other form mode, the same field may only be filled with text (much like a textarea field). This is mostly because the one form mode is used for users with more permissions, like using advanced editor functionality. The other form mode is used for users with less permissions and actually can not use the editor. So the field needs to be text format, but for some users the editor may not be used. So we had a text format that had no editor active (what was possible in CKEditor 4, but now with the upgrade to Drupal 10, it gave issues)

Wim Leers → credited tim@lammar.be → .

Patch contains deprecated getMasterRequest. Rewritten to getMainRequest.

reroll of #174 to be compliant with PHP8.2 (and D10)

This fixed the errors for me.

tim@lammar.be → created an issue.

I think it's just a typo, it should be $this->proxyMapping, which is defined.

Upgrade status module, gave me error on missing accessCheck() even though it was there.
I figured it should be relocated, and then after a new scan, the warning was gone.
Sharing patch here.

Fix: the accessCheck method is no longer executed by default on EntityQueries. Should be added on all queries.

Fix: the accessCheck method is no longer executed by default on EntityQueries. Should be added on all queries.

Correct placement of the accessCheck method.

tim@lammar.be → made their first commit to this issue’s fork.

This Patch did the trick for me, but probably room for improvement.

tim@lammar.be → created an issue.

Another issue I encountered, after updating to the latest version with the previous patch comitted, is the issue that entityQueries no longer have the accessCheck as a default beheviour and they must be called in every query before executing.
This patch did the trick for me.

also remove the core version

Simple patch.

Tim Lammar → created an issue.

Patch would not apply for me.
This one does in version 1.3

Fixed in latest version.

The patch that did the trick for me.

Tim Lammar → created an issue.