Repository Guidelines

Project Structure & Module Organization

This repository is a PrestaShop-based store with customizations across core-like folders and modules.

controllers/, classes/, src/: main PHP application logic (legacy + Symfony-style code).
modules/: feature modules (custom and vendor-like). Most front-end build/test tooling lives here.
themes/ and themes/leo_gstore/: storefront templates, assets, and theme behavior.
override/: PrestaShop overrides; keep changes minimal and well-justified.
app/config/, config/: environment and platform configuration.
changelog/: dated change notes (for example changelog/2026-03-19.md).

There is no single root build command; use module-scoped workflows.

php -l path\to\file.php: quick PHP syntax check before commit.
cd modules\ps_facetedsearch && npm install && npm run dev: install deps and run watch build.
cd modules\ps_facetedsearch && npm run build: production JS/CSS bundle.
cd modules\ps_facetedsearch && npm test: run Mocha tests (tests/**/*.spec.js).
cd modules\gsitemap && composer install: install PHP dev dependencies for that module.

Follow existing PrestaShop conventions: PHP classes in PascalCase, methods in camelCase, constants in UPPER_SNAKE_CASE.
Keep indentation/style consistent with surrounding file (legacy files vary; do not reformat unrelated code).
Use descriptive module/template names (example: AdminSearchController.php, search-results.tpl).
Prefer changes in modules/ or themes/ over editing vendor code in vendor/ or phpmailer/.

Test at the smallest valid scope: module-level first, then manual store/admin verification.
JS tests use *.spec.js (see modules/ps_facetedsearch/tests).
Run syntax checks for edited PHP files and exercise affected BO/FO pages (cart, product page, checkout, admin config).
No global coverage gate is enforced; add/update tests when touching tested modules.

Prefer clear, typed commits: feat: ..., fix: ..., chore: ....
Avoid vague messages like update or Save.
Keep commits focused to one concern and include touched paths in PR description.
PRs should include: purpose, risk/rollback notes, manual test steps, and screenshots for UI/theme changes.
For user-visible behavior changes, add/update a dated file in changelog/.