No download link for some products

[ghost]

Hello,

I am running latest version of WooCommerce on Nginx server with MariaDB database and I have issue with download link for some products. My Payment gateway is CryptoWoo with Bitcoins.

All products in my shop are set as Virtual and Downloadable. Download expiry is set to 15 days. Enable this to only allow one of this item to be bought in a single order is enabled. All files are zip, uploaded to the same server and all are active and available to download.

Wordpress Permalink are set as http://mysite.com/sample-post/
Product Permalink are set to default http://mysite.com/product/sample-product/

In downloadable section I have enebaled Grant access to downloadable products after payment

Some of products are visible after order and some of them no. When odder is complete customers get email with all info and link. Some products have this link and some of them no. There is only table with headers.

Also in /my-account/downloads/ section there is no link to ordered file.
No downloads available yet.

So for these orders I am sending file manually by email :(

Weird is that this is random. Some of customers bought same file and one of them have access to it and second one no. Some of customers bought for example two files and have link to only one.

When I am going to the order details Downloadable product permissions field is empty
I hit Order Actions -> Regenerate Download Permission but this doesn't fix it.
I tried to Grant Access to file manually but then I have error like: Could not grant access - the user may already have permission for this file or billing email is not set. Ensure the billing email is set, and the order has been saved.

I have no idea how to fix this. I compared accounts and products settings but everything looks the same.

My environment settings.
env.txt

[mikejolley]

Hi,

I can see in the env.txt there are a few plugins relating to orders/downloads which could be affecting this, since you said the regenerate button was also failing.

• License-Manager: by Isaac Oyelowo
• My Custom Functions (not sure what you have setup!)

It doesn't sound like you've ruled these out yet? My thinking is something (such as those extensions) is err'ing when downloads are regenerated and thus blocking their creation.

WC > System Status > Logs, specifically fatal error log, may give clues.

Other than that, have you seen if removing the download expiry helps at all?

Have you checked the wp_woocommerce_downloadable_product_permissions table to see if records exist for the users/orders with missing download links?

These are a few things you should investigate to identify the problem.

On a clean install I'm not having problems with download regeneration so I'm not able to replicate this issue or confirm there is a problem within WooCommerce itself. I'd encourage you to check the points listed above and get back to us if you find anything odd, or contact the helpdesk if you need help from someone and want to share logins.

https://woocommerce.com/contact-us/

Thanks

[ghost]

Thank you for your answer.

So I checked everything you mentioned. I turned off all extensions, I deleted limits for download and tried to regenerate but nothing happened.

I checked wp_woocommerce_downloadable_product_permissions table and unfortunately there is no record for these orders so this is probably the issue, records don't exist for orders with error. Is the Regenerate button should fix that missing entry in database table or it can just fix permission once table entry is generated properly?

[mikejolley]

The regenerate button should loop over all items in the order add add records into wp_woocommerce_downloadable_product_permissions, unless the download is misconfigured or an extension/code is blocking it from doing so.

[ghost]

Damn, I disabled all plugins and re-uploaded file and made order again with the same result. I made order for other files and link is ok. Mystery. No errors in logs :( I updated permission for files on server and added all rights to the database user. I will get back to this tomorrow. Anyway, thanks for your help. If you will get any idea what I can check or do let me know. If in the future I will find "my bug" I will update this thread for other people. Thanks!

[ghost]

One question before I go to bed and think all night what the hell I did wrong :)
How it looks from backend? When I hit regenerate button what process looks like? This is some sql query or curl query. Can I try to regenerate it manually on server side and not on Wordpress.

[mikejolley]

It just runs a function in the backend then displays a notice saying it was done. Rows would appear in the DB table if it worked.

[mateusz-michalik]

Hi guys, I'm getting the same issue on a multi-site install.

Similar to @AprilONeil, we've disabled all other plugins except for WooCommerce, we are on the latest WooCommerce (3.3.5) and have also reverted to the default theme. The rows into the woocommerce_downloadable_product_permissions are just never written and so the download links do not appear in the email notification or the my-account view order page.

Clicking 'Regenerate download permissions' simply refreshes the edit order page and says 'order updated', but the woocommerce_downloadable_product_permissions is still empty.

Using the 'Downloadable Product Permissions' controls and clicking 'Grant Access' after selecting an appropriate product yields a 'Could not grant access - the user may already have permission for this file or billing email is not set. Ensure the billing email is set, and the order has been saved' error.

Checked logs on local and on Pressidium (where this site is hosted) nothing at the time the above actions take place. I have a feeling this has something to do with multi-site table names though.

Problem exists on production and local environments, I'll have the other dev copy in the exact details of the setup if you need.

[ghost]

Uhh. I am still trying to find where the issue is. I checked file permission on server. I tried to upload new one to the different folder and there is access to the files but still nothing. Most annoying is that this doesn't work randomly. The size of file and upload date is also random. No database errors in logs, same for nginx, php fpm log. Still no luck in my investigation.

[peterStoj]

Hi Guys,

After a deep investigation of this issue, we've come to the conclusion the problem is caused when the filename of the Downloadable file(s) is rather big.

For example, I have added those two files as a test (http://prntscr.com/j9f57u) and I can see them normally in my account's order as well as on the administrative side of the order (https://prnt.sc/ja9bm7). However, once the filename is larger it fails not showing in my accounts, on the administrative side of the order or on the email notifications.

With some testing (Trial & Error) we've found that any filename over 40 characters including the file extension will fail.

Hope this help you @AprilONeil

[mateusz-michalik]

Nice one @peterStoj!

@mikejolley so you're aware, this issue did not appear in the error logs on local or prod environments, and it was Pressidium who had to dive into this a bit deeper on their side to discover the issue.

Essentially what happens is the long filename seems to stop an entry being written to the woocommerce_downloadable_product_permissions table

[mikejolley]

@mateusz-michalik Do you know which column? We don't write filename to that table.

[ghost]

Thanks guys for your investigation but this is not my issue :( I have really short filenames between 10 to 15 characters. Some file names with longer name are downloading and with shorter no.
But when I was checking links and filenames in my product pages I found one interesting rule. I was adding products partially and most of products was added in 2017 October and these are ok and second part was about 2018 February and March and orders with these files are the one with missing link and not regenerate.

so everything which was uploaded to for example to
/woocommerce_uploads/2017/10/test_file1.zip
is ok
and uploaded to
/woocommerce_uploads/2018/02/test_file2.zip

So I did some test with files.

For some test I edited old good product and added there newly uploaded file but still nothing. Only old was available.

My next step was to create new product with one old working file and second one which was not working. No link in email or order page for both.

So I created new product with old file (just a copy of one that already exist and was ok, and you know what? It also doesn't work. So I have two different products with same file and only one works good. The one which was created before Januray 2018. Since that time when I add new product no matter which file, the order is broken. So my issue is that when I am creating new product something is going wrong.

I disabled all plugins and created new product again with file from correct old product and have same issue.

[mateusz-michalik]

@peterStoj might be able to give more detail @mikejolley - he spoke with Pressidium on the matter and got it resolved.

[sjspaulding]

I see this is closed, but what was the resolution? Experiencing the same issue on my site.

[jawinn]

@mikejolley Should this be reopened, since the original author's issue has not been fixed or a solution offered, and others are still experiencing this?

Details on the same issue we're seeing. I'm going to look and see if I can find an entry in the permissions table for one that is broke:

---

We have seen a few orders where a customer purchased a downloadable product but
was not granted download permission, but when you go in and try to grant permission, it does not allow you to, throwing an error alert:

"Could not grant access - the user may already have permission for this file
or billing email is not set. Ensure the billing email is set, and the order has been saved".

(FYI the billing email is set).

So far this has happened at least twice, and we have to end up sending them the link via email.

[marwankhanfar]

I managed to solve this issue by increasing length of download_id column under table ls_woocommerce_downloadable_product_permissions from 32 to 100 characters because somes download ids are more than 32 characters

[pavelhuerta]

I have the same issue!... marwankhanfar give a good solution and works for new orders!... But I'm not able to grant access to completed or pending orders. Also creating a new order manually I'm not able to grant access to products. Seems nothing mentioned here works!...

[mikejolley]

@marwankhanfar and others, perhaps the DB update routine failed for some reason (permissions?) because that column should be 36 length:

download_id varchar(36) NOT NULL,

[ghost]

@marwankhanfar YAY! It works! Man you saved my life. I can add new products and they works fine.
Also I hit "Regenerate download permission" button for some old broken order and it is also works!

Thank you Sir!

PS. I just checked this on one new product and one already exist product. I will test it tomorrow on the rest.

[SS88UK]

@mikejolley I also have the same issue.

I attempted to manually add it and received the error pop-up:

"Could not grant access - the user may already have permission for this file
or billing email is not set. Ensure the billing email is set, and the order has been saved".

After changing download_id to 100 characters and repeating my step above to manually re-add a file, it worked. WooCommerce 3.3.5.

[jawinn]

Findings
The download_id is now storing the file name, rather than a hashed ID, causing download permissions to not be inserted into the ag_woocommerce_downloadable_product_permissions table when the stored file name is longer than 36 characters.

The length of the varchar field needs to be increased, or maybe this shouldn't be storing the filename.

Details
Our current download_id field is 36 characters:

mysql> DESCRIBE ag_woocommerce_downloadable_product_permissions;
+---------------------+---------------------+------+-----+---------------------+----------------+
| Field               | Type                | Null | Key | Default             | Extra          |
+---------------------+---------------------+------+-----+---------------------+----------------+
| permission_id       | bigint(20) unsigned | NO   | PRI | NULL                | auto_increment |
| download_id         | varchar(36)         | NO   | MUL | NULL                |                |
| product_id          | bigint(20) unsigned | NO   | MUL | NULL                |                |
| order_id            | bigint(20) unsigned | NO   | MUL | 0                   |                |
| order_key           | varchar(200)        | NO   |     | NULL                |                |
| user_email          | varchar(200)        | NO   |     | NULL                |                |
| user_id             | bigint(20) unsigned | YES  |     | NULL                |                |
| downloads_remaining | varchar(9)          | YES  |     | NULL                |                |
| access_granted      | datetime            | NO   |     | 0000-00-00 00:00:00 |                |
| access_expires      | datetime            | YES  |     | NULL                |                |
| download_count      | bigint(20) unsigned | NO   |     | 0                   |                |
+---------------------+---------------------+------+-----+---------------------+----------------+

I found no entries in the permissions table when selecting by order ID or product ID of one of the broken orders (giving the alert error when attempting to grant permission). Selecting by the user email does show permissions for other orders.

The broken order w/ downloadable product that I'm looking for has
order_id = 84625
product_id = 83861
variation ID = 83863

SELECT * FROM ag_woocommerce_downloadable_product_permissions WHERE product_id = 83861;
Empty set (0.00 sec)

SELECT * FROM ag_woocommerce_downloadable_product_permissions WHERE product_id = 83863;
Empty set (0.00 sec)

mysql> mysql> SELECT * FROM ag_woocommerce_downloadable_product_permissions WHERE order_id = 84625;
Empty set (0.00 sec)

So the error being received does not make sense, if there is no existing permission and the billing email is set. In addition to fixing the underlying issue, perhaps some error handling and better error message is needed to relay that an issue was encountered when attempting to store the permission.

Looking at the permissions table for this user, it's very strange that the newer downloads are now using the file name, instead of the a hashed download ID.

The change happened at the time we upgraded from 4.9.1 to 4.9.4, and WooCommerce from version 3.0.7 to 3.3.3. At this time we also updated all plugins and made template updates to clear up all warnings and errors from the major update in WooCommerce version.

Is this how it should be saved currently in WooCommerce? Could a plugin be interfering with that? This explains why those earlier in the thread were having issues with long file names. If the file name is longer than the 36 chars, it won't save the permission.

mysql> SELECT * FROM ag_woocommerce_downloadable_product_permissions WHERE user_email = 'REDACTED';
+---------------+-------------------------------------+------------+----------+------------------------+-----------------------------+---------+---------------------+---------------------+----------------+----------------+
| permission_id | download_id                         | product_id | order_id | order_key              | user_email                  | user_id | downloads_remaining | access_granted      | access_expires | download_count |
+---------------+-------------------------------------+------------+----------+------------------------+-----------------------------+---------+---------------------+---------------------+----------------+----------------+
|         19440 | 8b606654a8ee790ebc9841d22c822246    |      31353 |    31358 | wc_order_58fa768ef2f16 | REDACTED                    |       3 |                     | 2017-04-21 00:00:00 | NULL           |              0 |
|         19441 | 8b606654a8ee790ebc9841d22c822246    |      31353 |    31360 | wc_order_58fa771c18e78 | REDACTED                    |       3 |                     | 2017-04-21 00:00:00 | NULL           |              0 |
|         70718 | aac910329ea0efe23a2e97f23303a6ad    |      72286 |    72567 | wc_order_5a6f3e5109bfa | REDACTED                    |       3 | 4                   | 2018-01-29 00:00:00 | NULL           |              1 |
|         73302 | 8d007165d1950b47ea3c0f89c1832d30    |      71746 |    75039 | wc_order_5a8c8af2764ce | REDACTED                    |       3 | 5                   | 2018-02-20 00:00:00 | NULL           |              0 |
|         73303 | 10aaf85360e7b4295d2a65f3f48eae74    |      72643 |    75040 | wc_order_5a8c8bc07c672 | REDACTED                    |       3 | 5                   | 2018-02-20 00:00:00 | NULL           |              0 |
|         73566 | 4848f24f720cd3d5782e90afc85ad254    |      72689 |    75585 | wc_order_5a95c398f081f | REDACTED                    |       3 | 4                   | 2018-02-27 00:00:00 | NULL           |              1 |
|         74806 | 4859f168ff9f259cd172cef8af4347fa    |      75409 |    76823 | wc_order_5aa04f4614fa9 | REDACTED                    |       3 | 5                   | 2018-03-07 00:00:00 | NULL           |              0 |
|         74807 | 4848f24f720cd3d5782e90afc85ad254    |      72689 |    76823 | wc_order_5aa04f4614fa9 | REDACTED                    |       3 | 5                   | 2018-03-07 00:00:00 | NULL           |              0 |
|         80994 | Online LoremIpsumD LoremIp.zip      |      80022 |    82510 | wc_order_5ad61491537c5 | REDACTED                    |       3 | 5                   | 2018-04-17 00:00:00 | NULL           |              0 |
|         80997 | Online Lore Lore.zip                |      79992 |    82514 | wc_order_5ad62e43130fb | REDACTED                    |       3 | 5                   | 2018-04-17 00:00:00 | NULL           |              0 |
|         81003 | Online LoremIpsumD LoremIp.zip      |      80022 |    82520 | wc_order_5ad65e8325336 | REDACTED                    |       3 | 10                  | 2018-04-17 00:00:00 | NULL           |              0 |
|         81951 | Dollar Lor em - LoremIps LoremI.zip |      83380 |    83411 | wc_order_5ae373be9ec2d | REDACTED                    |       3 | 5                   | 2018-04-27 00:00:00 | NULL           |              0 |
|         83214 | LoremIpsu LoremI & LoremIp.zip      |      28441 |    84631 | wc_order_5aeb3520de230 | REDACTED                    |       3 | 5                   | 2018-05-03 00:00:00 | NULL           |              0 |
|         83366 | Lorem\\\'s Ipsumss-LoremIp Lore.zip |      79944 |    84779 | wc_order_5aeca30f065a4 | REDACTED                    |       3 | 5                   | 2018-05-04 00:00:00 | NULL           |              0 |
+---------------+-------------------------------------+------------+----------+------------------------+-----------------------------+---------+---------------------+---------------------+----------------+----------------+

I've gone ahead and altered the field to increase the number of characters, as some others here have done in the comments:

ALTER TABLE ag_woocommerce_downloadable_product_permissions MODIFY COLUMN download_id VARCHAR(255);

I then attempted to grant permission again and it worked! No more error message, and the permission was added.

The new permissions entry that was created:

|         84794 | Lorem\\\'s Ipsumss - LoremIpsums LoremIp.zip |      83863 |    84625 | wc_order_5aeb2cec1bd77 | REDACTED                    |       3 | 5                   | 2018-05-16 00:00:00 | NULL           |              0 |

---

Note in case anyone else encounters this: I also had to temporarily disable 'NO_ZERO_IN_DATE' in sql_mode in order to alter the table. It didn't like the 0000-00-00 00:00:00 as the default date in access_granted.

[mikejolley]

Definitely should not be a filename. Just a longer hash. Extension conflict is possible..

[DrMTR]

I get this issue in last woocommerce also..

Could not grant access - the user may already have permission for this file or billing email is not set. Ensure the billing email is set, and the order has been saved.

[jawinn]

We recently upgraded to 3.4.4 and deactivated the outdated "WooCommerce Dropbox" plugin that you were also using @DrMTR . That was likely the culprit as the problem of the download_id storing the file name is fixed.

Note that proper IDs will only appear for permissions associated with newly added product downloads (not edited downloads which had this problem).