The code in commerce_file_menu() reads as follows:

/**
 * Implements hook_menu_alter().
 *
 * Provides a file download callback in case file_entity is missing.
 */
function commerce_file_menu_alter(&$items) {
  // Added via hook_menu_alter() in order to override the same path
  // when provided by file_download_count (since that version doesn't force
  // the file to be downloaded).
  if (!module_exists('file_entity')) {
    $items['file/%file/download'] = array(
      // ...
    );
  }
}

The problem is that the File Entity module doesn't actually define a file/%file/download URL, but Commerce File still provides a display formatter for file entities that links to this URL. This means it falls back to trying to show the file/%file page instead, which should be a 403 in most cases but has resulted in what I can only assume is a redirect loop on a site I'm working on manifested as a PHP memory limit error.

I'm thinking the solution isn't to link to file/%file/download when File Entity exists and instead to just link directly to the file URL. I fixed the site I was working on by changing the user Files tab to use the "Generic files" display formatter instead of "Commerce file". However, that doesn't work for the checkout pane, which is apparently not derived from Views at all, so I'm just going to disable the "License completion message" checkout pane and update the checkout completion message to point to the user account page instead.

Comments

bojanz’s picture

The problem is that the File Entity module doesn't actually define a file/%file/download UR

Sure it does. Check that the client is not using File Entity 1.x.
We are not compatible with the 1.x branch so we might need a specific hook_requirements() to forbid module installation in that case.

rszrama’s picture

Updating the issue from off-line discussion - this site was using File Entity 7.x-2.0-unstable7, which was still too early to have the download link. Looks like Commerce File actually requires File Entity 7.x-2.0-alpha3 (or an earlier alpha, but why would anyone use that?).

One thing this module could do instead is change the module_exists() check to a check for the actual menu item in question (since we're adding it in hook_menu_alter() anyways). If empty($items['file/%file/download']), then define it in Commerce File. No more compatibility problems. : )

bojanz’s picture

That suggestion makes sense, thanks Ryan.

bojanz’s picture

Actually, the comment explains why that can't work:

  // Added via hook_menu_alter() in order to override the same path
  // when provided by file_download_count (since that version doesn't force
  // the file to be downloaded).

Not sure whether to just add a media entity version requirement to the info file.

andyg5000’s picture

As a note for others that find this. Make sure you're not using media-7.x-1.x since this module has file_entity included, but not the right one.

PedroKTFC’s picture

I think this might be related to https://www.drupal.org/node/2302897. I have just wasted a day or so tracking this down. Is it possible to update the Commerce File documentation to point out that Commerce File 7.x-2.0-beta3 is not compatible with file_entity module 7.x-2.x-dev and you need to apply the patch in the link above to get them to work (in bold!)? It should save others from a fraught day or two!

(I'd have updated the documentation myself but I don't have access.)

nDigitHQ’s picture

Please delete this comment.

jsidigital’s picture

If this is related to files generating a "Page not found" error when trying to download commerce file (because file_entity is also installed), here is what helped me...

https://www.drupal.org/node/2300495