Link Expired for no apparent reason

[provision147]

I am using WP eMember Version v7.0.2 and WP eStore Version v3.4.9. I have a Multi Blog site where my second-blog site is in a sub-directory rather than a sub-domain. It is in the second (sub) blog site where I have downloadable products set up. To the best of my knowledge everything is set up properly and everything works until I click the download links for any product ID. Rather than taking me to the downloadable file it simply displays a blank page with the following two words… “link expired”. I have set the expiry to 4444 hours, but no matter what I put there, it matters not. I have tried several things, including generating an encrypted links through Admin Functions which also display the same message.

[wzp]

Please upgrade to the latest version of eStore and try again…

https://support.tipsandtricks-hq.com/update-request

[provision147]

Okay, I completely removed WP eStore from the site/s and removed all WP eStore database tables putting everything back to square one. I deactivated all plugins except WP eMember. I installed the upgrade to v5.9.6 and carefully went through the settings and added a downloadable product. I did a test purchase which worked great but for the fact that I get the same result when I click on the generated link. A page that displays “Link expired”. When I generate a link using Admin Functions the log file says:

[09/16/2011 12:12 AM] – SUCCESS :Generating download link for single file.

I am at a loss.

[wzp]

I noticed in your original post, you said you have a multiple blog site. Is eStore only installed on one of those blogs?

[provision147]

eStore is installed on the primary blog (www.matteroflife.ca) and activated on the sub-blog (www.domain.ca/sub_blog)

Go here to try it out…

http://www.domain.ca/sub_blog/member-page/download/

Log in as… *****REDACTED*****

[wzp]

I am suspicious about whether or not a link generated by eStore on the sub blog, is inadvertently invoking the download.php script on the primary blog. If you are not using eStore on the primary blog, try deleting the plugin from there.

[provision147]

Thanks for your rapid responses! You are a real blessing!

I can’t delete it from the primary blog. That is how WordPress Multi-site works. All the plugins are installed in the primary blog server and thereby become available and activated on each individual sub-blog. Every pluggin on my sub-blog is set up and activated in this way, including eMember (working flawlessly) as well as all my other plugins.

BTW, although eStore is installed on the primary blog, it is not activated there.

I also deactivated eMember to see if somehow it was interfering. Nope!

[provision147]

I think I may have found the solution thanks to you, as you are thanked for sorting this issue out at the bottom of this article in the forum…

http://www.tipsandtricks-hq.com/ecommerce/how-to-customize-the-encrypted-download-url-224

[provision147]

I am getting closer. I followed the instructions in the article above placing ‘cppmembers’ in the new (custom) “download.php” file and uploaded it to the http://www.matteroflife.ca/downloads/ directory.

the line is… $wp_home_dir = ‘sub_blog’;

I also revised the “Download Validation Script Location” field to reflect the new location of the “download.php” file to be “http://www.domain.ca/downloads/”

However, I now get the following error…

===========================================

Warning: scandir(sub_blog) [function.scandir]: failed to open dir: No such file or directory in /home/domain/public_html/downloads/download.php on line 33

Warning: scandir() [function.scandir]: (errno 13): Permission denied in /home/domain/public_html/downloads/download.php on line 33

Please tell us “the Custom Download Validation Script could not find the WordPress home directory, because the script is not properly configured.” Thank you!

[wzp]

The error occurs because the custom script is having trouble finding the correct location of the active eStore plugin directory. Because there is more than 1 copy of the plugin and WordPress installed, it gets confused. I suppose that, given you seem to be code savvy, you could always hack the custom script and give it some “help,” by just hard coding the proper path to the active eStore plugin directory.

That would fix the problem for the immediacy. In order to fix the problem for future customers, and “for greater humanity,” I’d need to study your configuration. If you’d like, please drop me a line on my contact form TheAssurer.com/contact and I will get back to you.

[wzp]

Okay, issue resolved, here is the lowdown on what happened…

The “Download Validation Script Location” must ***ALWAYS*** be at or below the WordPress root directory. Normally, this maps to the same PHYSICAL directory as your WordPress installation. But under WordPress Multi-Site, there is only one physical WordPress installation directory, and rewrite rules are used to map network blogs into LOGICAL directory or domain paths.

In this case, the networked blog had a logical URL path of domain.ca/sub_blog and thus /sub_blog became the LOGICAL WordPress root directory.

Therefore, the Download Validation Script Location must be set as: domain.ca/sub_blog/downloads/

However, back in the PHYSICAL world, the actual location of the downloads directory is in the location you’d specify if you were to use a custom script location of domain.ca/downloads/ on the main blog.

I know, it’s complicated… Normally, a warning message appears in the settings menu that explains all of this, but because of the logical remapping that takes place on subdirectory installations, the warning logic gets confused.

[provision147]

Thanks once again for being so diligent to resolve this. I was tearing my hair out for sure! Please remove any references in the above thread to links and log in information.

Much appreciated!

[wzp]

Redactions completed.

[Author]

Posts