Hungary
Account created on 13 June 2008, about 16 years ago
  • Chief Technology Officer at PronovixΒ 
#

Merge Requests

More

Recent comments

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

This was the Slack thread: https://drupal.slack.com/archives/C392CHBEW/p1720016380610809

I also dumped it via Slackdump before it gets lost, see attachment.

Thanks for looping back to this thread, I'll also do that early next week.

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

mxr576 β†’ changed the visibility of the branch drupal-2951814 to active.

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

mxr576 β†’ changed the visibility of the branch 2951814-always-set-x-drupal-cache to hidden.

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

Indeed... :sadpanda: Rebasing again... PHPStorm could auto-resolve all :fingers-crossed:.

 git rebase origin/11.x
Auto-merging core/modules/basic_auth/tests/src/Functional/BasicAuthTest.php
Auto-merging core/modules/jsonapi/tests/src/Functional/NodeTest.php
CONFLICT (content): Merge conflict in core/modules/jsonapi/tests/src/Functional/NodeTest.php
Auto-merging core/modules/jsonapi/tests/src/Functional/ResourceTestBase.php
CONFLICT (content): Merge conflict in core/modules/jsonapi/tests/src/Functional/ResourceTestBase.php
Auto-merging core/modules/layout_builder/tests/src/Functional/LayoutSectionTest.php
Auto-merging core/modules/node/tests/src/Functional/NodeBlockFunctionalTest.php
Auto-merging core/modules/rest/tests/src/Functional/EntityResource/EntityResourceTestBase.php
error: could not apply d8f6085835... Applying https://www.drupal.org/files/issues/2021-02-24/2951814-85.patch
hint: Resolve all conflicts manually, mark them as resolved with
hint: "git add/rm <conflicted_files>", then run "git rebase --continue".
hint: You can instead skip this commit: run "git rebase --skip".
hint: To abort and get back to the state before "git rebase", run "git rebase --abort".
Could not apply d8f6085835... Applying https://www.drupal.org/files/issues/2021-02-24/2951814-85.patch

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

mxr576 β†’ changed the visibility of the branch 2951814-always-set-x-drupal-cache to active.

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

mxr576 β†’ changed the visibility of the branch drupal-2951814 to hidden.

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

Thanks @quietone for your work on this ticket! It makes perfect sense releasing this in 10.4.0 instead of a patch release for 10.3.x.

I added a release note snippet to the issue description, please review.

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

@naveenvalecha, review bot was right, Gitlab also complained about the merge issue, that tag should be used wisely.

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

The last second level blockers just got closed, let's make a comment and hope that flushes stale render cache ;P

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

Blocking issues have been fixed,

\o/

All green!

\o/

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

Reviewed the CR and both the MR. I could only nitpicking on consistency regarding whether we have , see [link]. or . See [link], but since PHPCS is happy, I can be happy with the current comments too, they are still readable and understandable.

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

Still mergable according to Gitlab.

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

Yep, 10.3.0 has the fix, so the suggested step is update from prior version or grab the fix from the referenced issue.

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

Now I think we have repro steps, I even have a draft fix for the problem with a todo.

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

\Drupal\Core\Routing\RouteProvider::getRouteCollectionCacheId() generates route:[language]=en:/user/password: as CID, notice that name query param is not included in the cid.

πŸ‡­πŸ‡ΊHungary mxr576 Hungary
\Symfony\Component\HttpKernel\EventListener\RouterListener::onKernelRequest()
\Drupal\Core\Routing\AccessAwareRouter::matchRequest()
\Drupal\Core\Routing\Router::matchRequest()
\Drupal\Core\Routing\Router::getInitialRouteCollection()
\Drupal\Core\Routing\RouteProvider::getRouteCollectionForRequest()
\Drupal\Core\Routing\RouteProvider::getRouteCollectionCacheId() # DOES NOT CONSIDER QUERY PARAMETERS WHEN GENERATES A CID.
\Drupal\Core\Routing\RouteProvider::getRouteCollectionForRequest() # modifies $request and overrides query parameters on, WHY??!?!

So this is how first a request to /user/password?name[%23post_render][0]=passthru can cause that a request to user/password afterwards also has a name query parameter...

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

$form['name']['#default_value'] = \Drupal::service('request_stack')->query->get('name');

yield a different result, it fails because there is no query... so my assumption that $this->requestStack gets serialized and stored and resurrected.

It also reveals another problem to me, the user.pass/code> route must deny access when the <code>name query parameter is missing, or handle it leniently.

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

Okay, this should be something else...

$form['name']['#default_value'] = $this->getRequest()->query->get('name'); fails in \Drupal\user\Form\UserPasswordForm::buildForm() after

/user/password?name[%23post_render][0]=passthru

was opened on /user/password because on that page the "current request" still contains the name query parameter and it is an array, which triggers the Input value "name" contains a non-scalar value. (\Symfony\Component\HttpFoundation\Exception\BadRequestException).

So how it could happen that a new request to /user/password still returns a query parameter from a previous request?

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

I also found this Symfony (non-Drupal!) HTTP exception in logs which could be related to the problem - in the past weeks I worked on caching issue and I remember seeing something related to how Symfony's own HTTP exceptions can cause problems with cacheability bubble up - like in this context they do no bubble up url.query_args cache context.

That is my hunch and I try to persuade that.

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

It seems to me that enough information was provided in the previous comment to continue the investigation.

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

I dared to open this issue last night because it seems to me the way type enforcement arrived to a minor release of the behat/* libraries weren't BC. I am surprised that nobody else reported this before and tried to convince maintainers to change their solution.

Why it is important? Because we would like to support 10.2.x and 10.3.x at the same time, but tests fails when the newer version of behat/mink is installed. It is good that this problem was mitigated in Drupal core, but contrib/custom space is still impacted. https://drupal.slack.com/archives/C223PR743/p1719331712444049

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

It occured to me that Greg's comment is 4 years old and maybe it is from those days when core-recommded did not allow patch version update of dependencies. In those days the concerns he raised regarding self.version was valid.

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

> The reason that we don't want to require drupal/core with self.version is that it makes upgrading harder.

In what way?

I was thinking about why Greg said this and what I saw in https://www.drupal.org/files/issues/2020-08-03/3163114-6.patch β†’ ... so do we really expect and reality also confirms that within the same Drupal minor versions, these meta packages could be on different versions at any time and everything should work? Because if not, the current solution with self.version in the MR is the only way to move forward, if not, then we get back to patch 6 and only lock on major.minor.

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

mxr576 β†’ made their first commit to this issue’s fork.

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

I am considering to open a Drupal core issue (over the weekend) for adding the Content-Language header to all emails sent by the mail manager...

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

https://github.com/composer/composer/discussions/12024

MailManagerInterface requires a langcode to be specified every time and the default MailManager implementation does add that to the $message payload: https://github.com/drupal/core/blob/10.3.0/lib/Drupal/Core/Mail/MailMana....

Also, it appears there is an official header for language, and it's Content-Language: https://www.rfc-editor.org/rfc/rfc4021.html#section-2.2.10. So, if we add something to the module, we should probably try to use that.

Good catch, thumbs up on that!

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

Tested current commit in MR and it works.

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

mxr576 β†’ changed the visibility of the branch 3042467-31-deprecated-alias-slug to hidden.

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

mxr576
Why a new patch was uploaded instead of contributing changes to the already open MR#6? It is one click requesting access and adding changes to it...

rokkun88 changed the visibility of the branch 3311063-add-support-for to hidden.

Well, I would have rather incorporated new changes to MR that makes code reviews and rebasing much easier then a patch... but maybe that is only my opinion.

πŸ‡­πŸ‡ΊHungary mxr576 Hungary
❯ git rebase origin/11.x
Auto-merging core/modules/jsonapi/tests/src/Functional/FileUploadTest.php
Auto-merging core/modules/jsonapi/tests/src/Functional/ResourceTestBase.php
Auto-merging core/modules/node/tests/src/Functional/NodeBlockFunctionalTest.php
Auto-merging core/modules/workspaces/tests/src/Functional/WorkspaceSwitcherTest.php
CONFLICT (content): Merge conflict in core/modules/workspaces/tests/src/Functional/WorkspaceSwitcherTest.php
Auto-merging core/profiles/standard/tests/src/FunctionalJavascript/StandardPerformanceTest.php
error: could not apply 0804e87ca2... Cherry-picked fix from https://git.drupalcode.org/project/drupal/-/merge_requests/8198
hint: Resolve all conflicts manually, mark them as resolved with
hint: "git add/rm <conflicted_files>", then run "git rebase --continue".
hint: You can instead skip this commit: run "git rebase --skip".
hint: To abort and get back to the state before "git rebase", run "git rebase --abort".
Could not apply 0804e87ca2... Cherry-picked fix from https://git.drupalcode.org/project/drupal/-/merge_requests/8198

Added void return defs to tests again... PHPStorm could easily resolve that.

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

\o/

Thanks for your collaboration @smustgrave!

πŸ‡­πŸ‡ΊHungary mxr576 Hungary
 git rebase origin/11.x
Auto-merging core/modules/block_content/tests/src/Functional/BlockContentListViewsTest.php
Auto-merging core/modules/views/tests/src/Kernel/Handler/FieldFieldTest.php
CONFLICT (content): Merge conflict in core/modules/views/tests/src/Kernel/Handler/FieldFieldTest.php
error: could not apply d0714b0f46... Fix failing test
hint: Resolve all conflicts manually, mark them as resolved with
hint: "git add/rm <conflicted_files>", then run "git rebase --continue".
hint: You can instead skip this commit: run "git rebase --skip".
hint: To abort and get back to the state before "git rebase", run "git rebase --abort".

Resolved conflicts caused by added void return type hints.

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

I tried different base fields, the UID or the Promoted field on the Article content type, but I could only reproduce the issue by changing the Moderation State field. Proof:

$ vendor/bin/drush cex --diff
 [notice] Differences of the active config to the export directory:
diff --git a/tmp/drush_tmp_1718824442_66732dfa7326c/core.base_field_override.node.article.moderation_state.yml b/tmp/drush_tmp_1718824442_66732dfa7326c/core.base_field_override.node.article.moderation_state.yml
new file mode 100644
index 00000000..8f89408d
--- /dev/null
+++ b/tmp/drush_tmp_1718824442_66732dfa7326c/core.base_field_override.node.article.moderation_state.yml
@@ -0,0 +1,18 @@
+uuid: 5689d78d-eb8f-4d3b-a1d2-361aff2b3504
+langcode: en
+status: true
+dependencies:
+  config:
+    - node.type.article
+id: node.article.moderation_state
+field_name: moderation_state
+entity_type: node
+bundle: article
+label: Foo
+description: 'The moderation state of this piece of content.'
+required: false
+translatable: true
+default_value: {  }
+default_value_callback: ''
+settings: {  }
+field_type: string


 The .yml files in your export directory (/mnt/files/local_mount/build/config/sync) will be deleted and replaced with the active config. (yes/no) [yes]:
 > 

 [success] Configuration successfully exported to /mnt/files/local_mount/build/config/sync.
/mnt/files/local_mount/build/config/sync

 $ vendor/bin/drush si -y --existing-config
 You are about to:
 * DROP all tables in your 'drupal' database.

 // Do you want to continue?: yes.                                                                                      

 [notice] Starting Drupal installation. This takes a while.
 [notice] Performed install task: install_select_language
 [notice] Performed install task: install_select_profile
 [notice] Performed install task: install_load_profile
 [notice] Performed install task: install_verify_requirements
 [notice] Performed install task: install_verify_database_ready
 [notice] Performed install task: install_base_system
 [notice] Performed install task: install_bootstrap_full
 [warning] Undefined array key "moderation_state" BaseFieldOverride.php:180
 [error]  Error: Call to a member function getFieldStorageDefinition() on null in Drupal\Core\Field\Entity\BaseFieldOverride->getFieldStorageDefinition() (line 120 of /mnt/files/local_mount/build/web/core/lib/Drupal/Core/Field/Entity/BaseFieldOverride.php) #0 /mnt/files/local_mount/build/web/core/lib/Drupal/Core/Field/FieldConfigBase.php(370): Drupal\Core\Field\Entity\BaseFieldOverride->getFieldStorageDefinition()
#1 /mnt/files/local_mount/build/web/core/lib/Drupal/Core/Field/FieldConfigBase.php(287): Drupal\Core\Field\FieldConfigBase->getSettings()
#2 /mnt/files/local_mount/build/web/core/lib/Drupal/Core/Config/Entity/ConfigEntityStorage.php(430): Drupal\Core\Field\FieldConfigBase->postCreate()
#3 /mnt/files/local_mount/build/web/core/lib/Drupal/Core/Config/Entity/ConfigEntityStorage.php(357): Drupal\Core\Config\Entity\ConfigEntityStorage->_doCreateFromStorageRecord()
#4 /mnt/files/local_mount/build/web/core/lib/Drupal/Core/Config/ConfigImporter.php(1059): Drupal\Core\Config\Entity\ConfigEntityStorage->importCreate()
#5 /mnt/files/local_mount/build/web/core/lib/Drupal/Core/Config/ConfigImporter.php(842): Drupal\Core\Config\ConfigImporter->importInvokeOwner()
#6 /mnt/files/local_mount/build/web/core/lib/Drupal/Core/Config/ConfigImporter.php(663): Drupal\Core\Config\ConfigImporter->processConfiguration()
#7 /mnt/files/local_mount/build/web/core/lib/Drupal/Core/Config/ConfigImporter.php(561): Drupal\Core\Config\ConfigImporter->processConfigurations()
#8 /mnt/files/local_mount/build/web/core/lib/Drupal/Core/Config/Importer/ConfigImporterBatch.php(31): Drupal\Core\Config\ConfigImporter->doSyncStep()
#9 /mnt/files/local_mount/build/web/core/includes/batch.inc(296): Drupal\Core\Config\Importer\ConfigImporterBatch::process()
#10 /mnt/files/local_mount/build/web/core/includes/form.inc(973): _batch_process()
#11 /mnt/files/local_mount/build/web/core/includes/install.core.inc(660): batch_process()
#12 /mnt/files/local_mount/build/web/core/includes/install.core.inc(578): install_run_task()
#13 /mnt/files/local_mount/build/web/core/includes/install.core.inc(121): install_run_tasks()
#14 /mnt/files/local_mount/build/vendor/drush/drush/includes/drush.inc(69): install_drupal()
#15 /mnt/files/local_mount/build/vendor/drush/drush/includes/drush.inc(53): drush_call_user_func_array()
#16 /mnt/files/local_mount/build/vendor/drush/drush/src/Commands/core/SiteInstallCommands.php(167): drush_op()
#17 [internal function]: Drush\Commands\core\SiteInstallCommands->install()
#18 /mnt/files/local_mount/build/vendor/consolidation/annotated-command/src/CommandProcessor.php(276): call_user_func_array()
#19 /mnt/files/local_mount/build/vendor/consolidation/annotated-command/src/CommandProcessor.php(212): Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback()
#20 /mnt/files/local_mount/build/vendor/consolidation/annotated-command/src/CommandProcessor.php(176): Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter()
#21 /mnt/files/local_mount/build/vendor/consolidation/annotated-command/src/AnnotatedCommand.php(391): Consolidation\AnnotatedCommand\CommandProcessor->process()
#22 /mnt/files/local_mount/build/vendor/symfony/console/Command/Command.php(326): Consolidation\AnnotatedCommand\AnnotatedCommand->execute()
#23 /mnt/files/local_mount/build/vendor/symfony/console/Application.php(1096): Symfony\Component\Console\Command\Command->run()
#24 /mnt/files/local_mount/build/vendor/symfony/console/Application.php(324): Symfony\Component\Console\Application->doRunCommand()
#25 /mnt/files/local_mount/build/vendor/symfony/console/Application.php(175): Symfony\Component\Console\Application->doRun()
#26 /mnt/files/local_mount/build/vendor/drush/drush/src/Runtime/Runtime.php(110): Symfony\Component\Console\Application->run()
#27 /mnt/files/local_mount/build/vendor/drush/drush/src/Runtime/Runtime.php(40): Drush\Runtime\Runtime->doRun()
#28 /mnt/files/local_mount/build/vendor/drush/drush/drush.php(139): Drush\Runtime\Runtime->run()
#29 /mnt/files/local_mount/build/vendor/drush/drush/drush(4): require('...')
#30 /mnt/files/local_mount/build/vendor/bin/drush(119): include('...')
#31 {main}. 

I also could not reproduce the problem by importing a base field override via config import to an existing side (as @ashetkar's report indicated that). Proof:

$ vendor/bin/drush cex --diff
 [notice] Differences of the active config to the export directory:
diff --git a/tmp/drush_tmp_1718825233_6673311143395/core.base_field_override.node.article.moderation_state.yml b/tmp/drush_tmp_1718825233_6673311143395/core.base_field_override.node.article.moderation_state.yml
new file mode 100644
index 00000000..cc25bbf8
--- /dev/null
+++ b/tmp/drush_tmp_1718825233_6673311143395/core.base_field_override.node.article.moderation_state.yml
@@ -0,0 +1,18 @@
+uuid: 9b164680-9812-452b-9b14-2507cc482d5f
+langcode: en
+status: true
+dependencies:
+  config:
+    - node.type.article
+id: node.article.moderation_state
+field_name: moderation_state
+entity_type: node
+bundle: article
+label: Foo
+description: 'The moderation state of this piece of content.'
+required: false
+translatable: true
+default_value: {  }
+default_value_callback: ''
+settings: {  }
+field_type: string


 The .yml files in your export directory (/mnt/files/local_mount/build/config/sync) will be deleted and replaced with the active config. (yes/no) [yes]:
 > 

 [success] Configuration successfully exported to /mnt/files/local_mount/build/config/sync.
/mnt/files/local_mount/build/config/sync

$ vendor/bin/drush cdel core.base_field_override.node.article.moderation_state

$ vendor/bin/drush cim --diff
diff --git a/tmp/drush_tmp_1718825254_66733126f2c77/core.base_field_override.node.article.moderation_state.yml b/tmp/drush_tmp_1718825254_66733126f2c77/core.base_field_override.node.article.moderation_state.yml
new file mode 100644
index 00000000..cc25bbf8
--- /dev/null
+++ b/tmp/drush_tmp_1718825254_66733126f2c77/core.base_field_override.node.article.moderation_state.yml
@@ -0,0 +1,18 @@
+uuid: 9b164680-9812-452b-9b14-2507cc482d5f
+langcode: en
+status: true
+dependencies:
+  config:
+    - node.type.article
+id: node.article.moderation_state
+field_name: moderation_state
+entity_type: node
+bundle: article
+label: Foo
+description: 'The moderation state of this piece of content.'
+required: false
+translatable: true
+default_value: {  }
+default_value_callback: ''
+settings: {  }
+field_type: string


 Import the listed configuration changes? (yes/no) [yes]:
 > 

 [notice] Synchronized configuration: create core.base_field_override.node.article.moderation_state.
 [notice] Finalizing configuration synchronization.
 [success] The configuration was imported successfully.

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

I guess the tag is outdated.

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

Could be simple though with before/after screenshots maybe of the altered results?

I think I maybe could... but the proposed change DOES NOT alter the original query alter anymore, just disables the query alter when a node access module is installed. So in this case, would it make sense capturing queries when it is clear how the behavior was changed?

I get your point on the CR, I'll create one.

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

I tried to put together repro steps by using a clean Drupal 10.2.7 install and with content moderation enabled, but I could not.

I did updated the issue description and I would have questions to @ashetkar:

  1. You wrote in the issue description: "I do config import I am getting issue for field core.base_field_override.node.content_type_name.promote as below " and later further clarified in comment 5. So based on those, am I correct that you see this failure NOT on a clean site install from existing config but when drush cim -y runs on an existing project?
  2. Are you sure that the issue was related to the promote base field and not moderation_state?
πŸ‡­πŸ‡ΊHungary mxr576 Hungary

Hiding patch because it is not a solution, just a hack.

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

It is more and more likely that the commited change breaks site install from existing config when Content Moderation is in use...

More details in #3441962-15: Call to a member function getSettings() on null in Drupal\Core\Field\FieldConfigBase->getSettings() β†’

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

Made this change and due to Monolog being active on the project since site install, I could capture this backtrace without spending hours on waiting for xDebug... not sure if it helps.

diff --git a/core/lib/Drupal/Core/Field/FieldConfigBase.php b/core/lib/Drupal/Core/Field/FieldConfigBase.php
--- a/core/lib/Drupal/Core/Field/FieldConfigBase.php	
+++ b/core/lib/Drupal/Core/Field/FieldConfigBase.php	
@@ -369,6 +369,11 @@
    * {@inheritdoc}
    */
   public function getSettings() {
+    if ($this->getFieldStorageDefinition() === NULL) {
+      $e = new \Exception();
+      \Drupal::logger(__CLASS__)->error('Fetching field storage definitions could not be fetched for "%name". Stack trace: <pre>%debug</pre>', ['%name' => $this->getName() , '%debug' => $e->getTraceAsString()]);
+      return $this->settings;
+    }
     return $this->settings + $this->getFieldStorageDefinition()->getSettings();
   }
 
[19-Jun-2024 08:19:33 UTC] [2024-06-19T08:19:33.215289+00:00] Drupal\Core\Field\FieldConfigBase.ERROR: Fetching field storage definitions failed for "moderation_state". Stack trace: <pre>#0 /mnt/files/local_mount/build/web/core/lib/Drupal/Core/Field/FieldConfigBase.php(287): Drupal\Core\Field\FieldConfigBase->getSettings() #1 /mnt/files/local_mount/build/web/core/lib/Drupal/Core/Config/Entity/ConfigEntityStorage.php(430): Drupal\Core\Field\FieldConfigBase->postCreate() #2 /mnt/files/local_mount/build/web/core/lib/Drupal/Core/Config/Entity/ConfigEntityStorage.php(357): Drupal\Core\Config\Entity\ConfigEntityStorage->_doCreateFromStorageRecord() #3 /mnt/files/local_mount/build/web/core/lib/Drupal/Core/Config/ConfigImporter.php(1059): Drupal\Core\Config\Entity\ConfigEntityStorage->importCreate() #4 /mnt/files/local_mount/build/web/core/lib/Drupal/Core/Config/ConfigImporter.php(842): Drupal\Core\Config\ConfigImporter->importInvokeOwner() #5 /mnt/files/local_mount/build/web/core/lib/Drupal/Core/Config/ConfigImporter.php(663): Drupal\Core\Config\ConfigImporter->processConfiguration() #6 /mnt/files/local_mount/build/web/core/lib/Drupal/Core/Config/ConfigImporter.php(561): Drupal\Core\Config\ConfigImporter->processConfigurations() #7 /mnt/files/local_mount/build/web/core/lib/Drupal/Core/Config/Importer/ConfigImporterBatch.php(31): Drupal\Core\Config\ConfigImporter->doSyncStep() #8 /mnt/files/local_mount/build/web/core/includes/batch.inc(296): Drupal\Core\Config\Importer\ConfigImporterBatch::process() #9 /mnt/files/local_mount/build/web/core/includes/form.inc(973): _batch_process() #10 /mnt/files/local_mount/build/web/core/includes/install.core.inc(660): batch_process() #11 /mnt/files/local_mount/build/web/core/includes/install.core.inc(578): install_run_task() #12 /mnt/files/local_mount/build/web/core/includes/install.core.inc(121): install_run_tasks() #13 /mnt/files/local_mount/build/vendor/drush/drush/includes/drush.inc(69): install_drupal() #14 /mnt/files/local_mount/build/vendor/drush/drush/includes/drush.inc(53): drush_call_user_func_array() #15 /mnt/files/local_mount/build/vendor/drush/drush/src/Commands/core/SiteInstallCommands.php(167): drush_op() #16 [internal function]: Drush\Commands\core\SiteInstallCommands->install() #17 /mnt/files/local_mount/build/vendor/consolidation/annotated-command/src/CommandProcessor.php(276): call_user_func_array() #18 /mnt/files/local_mount/build/vendor/consolidation/annotated-command/src/CommandProcessor.php(212): Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback() #19 /mnt/files/local_mount/build/vendor/consolidation/annotated-command/src/CommandProcessor.php(176): Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter() #20 /mnt/files/local_mount/build/vendor/consolidation/annotated-command/src/AnnotatedCommand.php(391): Consolidation\AnnotatedCommand\CommandProcessor->process() #21 /mnt/files/local_mount/build/vendor/symfony/console/Command/Command.php(326): Consolidation\AnnotatedCommand\AnnotatedCommand->execute() #22 /mnt/files/local_mount/build/vendor/symfony/console/Application.php(1096): Symfony\Component\Console\Command\Command->run() #23 /mnt/files/local_mount/build/vendor/symfony/console/Application.php(324): Symfony\Component\Console\Application->doRunCommand() #24 /mnt/files/local_mount/build/vendor/symfony/console/Application.php(175): Symfony\Component\Console\Application->doRun() #25 /mnt/files/local_mount/build/vendor/drush/drush/src/Runtime/Runtime.php(110): Symfony\Component\Console\Application->run() #26 /mnt/files/local_mount/build/vendor/drush/drush/src/Runtime/Runtime.php(40): Drush\Runtime\Runtime->doRun() #27 /mnt/files/local_mount/build/vendor/drush/drush/drush.php(139): Drush\Runtime\Runtime->run() #28 /mnt/files/local_mount/build/vendor/drush/drush/drush(4): require('...') #29 /mnt/files/local_mount/build/vendor/bin/drush(119): include('...') #30 {main}</pre> [] {"referer":"","ip":"127.0.0.1","request_uri":"http://default/","uid":0,"user":""}
πŸ‡­πŸ‡ΊHungary mxr576 Hungary

Those who are also suffering from this problem, do you also have Content Moderation module enabled on your projects?

I enabled debug logging and I see a bunch of complains related to the moderation_state field, and for that field only.

Unexpected error during import with operation create for core.base_field_override.node.[node_type].moderation_state: moderation_state []

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

The mentioned commit in #11 is with us since 10.2.0, We have also bumped a similar failure that was reported in this issue.
https://git.drupalcode.org/project/drupal/-/commit/e878713656faabf6d3afd...

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

I did some adjustments, do you still see any place for improvement?

I also wonder if this would need a CR or not... my current take is on NO.

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

Why a new patch was uploaded instead of contributing changes to the already open MR#6? It is one click requesting access and adding changes to it...

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

I did not have a project where I would suffer from the described problem, but based on the issue description and the attached test I think the described problem is addressed.
I had some nitpicks and also spin up a test-only branch just to confirm that the test fails.

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

If you could review the child for jsonapi that would be awesome,

JSONAPI tests... again... noooo :) on it

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

Let's start with a rebase.

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

Committed #155 to an issuefork so tests actually run on that code.

Made outdated patches hidden, MR#8155 contains the latest changes _always_.

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

Yey, another caching issue where we can collaborate @bbrala! ;)

I guess the patch is irrelevant anymore, the latest state in the MR.

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

Thanks for the review and the tentative RTBC. @bbrala.

I have synced with @kristiaanvandeneynde on Slack and described the current plan to get the blocker in sooner than later :) See: #2973356-32: Cacheability information from route access checker access results are ignored by dynamic_page_cache β†’ :fingers-crossed:

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

Synched with @kristiaanvandeneynde on Slack about the plan for getting this closed sooner than later, updated the issue description accordingly.

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

Meh... ofc simple rebase wasn't enough

Drupal\Tests\jsonapi\Functional\UserTest::testGetIndividual
Failed asserting that false is identical to true.

core/modules/jsonapi/tests/src/Functional/ResourceTestBase.php:1030

This should be also caused by the recently merged https://git.drupalcode.org/project/drupal/-/commit/9fc1bc9ac5a785ebf6e88......

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

Changes looks good to me, but since JSONAPI maintainers got summoned for review on Slack, I let them to RTBC this change.

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

Since the solution become more simpler, probably we do not need subsystem maintainer review anymore...

Also, let's try to move this back to node module's realm...

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

@smustgrave thanks for the review, I think your questions become irrelevant, since the fix took a complete different direction.

I realized that I did not see the bigger picture... and I realized why all related issues suggested "Disable SQL rewrite" as a "solution".

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

Okay, it took some time to realize that for sure, this works as designed.

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

Even after πŸ› AccessResult::orIf() has meaningless checks Fixed was closed, the reported issue still exists and the merge is decided by the same (refactored) line.

https://git.drupalcode.org/project/drupal/-/commit/1c814ad4277296875b9bd...

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

hm, this should have been in "needs review" for a while :)

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

Fixing this issue probably also resolves this one.

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

Restored empty-ish issue template.

πŸ‡­πŸ‡ΊHungary mxr576 Hungary

If you have a node_access implementation on your site, couldn't you just remove the status filter from the View and the correct nodes would be in your View? ie. The nodes that you have access to, independent of the status? Hmm probably only if you do something with (un)published in node_access I guess

Good idea, this simple one haven't came to my mind yet... but you are also right, unpublished ones would only appear if there is a node access module that grants access to them (at the query level). like view_unpublished contrib is enabled.

 * Node access grants apply regardless of the published or unpublished status
 * of the node. Implementations must make sure not to grant access to
 * unpublished nodes if they don't want to change the standard access control
 * behavior. Your module may need to create a separate access realm to handle
 * access to unpublished nodes.

https://github.com/drupal/core/blob/17708a8b8146cc3476a12bda9073376eb591...

My idea in ✨ Grant query level access to own unpublished nodes Active could be related, I do not know the historical reasons why Drupal core tried to leverage node access OOTB.

Also, this list: '***UNPUBLISHED_NIDS_ACCESS_GRANTED_BY_NODE_ACCESS***' can potentially get HUGE, at how many unpublished nodes will this fail? Depends on max_allowed_packet I guess, but it will fail at some point...

I also have this concern, I haven't found anything specific about the potential maximum length of parameters that would break this query... but again, better ideas are welcomed.

, they certainly aren't just what the description of that filter says.

I agree, the description should be changed, the purpose changes as well.

Thanks for raising these, they were valuable inputs.

Production build 0.69.0 2024