Checkout process not working in WordPress - although identical to Joomla

Hello,

Thank you for the report. We could reproduce it on a WordPress test site with HikaShop 6.6.0, and it is not related to your migration: it comes from two bugs in the WordPress part of HikaShop.

The first one is the token message. When the customer logs in or registers inside the checkout, WordPress creates a new session, but the security token of the checkout page is still computed for the previous one. The first click on "Next" after that is refused, the checkout reloads on the same step, and the 401 you see is the same refusal when it happens during the refresh of a block. A second click on "Next" goes through, because the reloaded page carries a valid token.

The second one is a PHP error with PHP 8 which can stop the refresh of the checkout blocks (login, address) when a HikaShop system plugin is enabled, which is the case by default. With errors hidden, you only see the checkout not moving on.

Both are fixed on our side. Download again the install package of HikaShop 6.6.0 on our website and install it on yours in order to get the patchs.

Hello Chris,

Thank you for the screenshots. We set up a WordPress site with your checkout workflow (guest checkout, email confirmation, the same steps) and found three problems in the WordPress part of HikaShop that the previous patches did not cover:

- With a workflow of several steps, the "Next" button displayed the first step again without any message, even when the guest information and the address were filled properly. That's the checkout not moving on.
- When a step is refused, the page displaying the error had its javascript broken. That's why, on your second screenshot, "Guest" is selected on the left while both the registration and the login forms are displayed on the right.
- Clicking on "Next" without filling the login form ended on a PHP error.

These are fixed on our side and are included in the package currently available on our website so you can update to it to get them.

However, we could not reproduce the security token error itself on our test sites, including with a guest checkout, so we don't know yet why your site refuses the token. To help us find it, could you tell us:

- the list of the plugins active on your WordPress site, and whether a cache plugin, a server cache or a CDN like Cloudflare is used,
- whether the error appears on the very first click on "Next" after opening the checkout page, or only after the page stayed open for a while,
- whether you are logged in the WordPress backend in the same browser while testing.

If you can, a temporary backend access to the site through our contact form, with a link to this thread, would let us check it directly.
www.hikashop.com/support/contact-us.html

Hello Chris,

Thank you for the access. We went through the checkout on your test site as a guest, and the "Next" button sends the customer back to the first step even when the guest information and the address are saved properly. If we open the second step directly, the payment methods display, so the data is fine: only the link to the next step is wrong.

Your site runs the build 2609141229 (you can see this number at the top of the main tab of the HikaShop configuration). The fix for that problem was added to the package after that build. Please download HikaShop Business again from your subscriptions area and install it over your current version, the build number displayed in the configuration should then be more recent. That should let the checkout move on to the payment step.

We did not get the security token error during our tests on your site. If you still see it after the update, please tell us after which click it appears.

Also, the setting "URL where you will be redirected when the cart is empty" (main tab of the HikaShop configuration) points to /store/online-store-all which gives a 404 on your website (it probably comes from your Joomla site). You can change it to your /shop/ page, or empty it so that HikaShop uses your shop page.