[halmobi]

Understood and thank you for your guidance!

I will post a separate enhancement suggestion / request.

Peter

[halmobi]

Hello and thank you so much for your prompt and informative reply! We have been digesting the information, looking at a solution.

We had been looking at cookies for a solution, since the ap_id cookie is set when the “Apply” button is clicked to apply the discount during the purchase process. This cookie should contain the Affiliate ID, our version wrongly contains a unique coupon code that we generate and is associated with a particular Affiliate as explained here.

[admin deleted code]

[halmobi]

Thank you so much for your fast and accurate response! We have followed through and were able to successfully get the functionality that we needed.

These are really great plugins, and you have terrific support. Truly top-notch and totally appreciated!

Cheers

Peter

[halmobi]

Thank you for this! I very much appreciate the additional functionality.

Peter

[halmobi]

Yes please, I would appreciate the shortcode you mentioned.

I am using eStore, eMember and the Affiliate Platform.

Thanks,

Peter

[halmobi]

Thanks for posting this, pmcmahon.

I have a similar situation and would also like to have a unique coupon code (not the coupon code that is the Affiliate Id from the coupon_tbl) link back and reward the Affiliate in addition to providing the discount.

Peter

[halmobi]

Yes, Superb!

It works now as long as the Thank-you page is added to the “excluded from lockdown” area.

Sincere Thanks once again, your fast response and attentiveness is so much appreciated!

Peter James

[halmobi]

Thank you for your very fast response and fix, the registration page works now! The new look and functionality for lock down of specific pages is great!

There is one more thing. Now the Thank-you page is locked down, it was working before. I do have the thank-you page added to the “excluded from lockdown” area. I also have the settings in eStore for “Return URL” set to the http://www.sitename/membersarea/thank-you page, and the PDT identity token is correct.

It is the same symptom as the issue with the registration page that you cleared up. The Thank-you page was working after a payment, now is getting the Lockdown screen. The URL is showing for example (fudged for this display) http://www.sitename/membersarea/thank-you?tx=8V599993HS999999A&st=Completed&amt=0.07&cc=USD&cm=coupon%3acoupon_code%26ip%3d99.999.999.999&item_number=

That is, when the URL has all the sale info it is locked down. If I clean the URL so that is is just http://www.sitename/membersarea/thank-you then it displays the thank-you page.

Perhaps the same fix, now for the thank-you page? I appreciate your help,

Peter

[halmobi]

Yes, I have specified your registration page’s URL in the “Registration Page” field under the pages/forms settings section.

The registration page loads correctly when site lockdown is enabled, as long as the URL only contains http://www.sitename/membersarea/registration.

The problem arises when the registration link is used. That URL is for example http://www.sitename/membersarea/registration?member_id=2&code=e91a7f30772d454249b74697d079ee99.

Placing “http://www.sitename/membersarea/registration” in the exclusion list under the “Enable Site Wide/Domain Level Lockdown” feature option makes no difference.

Placing the specific page http://www.sitename/membersarea/registration?member_id=2&code=e91a7f30772d454249b74697d079ee99 in the exclusion list DOES make it work.

So it seems that the lockdown feature is seeing the member’s complete link as a non-registration page URL. Is there logic in the plugin that parses out the URL to see if it contains a registration page piece? Otherwise I cannot see how it can exclude the members registration link from site lockdown, since every new member registration link is a unique URL, different than the base “http://www.sitename/membersarea/registration” page.

Thanks, I am looking forward to resolving this,

Peter

[halmobi]

Thanks for all your support and information!

[halmobi]

Thanks for your quick response!

You are right, the overall issue is now known to be on my server side. I have had more dialogue with host support, I know how to change the database collation. Now I am trying to get them to explain why the server default is “latin1_swedish_ci”. I live in Arizona, USA so I need education from them on that, so I can avoid having to manually intervene during database management tasks.

I will be using USA English, and so would like to confirm that “utf8_general_ci” is appropriate from your perspective.

Also, can you please confirm that deactivating the plugin in WordPress admin (not deleting the directory files), then deleting the tables in the database, then reactivating the plugin would recreate the tables without changing the plugin directory files?

Thanks! – Peter

[Author]

Posts