Files
interblue.pl/.paul/codebase/concerns.md
Jacek Pyziak b1e8bb3d12 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>
2026-04-27 12:41:05 +02:00

147 lines
7.1 KiB
Markdown

# 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*