I use this module on a site that is using commerce license (https://www.drupal.org/project/commerce_license) and its dependency module advanced queue (https://www.drupal.org/project/advancedqueue)

The story is: When a license entity passes its expiration date, a queue job is created that will set the license status as expired. On the next cron run the license has to be updated. On commerce_license.module the function commerce_license_expiration_queue_process
is loading a license:

  $license = entity_load_single('commerce_license', $data['license_id']);
  if ($license) {
    $license->expire();
  }

Unfortunately, entity_load_single returns FALSE.

The problem lies on domain_entity.module @ line 131: function domain_entity_query_alter(&$query)
This is used to alter the query and add additional access rules, based on the domain.

The function domain_entity_get_user_available_domains is used to "Return a list of domain id's, accessible by the current user"
But cron runs as anonymous user, and probably on the default domain, which means that the access is restricted.

I am not sure if this could be considered as a bug, or that it works as designed. And also, I am wondering if domain_entity module should be blamed for this. It is clear that the questionable bug is caused by this function. But is it supposed to be that way?

Would it be against the module's logic, to add an additional check on the beginning of function domain_entity_query_alter, so that if the function is called during a cron run, no extra domain-related checks will be triggered and no domain-restrictions will be applied.

Please note that I tried to run cron manually, through drush, by appending the --uri argument, but it still did not work expire the license.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

efpapado created an issue. See original summary.

efpapado’s picture

I propose a patch.
This is the best workaround I could think of: bypassing the query alteration during cron-runs.

efpapado’s picture

Status: Active » Needs review
efpapado’s picture

Title: Problem with commerce licenses expiration during cron runs » Cron is unable to load entities
delta’s picture

Status: Needs review » Needs work

mmmmh think of it, taking a large breath ... expire..

Maybe we should do it, and add a general settings for this, to not break the existing sites workflow.

- Add a variable domain_entity_cron_bypass (default to false)
- expose it in the UI (or not)
- Add a check, before bypassing for cli

efpapado’s picture

Attached :)

efpapado’s picture

FileSize
3 KB

Again, fix typo

efpapado’s picture

Status: Needs work » Needs review
mvwensen’s picture

Status: Needs review » Reviewed & tested by the community

Great patch!

This patch works perfect for my use case:
A scheduled node with a file field using the Scheduler module (on cron) on an Domain Access site. When a node was scheduled the file reference would disappear after the cron publish action.

The code looks also good to me. (patch #7)

super_romeo’s picture

Dear efpapado, thank you for patch!

But I suggest replace

php_sapi_name() == 'cli'

with

(drupal_is_cli() || strpos($_SERVER['PHP_SELF'], 'cron.php') !== FALSE) 

because:

  • some peoples launch cron via cron.php (not via cli),
  • we could detect using Ultimate Cron via $_SERVER['PHP_SELF'] == 'cron.php'.
mvdve’s picture

Status: Reviewed & tested by the community » Needs review
FileSize
502 bytes

The domain module already has a special request setting for cron.php. The only issue is that this status is ignored by the domain_entity module. Attached a patch with a fix. The issue that the cli has no access will still be there. This needs to be fixed within the domain_grant_all() function or you could implement hook_domain_grand_all_alter() and do something like this:

if (drupal_is_cli() && function_exists('drush_main')  && strpos(reset(drush_get_arguments()), 'cron') !== FALSE) {
        $grant = true;
    }