Skip to content

DECISIONS.md

Latest commit

 

History

History
90 lines (71 loc) · 5.6 KB

DECISIONS.md

File metadata and controls

90 lines (71 loc) · 5.6 KB

ps_onepagecheckout Decision Log

2026-03-05

D-001

  • Context: hook creation was attempted in module runtime.
  • Decision: module only registers existing Core hooks.
  • Impact: respects native module responsibilities.

D-002

  • Context: module used a custom spl_autoload_register.
  • Decision: remove custom autoloader, use namespaced classes + Composer autoload.
  • Impact: aligns with native module standards.

D-003

  • Context: duplicated OPC config flags existed.
  • Decision: keep only PS_ONE_PAGE_CHECKOUT_ENABLED as activation flag.
  • Impact: BO behavior is consistent across module manager and module BO tab.

D-004

  • Context: BO direct navigation to OPC config was missing.
  • Decision: add AdminPsOnePageCheckout tab rendering the same module-owned configuration flow as Module Manager Configure.
  • Impact: config is reachable from both entries with the same behavior and without relying on redirect-only navigation.

D-005

  • Context: module had legacy fallback payload and redirect behavior.
  • Decision: remove fallback payload/redirect logic from module.
  • Impact: native module owns OPC behavior without legacy coupling.

D-006

  • Context: no JS watch/build workflow in module.
  • Decision: add webpack/npm toolchain under views/ and GitHub workflow.
  • Impact: reproducible JS build for development and CI.

D-007

  • Context: BO configuration flow logic was implemented inline in ps_onepagecheckout.php.
  • Decision: move BO configuration submit/render logic to src/Form/BackOfficeConfigurationForm.php.
  • Impact: clearer separation of concerns and easier BO configuration maintenance.

D-008

  • Context: OPC form construction was duplicated in builder and module front controllers.
  • Decision: centralize OPC form/persister creation in src/Form/OnePageCheckoutFormFactory.php.
  • Impact: single source of truth for OPC form wiring and easier future Core-to-module feature ports.

D-009

  • Context: runtime checkout flag could be inconsistent when module injects its checkout process.
  • Decision: use a module-owned checkout process (OnePageCheckoutProcess) that overrides isOnePageCheckoutEnabled() with module flag.
  • Impact: is_one_page_checkout_enabled stays coherent with module activation in checkout runtime without module dependency on Core OPC checker interface.

D-010

  • Context: BO configuration class attempted to access protected Module internals ($table, trans()), triggering HTTP 500.
  • Decision: BO form uses module-safe/public data and Context translator instead of protected module API.
  • Impact: AdminPsOnePageCheckout configuration renders reliably from both BO entry points.

D-011

  • Context: BO module form used a basic HelperForm radio and did not match historical Core checkout-layout UX.
  • Decision: move BO rendering to a module Twig template with enriched checkout layout options (badge, descriptions, features, illustrations), and ship CSS/illustrations in module assets.
  • Impact: BO UX parity is preserved while keeping all implementation ownership in ps_onepagecheckout.

D-012

  • Context: BO tab was historically stored as AdminPsOnepagecheckout in existing databases.
  • Decision: do not ship a module-owned upgrade/ migration for this rename yet, because the module has not been released and there is no released-to-released upgrade path to support at this stage.
  • Impact: no speculative upgrade file is added before it is needed, but module-owned upgrade/ scripts remain expected later whenever a real released version transition requires a migration.

D-013

  • Context: module targets PrestaShop 9.2.0, where BO rendering is Twig-first.
  • Decision: BackOfficeConfigurationForm::renderConfigurationForm() now requires Twig and no longer falls back to Smarty templates.
  • Impact: BO configuration rendering is simpler, explicit, and aligned with 9.2.0 expectations.

2026-03-17

D-014

  • Context: PS_ONE_PAGE_CHECKOUT_ENABLED is no longer provisioned by Core and must be fully owned by the module lifecycle.
  • Decision: create PS_ONE_PAGE_CHECKOUT_ENABLED during module install with value 0, and remove it during module uninstall instead of recreating it with value 0.
  • Impact: module installation remains self-sufficient without activating OPC by default, and uninstall leaves no stale OPC configuration entry behind.

D-015

  • Context: module PHPUnit suites were not executed in CI, and local vs CI execution paths were diverging.
  • Decision: run unit and integration suites in GitHub Actions through a shared isolated entrypoint, ./scripts/run-tests.sh, used both locally and in CI.
  • Impact: PHPUnit execution is reproducible across environments, and regressions detected by unit or integration suites now block validation.

D-016

  • Context: ps_onepagecheckout must be available as a native baseline in the Core and later upgradable from the Back Office.
  • Decision: publish prestashop/ps_onepagecheckout on Packagist for initial Core inclusion, then expose newer versions through distribution-api.
  • Impact: the baseline version is pinned by the Core composer.lock, while newer compatible releases can still be discovered and upgraded from Module Manager.

D-017

  • Context: distribution and archive retrieval for native module updates are handled outside this repository by Packagist and distribution-api.
  • Decision: keep module tests focused on module-owned lifecycle only; document external publication/distribution steps without retesting them here.
  • Impact: the suite validates install/enable/disable/uninstall behavior, while Packagist publication, archive retrieval and upgrade execution through distribution-api stay external operational concerns.