#Needs issue summary update

balintbrews → credited lauriii → .

Thanks for the write-up, @tedbow. We’re looking for a slightly different workflow. I collaborated on this answer with @lauriii.

Code components can exist in two states. These are:

1. They only exist under "Code" on the Library tab. Not available to be added to pages, nodes, or global regions. However, they can be used to construct other components (e.g. button component could be imported to a card)
2. They are moved under "Components" on the Library tab. Available to be added to pages, nodes, other components, or global regions. No representation under "Code" anymore, the code component only exists under "Components".

Auto-save workflow

1. Changes are auto-saved and not visible in the published site.
2. Preview inside Experience Builder (returned by the /api/preview endpoint) is generated with the auto-saved changes taken into account.
3. Publishing makes the auto-saved changes public, it is built into the existing publishing process implemented in ✨ [PP-1] Implement the "Publish All" button Postponed .

This means that changes autosaved to components that are listed under "Code" or "Components" may include changes that need to be rendered inside the preview, whilst not being published to the publicly available site.

I was just on call with @balintbrews and @lauri regarding auto-saving Code Component. I just wanted to get my understanding down in regard to the usage of auto-saved components, because this would intersect with out parts of XB.

This is my understanding at least for 🌱 Milestone 0.2.0: Experience Builder-rendered nodes Active

1. If a code component is only in an auto-save state and has never been published, it will not be available in the component list in the library of the XB ui. Meaning you can't place an code component on the page/node if it is only in auto-save
2. if a code component has been published, it will be available in the component list in the library of the XB ui, it can be placed
3. if a code component has been published but the editor is currently making changes that are in auto-save, the version available in the component list in the library of the XB ui that can be placed and the version for instances that are already placed, is the published version and is not affected by the auto-save state. This auto-saved version of Code Component also would not affect any instances on page/nodes/global regions that are already been "Published"(in the XB process of "publish all")
4. for an already published version of a Code Component, if the editor has an auto-saved version, once the auto-saved Code Component is published all versions in both pending XB page/nodes/global regions, and already published XB page/nodes/global regions would use the updated version. There would no option to use the previous version

Patch in #74 to MR: https://git.drupalcode.org/project/drupal/-/merge_requests/10925/diffs

I rerolled @aurora-norris' MR!10865 to 10.4.x.

Drupal CMS may finally push this forward :)

I can confirm that also the MR https://git.drupalcode.org/project/drupal/-/merge_requests/10896.diff solves the error regarding "Drupal\Core\Database\TransactionNameNonUniqueException" on group relationship migrations.

I have reviewed the issue and worked on a patch.

The patch fixes this by check if formatter is entity reference. While this solution works for the reported issue, I am unsure if it covers all edge cases. Feedback on this would be greatly appreciated.

Please review the patch and let me know if there are any improvements or alternative approaches you’d suggest

LGTM. All concerns addressed.

Came across this issue: https://www.drupal.org/project/drupal/issues/3167032 → , talking about -ms-high-contrast too.

Uploading the MR 118 diff as a patch for composer patching needs

I added before/after screenshots to the issue summary and created a draft CR.

We can just keep reducing the number of database queries required to serve a page, in issues like 📌 Entity lazy multiple front loading Active .

Here is a static patch for 10.3.x, based on MR 8334.

The webform submission issue can be solved by applying 🐛 Incorrect use of 'render element' for webform_submission_data Active on webform 6.2.x, or updating to 6.3.x.
Adding revision and language to the key like MR 4994 does would make sense I think.

@mradcliffe: Both merge requests have been rebased.

Issue summary still needs to be updated.

Thanks!

Can anyone please reroll the patch for the 10.4.1?

https://git.drupalcode.org/project/drupal/-/merge_requests/10859.diff solved this issue for me after installing entity_reference_integrity on Drupal 10.3.10.

https://git.drupalcode.org/project/drupal/-/merge_requests/10896.diff also worked!

ItemCacheTagsTest was removed with aggregator so title doesn't need it

Left a comment on MR.

Rerolled patch from #14

The merge request 10896 (#45) seems to be 1770 commits behind the target branch and needs a rebase. It's currently failing tests.

The issue is a little hard to follow and I think next if someone could address the Needs issue summary update tag that would be helpful to clarify proposed resolutions and remaining tasks.

In general, I like the approach discussed in #74. It might not solve all the problems, but it does solve a single problem and should help with some people's issues. Let's roll it into an MR and add tests.

Thanks a lot Elim (@elimw)! Great job!

We've just given a round of tests with the merge request you created MR!10896 and it fixed the issue as well for us 🥳
We've updated the patch in our project to use the one from #54.

@vistree:
Yes indeed, the patch created by Elim can be tested here:
https://git.drupalcode.org/project/drupal/-/merge_requests/10896.diff

It should fix the issue in your project as well.

It's a different (better) way of writing the same thing as the previous patch.

Thanks again for the work Elim and in advance for your feedback @vistree!

I have just run a security test and see that this is still an issue with the php folder within sites default files.
i.e. drwxrwxrwx 3 apache apache 18 Jan 4 10:47 php

Can someone summarise if this is something to worry about? Is there a fix without patching core?
Thanks

@elimw: is your MR a replacement or an addition for MR 10859 ?

@dydave, @vistree, I've created separate MR which checks if a savepoint with the same name already exists before pushing a transaction.

Think one of the last things needed will be a CR. Also before/after screenshots should be added to the summary for quick glance.

Hi, thanks for the patch, which I tried today.

It applies cleanly to Drupal (I would love to say which version but /admin/reports/status is timing out for me) but I see that it adds the message to the bottom of the form, instead of the top?

https://www.w3.org/WAI/WCAG22/Techniques/html/H90#example-2-using-an-ast... states...

It is important that the asterisk meaning is defined at the start of the form.

I just wondered if this was a deliberate decision or whether it's worth me creating a patch to put the message at the top of the form?

Best,

Chris

I thought we wanted to upgrade twig in 10.5.x, if that's not the case, no need for this backport

See https://www.drupal.org/about/core/policies/core-change-policies/how-to-d... →

@catch please answer

Maybe fixed instead since it was committed to 11.x?

Looks like it's not a blocker anymore, not clear why but that's great!

We're running PHP 8.4 testing on Drupal 10 so not sure how this is a hard blocker?

@nod Why do we need to port this to Drupal 10.5.x?

damienmckenna: Thank you

I created the new child issue #3498834 🐛 Dont use core's prepopulate function for core forms (Privacy) Active with issue description according to template.

I also created a new change record. The old change record → from this issue can be deleted.

I hope that this will speed up the process.

I set priority to normal because depecration is not as important as getting the core compliant with data protection laws.

jan kellermann → changed the visibility of the branch 2409107-11x-only-disable-for-core to hidden.

jan kellermann → closed merge request !10644

aurora-norris: FYI your comments weren't visible because your account wasn't approved and the automated security systems on the site don't let you post patches until your account is confirmed. I've confirmed your account and have published your two comments (though the second one is a dupe).

Opened an updated MR for this project but that has conflicts against 11.1 so heres a patch for that too (now using an OOP hook in the test).

Created a MR against 11.x but that won't apply properly to core 11.1.x so heres a patch that will work on that (tests are now using OOP hooks).

Have not reviewed but issue summary appears incomplete/incorrect, recommend using the standard issue template.
Also there are 3 MRs up if those can be cleaned up.

Thanks a lot @vistree for the feedback! Glad it's working for you 🥳

Hopefully we'll get more reviews, feedback and perhaps a better version of the patch (see #51/refactoring), but for now, hopefully, this version will allow all of us to keep moving forward on our projects!
Cheers!

@dydave -After upgrading to current Drupal core 10.4.1 patch from MR (https://git.drupalcode.org/project/drupal/-/merge_requests/10859.diff) applied and - what great news - solved the error on running my migration ;-)

So, I can confirm that the MR solves the error regarding "Drupal\Core\Database\TransactionNameNonUniqueException" on group relationship migrations.

Thanks Elim (@elimw), re #48:

Rather than having to explicitly check if we should wrap a query in a savepoint before calling "Connection::addSavepoint()", wouldn't it be better to do the check inside of "Connection::addSavepoint()" instead?

Sounds good! I'm not super familiar with the overall code of the pgsql module, but if you do a quick search around and see where the functions are used and if there would be any unexpected impacts, it would be great!

Could you perhaps create a new merge request with a different patch?
We would be able to give the patch a round of tests and see if it could be equivalent to the current MR!10859.

Thanks in advance!

Nice one @vistree!

I am still on Drupal 10.4 by the way!! Therefor patch https://git.drupalcode.org/project/drupal/-/merge_requests/10859.diff will not apply.

Just did the test with D10.4.1 and the patch applies very well.

Additionally, looking at your stack trace, see:
#3 /data/html/docroot/core/modules/pgsql/src/Driver/Database/pgsql/Upsert.php(35): Drupal\pgsql\Driver\Database\pgsql\Schema->queryTableInformation()

Same as pointed above at #45.

Therefore: The patch should apply and fix the issue for your project! \o/

Could you please do a quick round of test and report back?

Thanks in advance!

@dydave - I found a backtrace in Watchdog. Is this helpfull? I am still on Drupal 10.4 by the way!! Error appears when trying to migrate Group User Relations with drush migrate:

Drupal\Core\Database\TransactionNameNonUniqueException: A transaction named mimic_implicit_commit is already in use. Active stack: 677fb68df0dbc1.32969210\drupal_transaction > 677fb68df23611.91989256\mimic_implicit_commit in Drupal\Core\Database\Transaction\TransactionManagerBase->push() (Zeile 254 in /data/html/docroot/core/lib/Drupal/Core/Database/Transaction/TransactionManagerBase.php).

#0 /data/html/docroot/core/modules/pgsql/src/Driver/Database/pgsql/Connection.php(558): Drupal\Core\Database\Transaction\TransactionManagerBase->push()
#1 /data/html/docroot/core/modules/pgsql/src/Driver/Database/pgsql/Connection.php(431): Drupal\pgsql\Driver\Database\pgsql\Connection->startTransaction()
#2 /data/html/docroot/core/modules/pgsql/src/Driver/Database/pgsql/Schema.php(149): Drupal\pgsql\Driver\Database\pgsql\Connection->addSavepoint()
#3 /data/html/docroot/core/modules/pgsql/src/Driver/Database/pgsql/Upsert.php(35): Drupal\pgsql\Driver\Database\pgsql\Schema->queryTableInformation()
#4 /data/html/docroot/core/lib/Drupal/Core/Cache/DatabaseBackend.php(312): Drupal\pgsql\Driver\Database\pgsql\Upsert->execute()
#5 /data/html/docroot/core/lib/Drupal/Core/Cache/DatabaseBackend.php(227): Drupal\Core\Cache\DatabaseBackend->doSetMultiple()
#6 /data/html/docroot/core/lib/Drupal/Core/Cache/DatabaseBackend.php(215): Drupal\Core\Cache\DatabaseBackend->setMultiple()
#7 /data/html/docroot/core/lib/Drupal/Core/Cache/VariationCache.php(176): Drupal\Core\Cache\DatabaseBackend->set()
#8 /data/html/docroot/modules/contrib/flexible_permissions/src/ChainPermissionCalculator.php(172): Drupal\Core\Cache\VariationCache->set()
#9 /data/html/docroot/modules/contrib/group/src/Access/GroupPermissionCalculator.php(39): Drupal\flexible_permissions\ChainPermissionCalculator->calculatePermissions()
#10 /data/html/docroot/modules/contrib/group/src/QueryAccess/GroupQueryAlter.php(40): Drupal\group\Access\GroupPermissionCalculator->calculateFullPermissions()
#11 /data/html/docroot/modules/contrib/group/src/QueryAccess/QueryAlterBase.php(143): Drupal\group\QueryAccess\GroupQueryAlter->doAlter()
#12 /data/html/docroot/modules/contrib/group/group.module(333): Drupal\group\QueryAccess\QueryAlterBase->alter()
#13 /data/html/docroot/core/lib/Drupal/Core/Extension/ModuleHandler.php(552): group_query_entity_query_alter()
#14 /data/html/docroot/core/lib/Drupal/Core/Database/Query/Select.php(494): Drupal\Core\Extension\ModuleHandler->alter()
#15 /data/html/docroot/core/lib/Drupal/Core/Database/Query/Select.php(519): Drupal\Core\Database\Query\Select->preExecute()
#16 /data/html/docroot/core/modules/pgsql/src/Driver/Database/pgsql/Select.php(157): Drupal\Core\Database\Query\Select->execute()
#17 /data/html/docroot/core/lib/Drupal/Core/Entity/Query/Sql/Query.php(272): Drupal\pgsql\Driver\Database\pgsql\Select->execute()
#18 /data/html/docroot/core/lib/Drupal/Core/Entity/Query/Sql/Query.php(85): Drupal\Core\Entity\Query\Sql\Query->result()
#19 /data/html/docroot/core/lib/Drupal/Core/Entity/Plugin/EntityReferenceSelection/DefaultSelection.php(401): Drupal\Core\Entity\Query\Sql\Query->execute()
#20 /data/html/docroot/core/lib/Drupal/Core/Entity/Plugin/Validation/Constraint/ValidReferenceConstraintValidator.php(133): Drupal\Core\Entity\Plugin\EntityReferenceSelection\DefaultSelection->validateReferenceableEntities()
#21 /data/html/docroot/core/lib/Drupal/Core/TypedData/Validation/RecursiveContextualValidator.php(202): Drupal\Core\Entity\Plugin\Validation\Constraint\ValidReferenceConstraintValidator->validate()
#22 /data/html/docroot/core/lib/Drupal/Core/TypedData/Validation/RecursiveContextualValidator.php(154): Drupal\Core\TypedData\Validation\RecursiveContextualValidator->validateConstraints()
#23 /data/html/docroot/core/lib/Drupal/Core/TypedData/Validation/RecursiveContextualValidator.php(164): Drupal\Core\TypedData\Validation\RecursiveContextualValidator->validateNode()
#24 /data/html/docroot/core/lib/Drupal/Core/TypedData/Validation/RecursiveContextualValidator.php(106): Drupal\Core\TypedData\Validation\RecursiveContextualValidator->validateNode()
#25 /data/html/docroot/core/lib/Drupal/Core/TypedData/Validation/RecursiveValidator.php(93): Drupal\Core\TypedData\Validation\RecursiveContextualValidator->validate()
#26 /data/html/docroot/core/lib/Drupal/Core/TypedData/TypedData.php(132): Drupal\Core\TypedData\Validation\RecursiveValidator->validate()
#27 /data/html/docroot/core/lib/Drupal/Core/Entity/ContentEntityBase.php(518): Drupal\Core\TypedData\TypedData->validate()
#28 /data/html/docroot/modules/contrib/group/src/Entity/GroupMembershipTrait.php(25): Drupal\Core\Entity\ContentEntityBase->validate()
#29 /data/html/docroot/core/lib/Drupal/Core/Entity/EntityStorageBase.php(528): Drupal\group\Entity\GroupMembership->preSave()
#30 /data/html/docroot/core/lib/Drupal/Core/Entity/ContentEntityStorageBase.php(753): Drupal\Core\Entity\EntityStorageBase->doPreSave()
#31 /data/html/docroot/core/lib/Drupal/Core/Entity/EntityStorageBase.php(483): Drupal\Core\Entity\ContentEntityStorageBase->doPreSave()
#32 /data/html/docroot/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php(806): Drupal\Core\Entity\EntityStorageBase->save()
#33 /data/html/docroot/core/lib/Drupal/Core/Entity/EntityBase.php(354): Drupal\Core\Entity\Sql\SqlContentEntityStorage->save()
#34 /data/html/docroot/core/modules/migrate/src/Plugin/migrate/destination/EntityContentBase.php(237): Drupal\Core\Entity\EntityBase->save()
#35 /data/html/docroot/core/modules/migrate/src/Plugin/migrate/destination/EntityContentBase.php(175): Drupal\migrate\Plugin\migrate\destination\EntityContentBase->save()
#36 /data/html/docroot/core/modules/migrate/src/MigrateExecutable.php(248): Drupal\migrate\Plugin\migrate\destination\EntityContentBase->import()
#37 /data/html/vendor/drush/drush/includes/drush.inc(62): Drupal\migrate\MigrateExecutable->import()
#38 /data/html/vendor/drush/drush/includes/drush.inc(53): drush_call_user_func_array()
#39 /data/html/docroot/modules/contrib/migrate_tools/src/Drush/Commands/MigrateToolsCommands.php(1074): drush_op()
#40 /data/html/docroot/modules/contrib/migrate_tools/src/Drush/Commands/MigrateToolsCommands.php(483): Drupal\migrate_tools\Drush\Commands\MigrateToolsCommands->executeMigration()
#41 [internal function]: Drupal\migrate_tools\Drush\Commands\MigrateToolsCommands->import()
#42 /data/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(276): call_user_func_array()
#43 /data/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(212): Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback()
#44 /data/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(176): Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter()
#45 /data/html/vendor/consolidation/annotated-command/src/AnnotatedCommand.php(391): Consolidation\AnnotatedCommand\CommandProcessor->process()
#46 /data/html/vendor/symfony/console/Command/Command.php(326): Consolidation\AnnotatedCommand\AnnotatedCommand->execute()
#47 /data/html/vendor/symfony/console/Application.php(1096): Symfony\Component\Console\Command\Command->run()
#48 /data/html/vendor/symfony/console/Application.php(324): Symfony\Component\Console\Application->doRunCommand()
#49 /data/html/vendor/symfony/console/Application.php(175): Symfony\Component\Console\Application->doRun()
#50 /data/html/vendor/drush/drush/src/Runtime/Runtime.php(110): Symfony\Component\Console\Application->run()
#51 /data/html/vendor/drush/drush/src/Runtime/Runtime.php(40): Drush\Runtime\Runtime->doRun()
#52 /data/html/vendor/drush/drush/drush.php(139): Drush\Runtime\Runtime->run()
#53 /data/html/vendor/drush/drush/drush(4): require('/data/html/docr...')
#54 /data/html/vendor/bin/drush(119): include('/data/html/docr...')
#55 {main}

Back to green, would be good to get another review on this

Drupal 10.4.1 adapted patch.

I have pushed a change to fix the issue I was encountering.

Rather than having to explicitly check if we should wrap a query in a savepoint before calling "Connection::addSavepoint()", wouldn't it be better to do the check inside of "Connection::addSavepoint()" instead?

Drupal 7 reached EOL