POC Decouple OPC from Hummingbird

[kpodemski]

Why?

Currently, the One Page Checkout (OPC) module is tightly coupled with Hummingbird. To improve the ability to make changes quickly, we should decouple the module, allowing it to render the front-end independently.

This PR includes:

• Moving all template files into the module.
• Moving all assets (such as CSS and JS part) into the module.

Native module should work best with native theme, but theme authors can easily override all the views, CSS and JS files available.

Known issues:

• Module seems to completely ignore custom fields added via additionalCustomerFormFields, and additionalCustomerAddressFields
• Having bootstrap variables inside the .scss may be overkill, especially since theme-scoped variables may have different values. Solution? Themes should adjust the styling via theme-level overrides, we should make sure it looks and works well on Hummingbird
• Tests are red in the original branch

[ThbPS]

These changes will need to be kept in Hummingbird:

• templates/customer/password-email.tpl
• templates/customer/password-infos.tpl
• templates/customer/password-new.tpl
• templates/customer/registration.tpl
• templates/customer/_partials/customer-form.tpl
• templates/customer/_partials/login-form.tpl
• templates/checkout/checkout.tpl
• templates/checkout/_partials/connected-account-info.tpl
• templates/checkout/_partials/steps/personal-information.tpl

Module seems to completely ignore custom fields added via additionalCustomerFormFields, and additionalCustomerAddressFields

https://prestashop-jira.atlassian.net/browse/SPE-115

Tests are red in the original branch

OnePageCheckoutProcessProvider is not available in the latest PrestaShop Docker image.
That is why PHPStan is failing. For now, testing must be done locally.

[kpodemski]

@ThbPS

I'm pretty sure we can incorporate some of these changes to the core, so that we can limit the updates needed on the theme-level. I'll think about it :)

[kpodemski]

@ThbPS @kevin-carangeot

templates/customer/password-email.tpl
templates/customer/password-infos.tpl
templates/customer/password-new.tpl
templates/customer/registration.tpl

Ensure that this method FrontController::getTemplateVarUrls is modified in the core. For example:

foreach ($p as $page_name) {
    $index = str_replace('-', '_', $page_name);

    $params = [];
    if (in_array($page_name, ['authentication', 'register'] && ($back = Tools::getValue('back', 0)) && Tools::urlBelongsToShop($back)) {
        $params['back'] = $back;
    }

    $pages[$index] = $this->context->link->getPageLink($page_name, true, null, $params);
}

templates/customer/_partials/customer-form.tpl
templates/customer/_partials/login-form.tpl

I'm not a fan of using $smarty.get.back directly in the template, and use Tools::urlBelongsToShop($back) as well. Would be better to pass it through the controller. We'll make OPC exclusive to 9.2+ only, so it is doable.

templates/checkout/checkout.tpl

There is no problem following what I've done and just using the entire checkout.tpl exclusive to OPC :) This would also help you handle:

templates/checkout/_partials/connected-account-info.tpl
templates/checkout/_partials/steps/personal-information.tpl

In short: OPC module takes full control over checkout rendering :)

[ThbPS]

@kpodemski

Thanks for your feedback.
I created a Jira ticket (https://prestashop-jira.atlassian.net/browse/SPE-125) to complete the isolation of the OPC module.