Customize Checkout Pages: Page names, pages order, buttons labels, help text, new custom pages

One additional core challenge to work around is the fact that we don't know until form submission whether payment will be processed immediately or require the intermediate redirect step. That ambiguity (and the general ambiguity you described) is the reason it was left generic and open for alteration; perhaps a simple contrib can provide a form for altering these since we don't have settings forms for checkout pages.

For example, if I know my store will only ever support PayPal WPS, I can easily change the text of the button to say "Proceed to payment" or something like that. Or if I know I only support on-site CC payment, I could just have it say "Complete order". "Submit payment" would work as a better default for the Review page (or Checkout page if Review isn't used), though, if it's determined that it's the final page before the Payment / Completion pages.

Whaddya think?

It is fairly easy to modify in a custom modules-- if you know what you're doing. It's also hackish (on a level that shouldn't require it). Moreover, this will result in plenty of implementations missing this detail and having poor end-user usability.

Yes, this will result in lost sales.

How about stuffing the correct pane into a variable (for now?) You could also use a table entry. Both are preferable to me, than needing a module to fix.

Thinking about this again, I really think it's better suited to a contrib module that alters these options into the UI for sites that want it. In core, translatability is more important than customizability. You cannot translate the value of a variable as suggested in #2 - the function only supports string literals.

This still might be a good option for core if we decide it's fine to provide an interface for changing these so long as the translatable default remains in place. We do a similar thing in a couple other places. The big issue to work around, though, would still be the fact that we don't know in advance (when the form is rendered) what the next page will be because of the way the off-site redirect pane works (as described in comment #1).

Have just tested Commerce Kickstart demo.
Bought some stuff "by accident" because of this "Continue to the next step" button.
I don´t think this button should be left left like this.
Isn´t there any solution for this yet?

Do the snippets above work as is or do I need additional code? I just realized this issue after launching a site and need to change the label to a ...Purchase one.

Thanks - I'm brand new to drupal.

-KM

**EDIT / UPDATE** - NM - It works when entered correctly...

Is there any news on this? The problem here in Germany is that there is a new law for customer protection. It regulates the text of the buy-button which confirms the terms of use. Ususally it is the last checkout button which hands you over to the payment process.

It specifies that the button text itself has to explicitly express that this click is subject to charge. It needs to say "BUY" or "Order subject to charge" or "Buy - fee required". Wording like "Order", "Continue" etc is not valid.

I haven't found a way to get this working and I'm not skilled enough in php to write custom modules. I'm quite concerned because German shops have to implement this until July 31st to avoid a warning by court (which is very expensive). Competitors can (and will to 99% ) sue violators over these details and can achieve a shutdown until you fix it.

Any help or hint is appreciated.

EDIT
Meanwhile I have crafted (copy & paste) a module that works and can be translated. Thanks to j0rd.

Nothing new since my comment in #4; I'm not aware of any contrib solving this yet.

maybe this could be a feature for Commerce Checkout Pages module.
They already have some configurations for the Checkout Pages.

Could Commerce Checkout Pages module be a part of Drupal Commerce, so the checkout pages titles, buttons or others could be configurable from UI?

I'm not sure if it should be a core feature or not, but at the very least we won't be putting a module like that in before 2.x.

This feature becomes more important since on August 1st in Germany a new law will become active which defines valid labels for buttons in online shops.
This is the official draft of the law: http://dipbt.bundestag.de/dip21/btd/17/077/1707745.pdf

The draft of the law says: It has to be absolutely clear that by pressing the button a financial commitment is made.
I guess this is mainly related to the button directly before the payment or the order completion (in the case there's no online payment).

Valid labels for Order-Buttons will be:

• ? (zahlungspflichtig bestellen)
• Order with costs (kostenpflichtig bestellen)
• Contract with costs (zahlungspflichtigen Vertrag schließen)
• Buy (kaufen)

Examples of invalid labels:

• Register / sign up (Anmeldung)
• Continue (weiter)
• Order(bestellen)
• Make order (Bestellung abgeben)
• Complete your order (Bestellung abschließen)

The button's label must be legible and no further additions may be added here. The same applies for check boxes or hyperlinks to query the confirmation of the purchase decision.

Consequences of failure to comply:
If the contractor doesn't meet the requirements, no valid contract will be concluded. This means the contractor does not have the legal basis to force the customer to pay.
(... Erfüllt der Unternehmer seine Pflicht aus Absatz 3 nicht, kommt ein Vertrag insgesamt nicht zustande; der Unternehmer kann vom Verbraucher das Entgelt nicht verlangen.)

PS: Proper translations very welcome.

Following issue is related, but points to a Europe wide law: #1470330: Legally important special button text for last checkout step

Peter, I have already mentioned it above and tried the solution posted. I made that rudimentary module which works for me. But as I am not a develper (and the hurdles on drupal.org are to high for me) I cant make a real module out of that. It lies in my git and if it makes sense, you or anyone else could improve and publish it.

I am going to mark this back to active, it is indeed a serious issue that will cause conversion loss. I ran against this issue for Kickstart.

http://baymard.com/checkout-usability might be a worthwhile resource for DC.

Hi! Thanks for #2. Unfortunately the code doesn't work for me.

@papalapp: could you please post your working code?

Thanks in advance.

EDIT: Sorry my own fault. It's working now! :)

i implemented Commerce Checkout Pages in the patch attached.
Unfortunately it seems this module has no update for almost a year.

• it's part of Checkout module
• I added the 2 new settings (customize buttons) required by the current issue.
• I build an i18n translation for the customized Checkout pages.

See my comment in #11. Why not try to take over that module in the meantime, vasike?

because of #14 : improve Commerce Kickstart usability.
and i am totally convinced that we definitely let people change some labels without coding and other custom contrib module.

retitleing.
the last patch doesn't change anything (the defaults). just adds new capabilities.

p.s. imho, this kind of capabilities (#1147690: Make "Add to cart" button text a display format setting (configurable at the field level by content type) this is another one) are basic (must have) capabilities that shouldn't miss.
it's like building fields without any UI labeling capability.

More specifically, the fact that I've said we won't be adding this patch to the 1.x branch. The problem is adding a whole new table and user interface at this point to what should be a stable core, and we currently aren't supporting i18n_string at all (the approach this patch takes to support translatable interface text). Commerce Kickstart could use the functionality just as easily if it were in a contrib module vs. core. : )

#1793200: Prepare for Drupal Commerce - new issue opened with patch for Commerce Checkout Pages module

it has an option to make a migration to Drupal commerce - it supposes that Drupal Commerce has something similar (what it's done the in the last patch #16).

Patch in number 16 works for me!

Hi vasike,

The patch in #16 works perfectly fine!

Many thanks

The patch in #16 works, but it is not possible to get a page before the "checkout" page.. That one is always on top.
When we install the Commerce Extra Login Page it is necessary to have a login page before the checkout page...
I tried altering a line in the function commerce_checkout_manage_form() from
'#disabled' => in_array($id, array('checkout', 'complete')), to '#disabled' => in_array($id, array('complete')),
It makes the "checkout" page also draggable, but the weight doesn't get saved for some reason...
Any lights on what is going wrong?

@sandravdv: I had the same issue. unfortunately it seems the Commerce Checkout Pages module seems to break the order of pages created by other custom modules by locking checkout and complete like this. I had created a few custom pages that exist before the "Checkout" page, but the dc_co_pages module forces "Checkout" to be the front page.

That module also seems to be abandoned.

I put up a patch here: #1865844: Don't lock checkout page and complete page that removes these locks, but I do fear what consequences might result. I wonder why those locks were put in place to begin with.

Made code example more clear

16: checkout_pages_customization-1308582-16.patch queued for re-testing.

New patch based on latest dev. I am still working on the i18n_string integration.

Any updates on this? I'm wary of using a year old patch. "Continue to next step" is misleading. I think "Complete Order" is meaningful even to payment redirect.

Any update on this? I am not sure how to use the above snippet -

<?php
function mymodule_commerce_checkout_page_info_alter(&$pages) {
  //dpm(array("PAGES" => $pages));
  if(!empty($pages['review'])) {
    $pages['review']['submit_value'] = t('Proceed with purchase');
  }
}
?>

Would like a legit way make this edit (for similar reasons to above users), rather than the non drupal, hacky

<script>
jQuery("input.checkout-continue").val('Submit Payment');
</script>

The hook works fine, but this still needs to be addressed better.

@drdrstudio
Create a directory under sites/all/modules with any name you want, for example drdrstudiomodule. In there, create a file drdrstudiomodule.info containing something like:

name = drdrstudiomodule
description = Some description.
package = Commerce (contrib)
core = 7.x
dependencies[] = commerce

And then a file named drdrstudiomodule.module with the code snipper. Be sure to replace 'mymodule' with 'drdrmodule' or whatever the module's name will be.

Why not just do a hook_form_alter?

I use a single page express checkout and did the following...

function MYMODULE_form_alter(&$form, &$form_state, $form_id) {
  if ($form_id == 'commerce_checkout_form_checkout') {
    $form['buttons']['continue']['#value'] = t('Desired Custom Text Here');
  }
}

HTH

Use form_alter to customize submit button values.

function MYMODULE_form_alter(&$form, &$form_state, $form_id) {
  switch ($form_id) {
    case 'commerce_checkout_form_checkout':
      if (isset($form['buttons']['continue']['#value'])) {
        $form['buttons']['continue']['#value'] = t('Proceed with purchase');
      }
       break;
   }
}

We're done making major changes to 1.x

@j0rd thanks for the snippet in #2. :)

Thought I'd try #2 since someone commented 5 months ago that it worked for them. However, it did not work for me and the button remains with the same text. I'm on the latest version of Commerce 1.x. Is it possible that my theme (Porto) is somehow not allowing the change? Seems like a simple solution, but simply not working. Any thoughts? Really a bad title on a button when clicking it initiates the payment transaction.