Easy-digital-downloads: Allow multiple checkout pages

[tnorthcutt]

This is a for client project that @tubiz and I are going to be working on, and will be PRing into EDD core.

The title says it all: right now, EDD only supports one checkout page; we'll be adding support for multiple checkout pages.

[SDavisMedia]

First of all, 😍 ... and also, thanks so much for the contribution! I'm going to post remarks below as if we wrote the code. I'll let the lead devs decide how to proceed. I'm just here to test. 😄

Okay, I'm getting a JS error on the Downloads -> Settings -> General page the moment I click into the Chosen field:

Uncaught TypeError: Cannot read property 'length' of undefined
http://localhost/edd/wp-content/plugins/easy-digital-downloads/assets/js/admin-scripts.js?ver=2.8.1 line 1289

The pages save just fine and each of them seems to be able to process a payment. Getting to "a" checkout page might be a problem, though. Not sure how we plan to make edd_get_checkout_uri() backwards compatible? It's being used in a number of different ways, including the Add to Cart button. It just returns false now.

I really can't think of anything else to test. The behavior should be the same across all checkout pages. So it's just a matter of when to use what checkout page we'll have to figure out. 🤔

[tubiz]

Thanks for the comment Sean. I will look into the JS error on the console I was able to replicate it on my end too.

I only checked edd_is_checkout() to make sure it still work with the multiple checkout pages. I totally forget about edd_get_checkout_uri().

I am working on making edd_get_checkout_uri() backwards compatible as well. A single uri will have to be returned from the multiple pages set.

[SDavisMedia]

Very much appreciated, @tubiz!

[tnorthcutt]

@SDavisMedia regarding edd_get_checkout_uri(), do you have a preference on how returning a single uri is handled? For instance, should there be some UI to indicate a "primary" checkout page?

[SDavisMedia]

@tnorthcutt the thought of intentionally setting a primary checkout page did cross my mind. I don't think it's safe to automatically assume one for the user. He or she should make that decision, in my opinion.

Would love to hear from @pippinsplugins and @cklosowski here as well since this could potentially complicate a very basic UI.

[cklosowski]

I have a suggestion that I think might work but let me get non-mobile so
that I can get code snippets in easily.

On Aug 4, 2017 8:21 AM, "Sean Davis" [e-mail] wrote:

@tnorthcutt https://github.com/tnorthcutt the thought of intentionally
setting a primary checkout page did cross my mind. I don't think it's safe
to automatically assume one for the user. He or she should make that
decision, in my opinion.

Would love to hear from @pippinsplugins https://github.com/pippinsplugins
and @cklosowski https://github.com/cklosowski here as well since this
could potentially complicate a very basic UI.

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
https://github.com/easydigitaldownloads/easy-digital-downloads/issues/5891#issuecomment-320276838,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABU2LCU9u1pWmtUiRsauUVCBqviZ9eKxks5sUzcAgaJpZM4Ohn9I
.

[tnorthcutt]

@SDavisMedia agreed. My first thought was to take what someone chooses in the multi-select, and populate a new select (or radio buttons) from that, to let them choose a primary checkout page.

[cklosowski]

Before this goes much further let me voice the opinion that I think a UI
for this is a slippery slope, and what I have I mind should solve any
issues without changing the UI for selecting checkout pages.

On Aug 4, 2017 8:24 AM, "Travis Northcutt" [e-mail] wrote:

@SDavisMedia https://github.com/sdavismedia agreed. My first thought
was to take what someone chooses in the multi-select, and populate a new
select (or radio buttons) from that, to let them choose a primary checkout
page.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/easydigitaldownloads/easy-digital-downloads/issues/5891#issuecomment-320277715,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABU2LNJvW6jSQ1fGLEw5EAXgEJLAoLx-ks5sUzfAgaJpZM4Ohn9I
.

[tubiz]

Also there are multiple calls to edd_get_option( 'purchase_page' ) the value returned is sometimes used to get the link to the checkout page using the get_permalink() and in edd_checkout_button_next()

This will have to be fixed as well.

[tnorthcutt]

Regarding the js error in admin-scripts.js, I think there's an already existing bug there. In that file, we're doing:

var placeholder = $(this).parent().prev().data('search-placeholder');

So we're looking for a data-search-placeholder attribute. But, chosen.js requires a data-placeholder attribute (which is what exists on these select elements).

Probably related to https://github.com/easydigitaldownloads/easy-digital-downloads/issues/5357

[tubiz]

@tnorthcutt I have fixed this but haven't pushed the code yet. EDD uses data-search-placeholder to get the value of the placeholder that is set while chosen.js uses data-placeholder

[cklosowski]

Again. I'll voice it again. I think this is the wrong approach. If you can
wait 20 minutes I have a solution that I think will be less confusing and
create far less support for us.

On Aug 4, 2017 8:48 AM, "Tunbosun Ayinla" [e-mail] wrote:

@tnorthcutt https://github.com/tnorthcutt I have fixed this but haven't
pushed the code yet. EDD uses data-search-placeholder to get the value of
the placeholder that is set while chosen.js uses data-placeholder

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/easydigitaldownloads/easy-digital-downloads/issues/5891#issuecomment-320283652,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABU2LCkwP2lId1hxL4_x1cSK-wiI6uemks5sUz1kgaJpZM4Ohn9I
.

[tnorthcutt]

@cklosowski I think there was a misunderstanding - we were just discussing a console error this new feature triggered. Totally fine waiting on your guidance for the UI issues 👍

[SDavisMedia]

LOL calm down, Chris! 😂

[cklosowski]

Ok,

So my initial thoughts are YES, let's support this, but I think altering the dropdown to allow multiples is the wrong approach. I think it creates a confusing interface for users (specifically when it comes to settings a 'primary') _but_ we have some solutions that mean we can avoid customer confusion all while supporting it pretty easily.

The main issue is that the scripts needed for a Checkout process are not loaded when the page isn't defined as 'THE' checkout page in the EDD settings, but we can fix that!

I think we can approach this programmatically with the has_shortcode function, and by adding something on the page editor to allow a post meta item of 'is checkout' to be saved.

In edd_is_checkout() we can do logic like the following:

if it is the defined checkout page
    true
if the page contains the shortcode
    true
contains post meta that it's checkout
   true

With that we can change the setting Label to Primary Checkout but nothing else needs to change as far as edd_get_checkout_uri(), etc, and our installer doesn't need any changes, and we avoid a bunch of JS manipulation on the settings page.

It also allows someone to drop the shotcode on any page and have it load the scripts, and it also allows a developer who custom creates a checkout page not using the shortcode, but a custom coded form, to check a box stating, yes this is a checkout page as well.

We'd also need to update the System info to include 'Primary Checkout' and then also maybe page IDs of any other pages that contain the shortcode or have the post meta assigned.

[tnorthcutt]

@cklosowski that approach makes sense.

Because I'm working on a fixed budget doing this for a client, I'd like to be careful not to do any more unneeded work. Who has final say on what method will get merged in when we PR it?

[pippinsplugins]

I agree 100% with @cklosowski's approach. The settings UI should not be changed; the only adjustment that should occur is making the [download_checkout] shortcode work fully whether it is on the _real_ checkout screen or an _additional checkout screen.

I'm +1: to that approach.

[cklosowski]

Ok I'll get that worked up into a PR. @tnorthcutt fully respect the fact that you're on billable time for this feature to get added, so I'll code up the alternate approach to this and get it included.

[tnorthcutt]

@cklosowski awesome, much appreciated. Feel free to pull me in at any point for feedback/testing/rubber ducking/etc.

[Blakkrose]

I have created a web site in more languages.
I have inserted in every page (one per language) the link to checkout pages but all link bring to the cart in italian because in the plugin's option I have inserted the link to the checkout pages in Italian.
I think my problem is the same. How do I do to insert some different links that bring to the cart in the different languages?

[tnorthcutt]

@cklosowski Hiya - let me know if you need anything from my end to get this wrapped up. Thanks!

[cklosowski]

@tnorthcutt Just opened up a PR that _should_ do the trick.

In my testing, it's important to note that the edd_is_checkout() function only really works after the template_redirect action is fired by WP Core. I believe due to the way that $wp_query loads up the contents of the queried object.

But this supports the page post type with the following:
1) Normal EDD checkout setting (renamed Primary Checkout)
2) Pages now have an Easy Digital Downloads Settings metabox that gives a checkbox to state this is specifically a checkout page
3) If the page being loaded contains the [download_checkout] shortcode.

Also, if the page you are editing is currently set to the Primary Purchase Page, the box is disabled.

[pippinsplugins]

Is it necessary to add a metabox to indicate a page is a checkout screen? Looping back to this comment, could we not just make [download_checkout] work on stand alone pages without any other distinction being set on the page?

[cklosowski]

@pippinsplugins there is a case where someone may not use the [download_checkout] as an option. If someone custom builds the checkout page, not using the shortcode (which has actively been done by multiple people that I personally know), it allows them to be able to define it as a checkout page, even though it doesn't contain the shortcode.

[pippinsplugins]

If someone builds a customer checkout screen without the shortcode, I believe it should be their responsibility to make that page work by adjusting the filters we provide them.

Adding a UI option seems overly burdensome to me and will likely result in a lot people (ones that have no need for multiple checking screens) asking "what is this here for and why do I need it?".

[cklosowski]

@pippinsplugins I just based the inclusion of that by your 100% approval of my approach listed in https://github.com/easydigitaldownloads/easy-digital-downloads/issues/5891#issuecomment-337066436

I agree 100% with @cklosowski's approach. The settings UI should not be changed; the only adjustment that should occur is making the [download_checkout] shortcode work fully whether it is on the real checkout screen or an _additional checkout screen. I'm +1: to that approach.

[cklosowski]

I don't mind removing it, I just thought we were in agreement that it was part of the solution.

[pippinsplugins]

Ah, my fault. That was misleading.

I would like this to work solely through the usage of additional [download_checkout] shortcodes and nothing more in the UI.

[cklosowski]

Works for me! I'll strip out the setting.

[cklosowski]

Testing notes:

1) Add the [download_checkout] shortcode to a page and set it as the checkout in EDD Settings
2) Add the [download_checkout] to a page that is not the EDD checkout
3) Add the [download_checkout] to a post.

All three scenarios should trigger edd_is_checkout() to return true, which can be seen in the latest EDD Dev tools here:

[SDavisMedia]

All scenarios check out as checkout for me.