docs: map existing codebase with PAUL
- stack.md - PrestaShop 1.7.x, PHP, Smarty, SCSS, modules - architecture.md - MVC + hooks, override mechanism, CQRS in src/ - structure.md - Directory layout, key file locations - conventions.md - PHP/Smarty/SCSS/JS conventions, PS patterns - testing.md - No automated tests in custom modules - integrations.md - Allegro, Empik, BaseLinker, shipping, payments - concerns.md - Override fragility, EOL risk, missing CI/CD - db_schema.md - Custom tables, modified core tables Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
146
.paul/codebase/concerns.md
Normal file
146
.paul/codebase/concerns.md
Normal file
@@ -0,0 +1,146 @@
|
||||
# Codebase Concerns
|
||||
|
||||
**Analysis Date:** 2026-04-27
|
||||
|
||||
## Tech Debt
|
||||
|
||||
**Override Chain Fragility — Order Processing:**
|
||||
- Issue: Three modules (modrefchange, AddOrderExtraFields, x13allegro) all modify `Order` class through overlapping overrides
|
||||
- Files: `override/classes/order/Order.php`, `modules/modrefchange/override/classes/order/Order.php`, `modules/AddOrderExtraFields/_overrides/classes/order/Order-modrefchange.php`
|
||||
- Why: Each module added override independently without documentation of interdependencies
|
||||
- Impact: Hook execution order undocumented; disabling modrefchange orphans hooks; AddOrderExtraFields install copies override file (fragile)
|
||||
- Fix approach: Document hook execution order, add comments to override file explaining all contributing modules
|
||||
|
||||
**Payment Module Logic Bug:**
|
||||
- Issue: Operator precedence bug in order source detection
|
||||
- Files: `modules/AddOrderExtraFields/override/classes/PaymentModule.php` (line ~350)
|
||||
- Code: `if (!$order->module == 'x13allegro')` — evaluates as `!(false) == 'x13allegro'` not as intended
|
||||
- Impact: Order source may be incorrectly set in edge cases
|
||||
- Fix approach: Change to `if ($order->module !== 'x13allegro')`
|
||||
|
||||
**One-Page Checkout Controller Duplication:**
|
||||
- Issue: `override/controllers/front/OrderController.php` (root, 653 lines) and `modules/onepagecheckoutps/public/override/controllers/front/OrderController.php` both exist; PS loads root override only
|
||||
- Files: `override/controllers/front/OrderController.php`, `modules/onepagecheckoutps/public/override/controllers/front/OrderController.php`
|
||||
- Impact: Module override is silently ignored; confusion when updating module
|
||||
- Fix approach: Document that root override is authoritative; remove or flag module copy
|
||||
|
||||
## Known Bugs
|
||||
|
||||
**Die() Calls in Empikmarketplace:**
|
||||
- Symptoms: Admin pages may crash without user-friendly error
|
||||
- Files: `modules/empikmarketplace/controllers/admin/AdminEmpikOffersController.php`, `modules/empikmarketplace/controllers/admin/AdminEmpikProductsController.php`, `modules/empikmarketplace/controllers/front/cron.php`
|
||||
- Workaround: None — admin must retry operation
|
||||
- Root cause: Missing try/catch and error recovery in module controllers
|
||||
|
||||
**Dev Mode IP Hardcoded:**
|
||||
- Symptoms: Debug mode silently enabled for traffic from specific IP
|
||||
- Files: `config/defines.inc.php` (line 28)
|
||||
- Risk: Exposes debug info if that IP is compromised or reused
|
||||
- Fix: Move dev detection to environment variable or remove entirely
|
||||
|
||||
## Security Considerations
|
||||
|
||||
**Dispatcher URL Parsing — Potential Injection:**
|
||||
- Risk: Regex in `override/classes/Dispatcher.php` (line 69) parses raw `$_GET` without sanitization
|
||||
- Files: `override/classes/Dispatcher.php`
|
||||
- Current mitigation: PrestaShop built-in URL sanitization may catch most cases
|
||||
- Recommendations: Audit regex patterns, validate extracted values before use
|
||||
|
||||
**Admin Path Obfuscation Only:**
|
||||
- Risk: `admin658c34/` relies on obscurity alone (no 2FA, IP restriction visible)
|
||||
- Files: `admin658c34/`
|
||||
- Current mitigation: Randomized folder name
|
||||
- Recommendations: Enable 2FA if supported, IP-restrict admin if hosting allows
|
||||
|
||||
**Order Source Enum Hardcoded:**
|
||||
- Risk: `order_source` enum in `ps_orders` only allows ('Allegro', 'Sklep int.', 'Telefonicznie') — new order sources require DB migration
|
||||
- Files: `modules/AddOrderExtraFields/AddOrderExtraFields.php`
|
||||
- Recommendations: Consider VARCHAR with application-level validation instead of enum
|
||||
|
||||
## Performance Bottlenecks
|
||||
|
||||
**Empikmarketplace Admin Views:**
|
||||
- Problem: Module overrides admin product catalog list views with custom Twig templates
|
||||
- Files: `modules/empikmarketplace/views/PrestaShop/Admin/Product/CatalogPage/Lists/list.html.twig`, `products_table.html.twig`
|
||||
- Impact: Admin product list may be slower or behave unexpectedly after empikmarketplace updates
|
||||
- Improvement: Keep module updated; test after each module upgrade
|
||||
|
||||
**No Indexes on Custom Feature Tab:**
|
||||
- Problem: `ps_custom_feature_tab` has no index on `id_feature` or `id_feature_value`
|
||||
- Files: `modules/customfeaturetab/customfeaturetab.php` (table creation SQL)
|
||||
- Impact: Slow queries when many products loaded (full table scan per product)
|
||||
- Fix: `ALTER TABLE ps_custom_feature_tab ADD INDEX (id_feature, id_feature_value)`
|
||||
|
||||
## Fragile Areas
|
||||
|
||||
**Override Load Order:**
|
||||
- Files: All files in `override/classes/` and `override/controllers/`
|
||||
- Why fragile: PrestaShop loads overrides alphabetically; installing new modules with overlapping overrides can silently fail or corrupt class index
|
||||
- Safe modification: Always clear `var/cache/*/class_index.php` after adding/modifying overrides
|
||||
- Test coverage: None
|
||||
|
||||
**Hook System Intercept (cookiesplus):**
|
||||
- Files: `override/classes/Hook.php`
|
||||
- Why fragile: cookiesplus intercepts ALL hook execution for GDPR consent; if module corrupts its config, hooks may silently fail site-wide
|
||||
- Common failure: Module misconfiguration blocks legitimate module output
|
||||
- Safe modification: Test in staging if possible before enabling
|
||||
|
||||
## Scaling Limits
|
||||
|
||||
**PrestaShop 1.7.x End of Life:**
|
||||
- Current capacity: Working for current traffic
|
||||
- Risk: No official security patches available for 1.7.x
|
||||
- Impact: Accumulating unpatched vulnerabilities in core and 45+ vendor dependencies
|
||||
- Scaling path: Plan migration to PrestaShop 8.x (significant effort)
|
||||
|
||||
**No CI/CD — Manual FTP Deployment:**
|
||||
- Current: Changes deployed manually via FTP from VSCode
|
||||
- Risk: Human error, no rollback mechanism, no pre-deploy validation
|
||||
- Impact: Broken deployments require manual FTP rollback
|
||||
|
||||
## Dependencies at Risk
|
||||
|
||||
**PrestaShop 1.7.x:**
|
||||
- Risk: End of life — no more security fixes
|
||||
- Impact: All custom modules, theme, overrides would need migration
|
||||
- Migration plan: PrestaShop 8.x upgrade (breaking changes in module APIs)
|
||||
|
||||
**x13allegro (Allegro API):**
|
||||
- Risk: Allegro REST API versioning — module may need updates when API changes
|
||||
- Impact: Allegro order sync breaks if module not updated
|
||||
- Migration plan: Keep module updated; monitor x13.pl module updates
|
||||
|
||||
**onepagecheckoutps (v1.0.1):**
|
||||
- Risk: Old version, complex OrderController override (653 lines)
|
||||
- Impact: Checkout flow breaks on PS updates
|
||||
- Migration plan: Test and update before any PS core updates
|
||||
|
||||
## Missing Critical Features
|
||||
|
||||
**No Automated Testing:**
|
||||
- Problem: Zero automated tests for custom modules
|
||||
- Blocks: Confidence in refactoring, PS upgrade path verification
|
||||
- Implementation complexity: Medium (PHPUnit setup per module)
|
||||
|
||||
**No Staging Environment:**
|
||||
- Problem: Changes go directly to production
|
||||
- Current workaround: Test manually in production during low-traffic hours
|
||||
- Blocks: Safe testing of marketplace integrations, checkout changes
|
||||
- Implementation complexity: Medium (duplicate hosting setup)
|
||||
|
||||
**No Rollback Mechanism:**
|
||||
- Problem: No automated rollback for failed deployments
|
||||
- Current workaround: Restore via FTP from backup
|
||||
- Blocks: Confidence in deploying risky changes
|
||||
|
||||
## Database Design Issues
|
||||
|
||||
**utf8 vs utf8mb4:**
|
||||
- Files: `modules/customfeaturetab/customfeaturetab.php` (CREATE TABLE uses `utf8`)
|
||||
- Risk: Cannot store 4-byte Unicode characters (some emoji, rare CJK)
|
||||
- Fix: Migrate custom tables to `utf8mb4` charset
|
||||
|
||||
---
|
||||
|
||||
*Concerns audit: 2026-04-27*
|
||||
*Update as issues are fixed or new ones discovered*
|
||||
Reference in New Issue
Block a user