Shop Project - Documentation
Changelog: Version 0.1 – The First Milestone
A few months ago, the very first prototype went online. A lot has happened since then – code has grown, structures have taken shape, and an idea is slowly becoming a real system.
This documentation is not just for me, but also for the case that someday I might no longer be working alone – or external support joins in. It should provide a quick, efficient insight without having to fight through a thousand question marks.
📦 Current status: Core system running | 👥 Roles: Guest, User, Admin | 🌍 Multilingual: DE/EN/FR/JP | 🏗️ Next steps: Finalize article management
At a glance: What version 0.1 can already do
Before we dive into the details – here's the big picture. The shop is designed as an MVP: It works, is multilingual, and you can list and browse articles. The homework (validation, security, structure) is done, now it's time for fine-tuning.
Current (June 2026) core features at a glance:
- 🏗️ Core System: MVC architecture with router, dispatcher, and app lifecycle
- 🔐 Security & Access: Role-based system (Guest, User, Admin) with session management
- 🌍 Multilingual: Label system with German/English, extensible
- 🧭 Navigation: Complex menu system with multilingual support
- 📦 Marketplace: Create articles, list articles, detail views
- 👤 User management: Registration, login, email confirmation (PHPMailer)
- 🗄️ Database: 8 stable core areas (Users, Products, Shipping, Support, Tracking, etc.)
💡 Why this changelog? So that I (and ev. others) can understand what happened when – and why certain decisions were made. Transparency builds trust, even in your own code.
🗺️ Roadmap: On the roadmap, I have just completed stage 0.1.7. However, the project already has a large scope, as many background tasks were required.
1. Changelog of this project (Version 0.1 Prototype)
New: Web documentation
Implementation: Since I can no longer keep track of all the files and lines of code, I decided to create a web documentation. Here, all important information, decisions, and changes are recorded – so that I (and possibly others) can always have a clear overview.
Modular JS stream path
New: Modular JS stream path
Implementation: The new primary path is active (`dom.js` + `stream.js` + `ajax.php?action=streamModule`). Page logic is loaded modularly via `app/JS/modules/`.
Changed: Unified front-back orchestration
Implementation: Route manifest, module lifecycle (`init/mount/cleanup`), and error paths were consolidated into one consistent flow.
Deprecated: Legacy JS generator path
Description: The previous adapter path via `dom.php`/`main.js.php` was kept as a legacy path during migration and then fully replaced.
Removed: Old JS structure in production path
Description: `public/dom.php`, `app/JS/main.js.php`, `app/JS/base.js.php`, and the legacy folder `app/JS/page/` were removed from the production refactor path.
Fixed: Unstable SPA transitions
Description: Navigation, CSS synchronization, and module cleanup were stabilized so route transitions run consistently without full reloads.
Security: Unified endpoint gates and logging
Description: Method checks, CSRF rules, role gates, and centralized client logging were implemented consistently in the API core.
Coding convention + optimization stages
Completed: Coding convention cycles 01-14
Implementation: The areas Config, Public, app/model, app/service, app/control, app/helper, app/view, docweb, app/core, app/security, app/bootstrap, app/JS, app/css, and dev were standardized step by step. Focus: clear responsibilities, consistent naming, unified comment rules, and crash-first behavior without silent fallback paths.
Completed: Stage 15 (public/dev untangling)
Implementation: The dev entry flow was consolidated into a clean 4-endpoint structure. Goal: a robust, understandable developer path without legacy cross-couplings.
Completed: Stage 16 (performance + monitoring)
Implementation: Navigation and SPA rendering were stabilized (less flicker, consistent CSS synchronization, hard timeout limits). At the same time, reproducible metrics and monitoring hooks were established.
Completed: Stage 17 (logging restructure backend/frontend)
Implementation: Logging was split into three clear levels: error (system/programming failures), trace (notable anomalies/flow signals), and debug (local frontend debugging). Frontend debug stays local, while trace/error are logged centrally in the backend.
Completed: Roadmap 0.1 (article lifecycle)
Implementation: The last open 0.1 points are completed. Own articles can now be edited in marketplace and detail view, and deleted with a confirmation dialog. The editor uses the existing edit mode, and end-to-end checks for edit/delete are successfully documented.
Status: Version 0.1 is technically and documentationally complete within the defined scope. The next step is feature expansion from 0.2 onward with new user and trading functions.
Roadmap 0.1 completed: Article lifecycle
Added: Owner actions in marketplace and detail view
Implementation: Authorized users now receive functional edit and delete actions for their own articles. The detail view uses the same action block as marketplace tiles; deletion requires confirmation.
Changed: Article editing through the existing editor
Implementation: Editing starts through `edit_id`; the existing editor is prefilled with the article data. The backend handler validates ownership and input, saves the metadata, and then returns consistently to the article list.
Changed: Article deletion through one explicit controller path
Implementation: The delete form submits via POST to the `article_editor` path, which owns the central processing. Ownership, target ID, and image cleanup are checked before the database delete; the return route is controlled through the allowed target node.
Fixed: Validation, ownership checks, and language-ID error
Security and stability: Edit/delete use centralized CSRF and ownership checks. A fatal error caused by passing a language key instead of a numeric language ID was fixed; placeholder links and inconsistent special paths were removed.
Verified: End-to-end acceptance of the article lifecycle
Evidence: Cancel leaves an article unchanged; confirmed deletion removes it and updates the grid. Editing saves a visible change, was verified in the marketplace, and was then restored to its original value. Lint, error, and navigation checks completed without new errors or regressions.
Status: Version 0.1 completed within the defined scope
The open 0.1 items "Edit article" and "Delete article" are technically and documentationally complete. Remaining expansion topics belong to versions from 0.2 onward and do not block this milestone.
Completion: Stabilization, security, and data integrity
Completed: Shell, content, and item separation
Implementation: The fragmented loading process is active in production. `index.php` owns the initial load and shell, `content.php` delivers navigation content, and `item.php` handles small interactions with clear JSON contracts. SPA navigation runs without an additional document reload; modules activate only after content has loaded successfully.
Completed: Edit and delete articles
Implementation: Owners can edit their own articles in the marketplace and detail view or delete them with confirmation. Ownership checks, validation, redirects, image ordering, and physical image cleanup were verified end to end.
Fixed: Category CRUD aligned with the active schema
Implementation: The category editor now uses the real table and column structures. Parent relations are maintained through `tb_cat_hierarchy`, names are managed through the central label system, and deletes are visibly blocked when children or assigned articles exist.
Fixed: User deletion with article images
Implementation: Article image files are removed before user deletion and their dependent rows are included in the deletion cascade. Complete deletion of a test user with an article and image was verified without foreign-key errors.
Security: Unity and negative tests completed
Evidence: CSRF, role, foreign-object, ID, upload, token, rate-limit, and double-submit cases were tested with real HTTP or database checks. Session cookies use `HttpOnly` and `SameSite=Lax`; test data and uploads were cleaned up after the runs.
Open: Production SMTP verification
Status: Local mail delivery cannot be completed because the local SMTP configuration is intentionally empty. The real delivery test with production credentials and a test recipient remains a separate host check.