Errors with version 2.36

These errors are mostly coming from update hooks which would be a problem when migrating straight from Drupal 8 to Drupal 10 but the recommendation is not to do that.

Drupal 10 has no replacement for drupal_install_schema(), we can fix the queries easily though.

Created a patch for entityQuery errors. Please review,

The access check should be FALSE since the update is executed by the anonymous user... Also, why are you updating the ConfigurableFieldManager, there's already an access check there?

So @jsacksick are you saying \Drupal\Core\Extension\ModuleInstaller::installSchema() will no longer work and ALL AccessChecks should be FALSE ?? (there is 30 more)

ModuleInstaller::installSchema() is protected? See https://www.drupal.org/node/2970993 → .

Also, regarding:

Parameter $checker of method Drupal\commerce_order\AvailabilityManager::addLegacyChecker() has typehint with deprecated interface Drupal\commerce\AvailabilityCheckerInterface. Deprecated in commerce:8.x-2.18 and is removed from commerce:3.x. Use Drupal\commerce_order\AvailabilityCheckerInterface instead

There are 4 of these

breaks the site and prevents any update to the database - aka "drush updb" - when I try to fix it - perhaps I am doing it wrong

How is that breaking the site? That isn't supposed to? This is just a deprecation warning... I'm running several sites on D10 without issues.

Pushed some fixes, some of the warnings aren't legit, some of the queries had access checks already, so the report might be incorrect, marking this as "fixed" for now.

I pushed the new dev version and it took me from 10 errors - actually 8 because two were notices to 31, so I put my 2.36 I patched back on

Here are the errors as jpg files from Upgrade Status

named 1a, 2a and 3a

31 errors? I'll maybe just install upgrade status to check for myself, don't really understand how this is possible... But besides these warnings reported, nobody ever reported any of these as "blocking" issues.
For example, even the drupal_install_schema() isn't supposed to be a problem as people are recommended to upgrade from 8 to 9 and then 9 to 10, not straight from Drupal 8 to Drupal 10.

I'm not sure how the number of errors could have increased. Also, once again, the availability manager reports aren't really "valid" IMO.

The access check should be FALSE since the update is executed by the anonymous user...

AFAIK, any time that accessCheck(FALSE) is introduced to an entity query which did not previously have an accessCheck, you are changing the behaviour of that code. Are these behavioural changes on purpose? (Was the original code wrong?)

In the past, access was checked by default, equivalent to accessCheck(TRUE), so if the intention is to update the old code without changing what it does, accessCheck(TRUE) is appropriate.

The change record is: https://www.drupal.org/node/3201242 →

Not sure why this is being reopened...

AFAIK, any time that accessCheck(FALSE) is introduced to an entity query which did not previously have an accessCheck, you are changing the behaviour of that code. Are these behavioural changes on purpose? (Was the original code wrong?)

Yes, the code was wrong. Updating content entities from post update functions shouldn't take into account access as the updates will be executed by the anonymous user.

Automatically closed - issue fixed for 2 weeks with no activity.