Using entityQuery in Cron, Update and Other Contexts
entityQuery is one of the most used functions in Drupal. It helps you easily pull Drupal entities in code. But when you use this in contexts other than controllers, say in cron-jobs or update hooks where the system is accessed as anonymous users, it may not work as expected in Drupal 9 unless you call accessCheck method explicitly.
Before Drupal 9.2, if we did not call the \Drupal\Core\Entity\Query\QueryInterface::accessCheck(), it behaves as if ::accessCheck(TRUE) is called. This caused many bugs related to permissions, and with the release of Drupal 9.2, Drupal core deprecated the use of entityQuery without explicitly calling ::accessCheck.
Now in Drupal 9.2 or above, calling entityQuery like the following will trigger a deprecation error.
//In Drupal 9.1 or below, this code get executed with accessCheck(TRUE). In Drupal 9.2 or above you will get a depercation error. In Drupal 10.x it will throw an exeption.
$nids = \Drupal::entityQuery('node')
->condition('type', 'article')
->execute();
The correct way of calling this is
//Get all nodes current user can access
$nids = \Drupal::entityQuery('node')
->accessCheck(TRUE)
->condition('type', 'article')
->execute();
or
//All nodes with out checking for access
$nids = \Drupal::entityQuery('node')
->accessCheck(FALSE)
->condition('type', 'article')
->execute();
Suppose you are using an older version of Drupal (9.1 or below); you will not see any warnings if you use entityQuery without accessCheck. The system will always assume that accessCheck is True, i.e. only people with the right access can get the content. So you may not get the expected result, if you use entityQuery in the context of cron or update_hooks. These functions often get called as accessed by "anonymous users".
In Drupal 10, you will not face this issue as the system will not allow you to use entityQuery without explicitly calling accessCheck method. It will throw an exception if you use entityQuery without an access check.
If you are using entityQuery in your code, the best practice now is to call accessCheck explicitly. This will make your code compatible with Drupal 10. Also, it will work as expected in Drupal 9.x.
Thanks, Adarsh M, for pointing this out in mattermost. You can read the full details and see the code changes in this changelog published on drupal.org
You are at a security risk if you use Drupal versions below 9.5. It is always recommended to move to Drupal 10.x, which has many new features. If any contributed modules prevent you from moving to Drupal 10, you have time till Nov 2023, but you should move to Drupal 9.5 immediately to mitigate the security risk.
Our Drupal migration services helped many organizations move from older versions of Drupal to the latest versions of Drupal and migrated from other content management systems (CMSs) like WordPress, Joomla, Sitecore, Djago etc. If you have a need or question related to Drupal migration, our team can help you. Don't hesitate to get in touch with us for support.