Tips and Tricks HQ Support Portal › Forums › WP eStore Forum › eMember not directing to PayPal subscription after registration
- This topic has 6 replies, 3 voices, and was last updated 5 years, 11 months ago by Dyan.
-
AuthorPosts
-
February 9, 2019 at 2:01 am #15309DyanMember
Hello. I really need help, please. I have eMember. I have eStore. I have eStore Members Only Download Button. I have Extra Shortcodes for WP eStore. I believe I have correctly configured the “subscribe” button so that members can subscribe and then be redirected to the member area. However, after registration, registrants are not being taken to PayPal. They are able to register. However, they are never taken to paypal as should happen directly after registration. What is happening is they register and are then asked to log back into site and are taken correctly to the member area. But in the member area, they are not seeing the member download only button, presumably because they have not been asked to make a subscription (for our 3 free day trial). The part that seems to be missing is the part where they are asked to make the actual subscription for the free 3 day trial after registration. What am I not understanding? Thank you.
February 10, 2019 at 2:57 am #79181wzpModeratorAre your subscription buttons being managed by eMember or eStore? Please enable the debug logs for both eMember AND eStore. Then examine the debug logs for possible clues.
February 10, 2019 at 9:54 pm #79182DyanMemberThey are being managed by eStore. My understanding was that we could not make a subscription type button without buying the plugin for eStore. So we went ahead and additionally bought that. In any event, I believe we have solved this particular issue.
However, we have bigger issue. That is that in the member area, with the member only download button installed for each product, with example shortcode like this: [wp_eStore_fancy_display id=”22″ style=”1″ restriction=”2-3|4|1″] when we click on “Download,” we DO get a file, but it is an empty file. No KB.
Here is an example of the file type when we click download from the member area, which just says it’s a “file” under properties. open_id=1pVv4eHefERUH40XgkvTWLPoZq4iGweN1
We are serving the actual MP4 file from google drive. We have correctly checked this checkbox:
‘If checked the digital content will be delivered via an anonymous encrypted download process (the customer won’t know where it is coming from). If unchecked the buyers will be redirected to the above URL when they click on the encrypted link.’
We have also added the correct membership level for access into the Reference Text box.
Please advise as to what the problem could be. Why is an empty file of type ‘file’ being delivered instead of an MP4 which is our actual file type?
Also, please advise as to exactly where we enable debug mode. Thank you.
February 11, 2019 at 4:01 am #79183adminKeymasterThe new issue that you have explained would be related to the download manger side of things. Go through the following checklist (it should help you figure out what could be causing the encrypted download issue on this site):
Downloaded file size is 0 (Zero) byte or 404 error or Other file download error
February 11, 2019 at 6:34 pm #79184DyanMemberThank you. Checklist:
1. We have verified that the URL specified in the Digital Content URL field is not resulting in a 404.
2. We have verified there are no spaces in the file name of any of our downloadable files.
3. http?? We are on an https protocol. And it is all typed correctly (https://) for every one of our downloadables.
4. The only files in the downloads directory folder of the estore are these:
MP3 (a folder with test_mp3.zip in it)
ebook.zip
index.hteml
myscript.zip
Readme.txt
We do not find the two files .htaccess or htpasswd in the downloads directory of the estore plugin. The files listed above are the only files located in the downloads directory folder of the estore.
5. We have tried all of the other download methods explained in the forum topic for /wp-estore-download-methods. None worked.
6. We have 140 products. It is not reasonable to break the files up into multi-units.
7. We deactivated W3 Total Cache.
We have 256MB RAM.We do not have mod_xsendfile
You do not say how much RAM is actually needed: “You can upgrade your hosting to a plan with enough RAM.”
How much RAM is “enough” RAM?
8. We reset the value of the Download Validation ScCript Location.
…from wzp Moderator 8 years ago: “Also…
If the URLs of the product files being offered for download are stored in a URL path that is different from the eStore install; try setting the “Automatic URL Conversion Preference” (Version 4.5.7 and higher) to “Do Not Convert.” This applies in situations similar to the following:
Your WP and eStore use the someplace.com/site URL but the product download files are stored in the elsewhere.someplace.com/files URL.
Yes, this is our situation as we are serving from google drive.
We reset the Download Validation Script Location:
Reset this value. Updated. And updated again as per instructions.
Generated encrypted link which still does not work, i.e., is serving 0 MB. Did this for 3 products. Same result.
9. We did not upgrade the plugin. We have already current version initially installed.
10. We are serving from google drive, which does indeed use capital letter combinations in their links.
BOTTOM LINE: This is the only thing that seems to work for us and it is not our ideal scenario, but it works (apart from uploading 140 product files to Amazon S3 network now and installing that integration):
“Edit the eStore product in question and uncheck the “downloadable” checkbox for the product (look under the “Digital Content Details” section for this option). This will force eStore to let the browser handle the download.”
That does work.
Thanks.
February 11, 2019 at 7:12 pm #79185wzpModeratorWe have 256MB RAM.We do not have mod_xsendfile
You do not say how much RAM is actually needed: “You can upgrade your hosting to a plan with enough RAM.”
How much RAM is “enough” RAM?
It depends on the number of plugins you have running. Also, the amount of RAM is specifically referring to allocatable “PHP memory.” 768 MB or higher is recommended.
We are serving from google drive, which does indeed use capital letter combinations in their links.
We DO NOT support Google Drive integration. We DO support Amazon S3 integration:
https://www.tipsandtricks-hq.com/ecommerce/wp-estore-amazon-s3-integration-addon-4247
“Edit the eStore product in question and uncheck the “downloadable” checkbox for the product (look under the “Digital Content Details” section for this option). This will force eStore to let the browser handle the download.”
That does work.
The reason it “works,” is because Google Drive URL do not point directly at the file. It’s sort-of a redirection through their internal database. By not checking “downloadable,” you are forcing the user’s browser to navigate the Google redirections; until a file is finally served.
February 12, 2019 at 6:15 am #79186DyanMemberYes. I understand. Thank you.
-
AuthorPosts
- You must be logged in to reply to this topic.