moved website outside of panel folder

.github/agent.md

@@ -7,19 +7,19 @@
 - Use the GSP/WDS/GSW branding across UI, docs, and comments; when heritage context matters add: “GSP is a heavily customized fork of OGP maintained by WDS.”
 - Keep `bootstrap/` current: Ubuntu 24.04 panel + agent installers, Windows Server 2019 (Cygwin) agent installer + service wrapper, and the optional `docker/compose.yml` dev stack. All scripts must be idempotent, echo next steps, and document verify/rollback procedures in their README files.
 - Author and maintain admin-only docs in `WDS_Website/content/projects/gsp.md` and `content/docs/gsp/*` (front-matter + the **Admin Documentation** banner). Cross-link these guides from panel features that need deep dives.
-- Refresh user-facing help in `modules/faq/` (RSS + UI) so the seven core topics—panel basics, file browser, Adminer/MySQL, FTP/SFTP, task scheduler, sub-users, and support—link to the latest WDS admin docs.
+- Refresh user-facing help in `Panel/modules/faq/` (RSS + UI) so the seven core topics—panel basics, file browser, Adminer/MySQL, FTP/SFTP, task scheduler, sub-users, and support—link to the latest WDS admin docs.
 - Track cross-repo progress in `WDS-Team/docs/wds-gsp-migration.md` and update `.github/copilot-instructions.md` + `.github/agent.md` in lockstep whenever these guardrails change.
 - Enforce the shared security settings everywhere: SSH port 12322, MySQL accounts `localuser@localhost` and `remoteuser@<reporter-ip>`, shared secret stored at `/home/gameserver/tools/.password`, and mention optional DR/monitoring tools in admin docs when relevant.
 
 ## Deployment model & paths
-- `modules/billing/` houses the public storefront. Those files are always present inside the panel repo and get deployed either (a) as the root of a dedicated virtual host or (b) through the panel module loader (`home.php?m=billing`).
+- `Website/` houses the public storefront. Those files live at repo root alongside `Panel/` and are deployed as the root of a dedicated virtual host.
-- Because the storefront and the control panel live in the same tree, you may include panel helpers when needed. Use the dedicated bridge include (`modules/billing/includes/panel_bridge.php`) instead of sprinkling ad-hoc `../../includes/...` calls.
+- Because the storefront and the control panel live in the same repo, you may include panel helpers when needed. Use the dedicated bridge include (`Website/includes/panel_bridge.php`) instead of sprinkling ad-hoc `../../Panel/includes/...` calls.
-- We keep Apache/Nginx vhosts pointed at `modules/billing/`, so every storefront URL must look root-relative (see critical section below). Never expose `/modules/billing` in any URL sent to a browser or external service.
+- We keep Apache/Nginx vhosts pointed at `Website/`, so every storefront URL must look root-relative (see critical section below). All user-facing URLs must be root-relative.
 - Before touching billing logic or module wiring, skim `.github/module-map.md` to remember how the panel modules depend on each other.
 
-## CRITICAL: Website file paths and URLs (modules/billing)
+## CRITICAL: Website file paths and URLs (Website/)
-- **The billing website files in `modules/billing/` are deployed at the WEBSITE ROOT when live.**
+- **The billing website files in `Website/` are deployed at the WEBSITE ROOT when live.**
-- **Never output `/modules/billing/` in any link, redirect, script tag, or webhook URL. All user-facing URLs must be root-relative**, e.g. `/payment_success.php`, `/cart.php`.
+- **All user-facing URLs must be root-relative**, e.g. `/payment_success.php`, `/cart.php`.
 - Continue to use root-relative URLs inside HTML/JS and when building PayPal return/cancel links. The deployment tooling rewrites the document root; hardcoding `/modules/billing` breaks both standalone hosting and module embedding.
 
 ### Examples of CORRECT usage
@@ -41,14 +41,14 @@ header('Location: /modules/billing/cart.php');
 - Server-side includes may use absolute filesystem paths, but route those through the bridge helpers when panel context is required:
   - ✅ `require_once(__DIR__ . '/includes/config.inc.php');`
   - ✅ `require_once(__DIR__ . '/includes/panel_bridge.php');`
-- Avoid copy/pasting panel bootstrap code; lean on the helpers already shipped inside `modules/billing/includes/`.
+- Avoid copy/pasting panel bootstrap code; lean on the helpers already shipped inside `Website/includes/`.
 
 ## 1) What to read first
 - `.github/module-map.md` – living diagram of how the panel, billing site, daemons, and cron jobs talk to each other.
-- `modules/billing/` – storefront runtime, payment handlers, provisioning bridge.
+- `Website/` – storefront runtime, payment handlers, provisioning bridge.
-- `modules/config_games/server_configs/` – authoritative XML metadata for every supported game.
+- `Panel/modules/config_games/server_configs/` – authoritative XML metadata for every supported game.
-- `modules/` – control-panel modules (billing runs here too when embedded).
+- `Panel/modules/` – control-panel modules.
-- `includes/` & `ogp_api.php` – database layer, shared helpers, remote agent operations.
+- `Panel/includes/` & `Panel/ogp_api.php` – database layer, shared helpers, remote agent operations.
 
 ## 2) Planning mode (default)
 While scoping multi-file work, do **not** emit PHP/SQL/XML or run shell commands unless a maintainer explicitly says “Generate code now.” Plans should cover:
@@ -59,18 +59,18 @@ While scoping multi-file work, do **not** emit PHP/SQL/XML or run shell commands
 ## 3) Scope & principles
 - **Single session across panel + storefront.** Every billing page must call `session_name('opengamepanel_web')` before `session_start()`. Always keep `$_SESSION['user_id']`, `$_SESSION['users_login']`, `$_SESSION['users_group']`, and `$_SESSION['website_user_id']` in sync so that logging into either surface signs the visitor into both.
 - **Auth reuse.** Preferred order when verifying credentials: `users_pass_hash` (modern hash) → legacy `users_passwd` (MD5). Upgrading to a modern hash is allowed so long as panel logins keep working.
-- **Bridge for panel helpers.** Use `modules/billing/includes/panel_bridge.php` to load panel classes (`OGPDatabase`, `OGPRemoteLibrary`, XML parsers) when the storefront needs to provision servers or read panel-only metadata. Do not reinvent ad-hoc copies of panel logic.
+- **Bridge for panel helpers.** Use `Website/includes/panel_bridge.php` to load panel classes (`OGPDatabase`, `OGPRemoteLibrary`, XML parsers) when the storefront needs to provision servers or read panel-only metadata. Do not reinvent ad-hoc copies of panel logic.
-- **Storefront runtime.** Public pages continue to use mysqli with credentials from `modules/billing/includes/config.inc.php`. Provisioning steps may request an `OGPDatabase` handle from the bridge.
+- **Storefront runtime.** Public pages continue to use mysqli with credentials from `Website/includes/config.inc.php`. Provisioning steps may request an `OGPDatabase` handle from the bridge.
-- **Provisioning pipeline.** Always funnel server creation or renewals through the shared provisioner (`modules/billing/includes/provisioner.php`). This helper wraps the old `create_servers.php` logic and ensures PayPal captures, cron jobs, and panel clicks all follow the same code path.
+- **Provisioning pipeline.** Always funnel server creation or renewals through the shared provisioner (`Website/includes/provisioner.php`). This helper wraps the old `create_servers.php` logic and ensures PayPal captures, cron jobs, and panel clicks all follow the same code path.
-- **Catalog = XML.** Never hardcode game metadata. Parse `modules/config_games/server_configs/*.xml` at runtime; new XMLs must show up automatically.
+- **Catalog = XML.** Never hardcode game metadata. Parse `Panel/modules/config_games/server_configs/*.xml` at runtime; new XMLs must show up automatically.
 - **Regions/Nodes = live DB.** Pull nodes/locations from the panel DB (`gsp_remote_servers`, etc.). Respect admin enable/disable flags and never mirror node lists into flat files.
-- **Game XML wiki parity.** We ship a PHP-rendered version of https://github.com/OpenGamePanel/OGP-Website/wiki/XML-Notes inside `modules/billing/` (linked from the storefront admin area). Keep it updated so maintainers can edit XMLs without leaving the repo.
+- **Game XML wiki parity.** We ship a PHP-rendered version of https://github.com/OpenGamePanel/OGP-Website/wiki/XML-Notes inside `Website/` (linked from the storefront admin area). Keep it updated so maintainers can edit XMLs without leaving the repo.
 
 ## 4) Functional requirements
 ### 4.1 Catalog (from XML)
-- Parse every XML under `modules/config_games/server_configs/`.
+- Parse every XML under `Panel/modules/config_games/server_configs/`.
 - Normalize: game key, display name, install/update commands, default ports, mod metadata.
-- XML pages (`modules/billing/docs.php` and the new XML-notes mirror) must stay in sync so AI-powered edits can cross-reference expectations.
+- XML pages (`Website/docs.php` and the new XML-notes mirror) must stay in sync so AI-powered edits can cross-reference expectations.
 
 ### 4.2 Authentication & sessions
 - Website registration must create/maintain panel users. Set both the legacy `users_passwd` and the modern hash column.
@@ -81,24 +81,24 @@ While scoping multi-file work, do **not** emit PHP/SQL/XML or run shell commands
 - Flow: add to cart → invoices (`billing_invoices`) → PayPal order (`api/create_order.php`) → capture (`api/capture_order.php`) → immediately hand off to `BillingProvisioner`.
 - Mark invoices paid **only** after verifying PayPal response/webhook. Support multiple servers per payment: loop through every paid invoice and either create a new order or extend an existing service.
 - For renewals, extend `end_date` from its current value and keep status at `installed`. For new services set status `installing`, invoke the provisioner, then switch to `installed` on success.
-- Provisioner is responsible for calling `modules/billing/create_servers.php` logic, adding homes, assigning ports, enabling FTP, and logging/notifications. Never bypass it.
+- Provisioner is responsible for calling `Website/create_servers.php` logic, adding homes, assigning ports, enabling FTP, and logging/notifications. Never bypass it.
 
 ### 4.4 Regions/Nodes (multi-remote)
 - `remote_servers` and `remote_server_ips` tables remain the source for available locations. Admin tooling (`adminserverlist.php`) must let staff toggle availability and restrict services per location.
 - When a node is globally disabled it must disappear (or show as unavailable) in ordering and admin tools.
 
 ### 4.5 Billing automation (website-side)
-- Cron/workers under `modules/billing/cron-shop.php` still suspend/delete expired services. Renewals triggered via PayPal must update `billing_orders.status` and `end_date` consistently so cron jobs can pick up where they expect.
+- Cron/workers under `Website/cron-shop.php` still suspend/delete expired services. Renewals triggered via PayPal must update `billing_orders.status` and `end_date` consistently so cron jobs can pick up where they expect.
-- Keep audit logs in `modules/billing/logs/` whenever automatic provisioning, renewals, refunds, or coupon adjustments happen.
+- Keep audit logs in `Website/logs/` whenever automatic provisioning, renewals, refunds, or coupon adjustments happen.
 
 ## 5) Data model alignment (no DDL during planning)
 - Use panel tables as the source of truth (`gsp_billing_orders`, `gsp_billing_services`, `gsp_billing_invoices`, `gsp_game_mods`, etc.).
 - Multi-remote fields (`remote_server_id`, IP IDs) already exist—never introduce duplicates in the storefront DB.
-- When you truly need schema changes, follow the naming conventions, provide migrations under `modules/billing/*.sql`, and describe the plan first.
+- When you truly need schema changes, follow the naming conventions, provide migrations under `Website/sql/`, and describe the plan first.
 
 ## 6) Coding standards & security
 - Parameterize SQL or escape inputs with mysqli real_escape-string helpers.
-- Harden sessions (regenerate IDs on login, honor `modules/billing/timestamp.txt` for public timestamps).
+- Harden sessions (regenerate IDs on login, honor `Website/timestamp.txt` for public timestamps).
 - CSRF-protect every POST/DELETE-like operation in the storefront admin.
 - Verify PayPal signatures, never trust client-side status.
 - XML parsing: disable external entities, enforce file size limits.
@@ -106,10 +106,10 @@ While scoping multi-file work, do **not** emit PHP/SQL/XML or run shell commands
 - Licensing: leave upstream license headers intact.
 
 ## 7) Validation checklist
-- Read `.github/module-map.md`, `modules/billing/`, panel helpers, and XMLs before proposing architecture changes.
+- Read `.github/module-map.md`, `Website/`, panel helpers, and XMLs before proposing architecture changes.
 - Confirm catalog pages only use XML metadata.
 - Confirm node selectors reflect current DB state (respect enabled flags).
-- Test that logging into either the panel (`index.php`) or storefront (`modules/billing/login.php`) logs you into both.
+- Test that logging into either the panel (`Panel/index.php`) or storefront (`Website/login.php`) logs you into both.
 - PayPal capture should mark invoices paid, create/extend orders, and schedule provisioning instantly. Verify multi-item carts create all services.
 - `BillingProvisioner` must be exercised via PayPal capture, panel module (`create_servers.php`), and any admin “retry” buttons.
 - Documentation admin links must expose the XML-notes PHP mirror and the game docs browsers.
@@ -136,9 +136,9 @@ While scoping multi-file work, do **not** emit PHP/SQL/XML or run shell commands
 
 When making small content or page edits to the website, ensure the following pages display a human-friendly "Last updated" timestamp at the very bottom of the page (visible to site visitors):
 
-- `modules/billing/index.php`
+- `Website/index.php`
-- `index.php` (site root)
+- `Panel/index.php` (panel root)
-- `modules/dashboard/dashboard.php`
+- `Panel/modules/dashboard/dashboard.php`
 
 Requirements:
 - The text must read exactly: "Last updated at YYYY-MM-DD HH:MM:SS" (24-hour time) where the timestamp reflects the deliberate edit time of the page (see acceptance criteria below).
@@ -156,7 +156,7 @@ Testing checklist:
 - If using automated deploys, ensure the deploy process preserves or updates the canonical timestamp source (e.g., touch file, update metadata) so the displayed value is accurate.
 
 Maintainer update requirement:
-- The canonical human-friendly timestamp is stored in `modules/billing/timestamp.txt` and MUST be updated whenever site files or content are edited and deployed.
+- The canonical human-friendly timestamp is stored in `Website/timestamp.txt` and MUST be updated whenever site files or content are edited and deployed.
 - Format and wording: use a single-line plain-text entry such as: "Last Updated at 7:25am on 2025-15-11". This exact text (including capitalization) is what appears in theme footers.
 - Update process: include the `timestamp.txt` change in the same commit/PR as any content change that should alter the "Last Updated" time, or ensure your deployment process updates the file automatically (for example, a post-deploy hook that writes the current deploy time in the agreed format).
 - Rationale: themes are non-PHP files and may not support SSI on all servers; keeping a single canonical plain-text file reduces duplication and avoids server-side includes.

.github/copilot-instructions.md

@@ -7,19 +7,19 @@
 - Use the GSP/WDS/GSW branding across UI, docs, and comments; when heritage context matters add: “GSP is a heavily customized fork of OGP maintained by WDS.”
 - Keep `bootstrap/` current: Ubuntu 24.04 panel + agent installers, Windows Server 2019 (Cygwin) agent installer + service wrapper, and the optional `docker/compose.yml` dev stack. All scripts must be idempotent, echo next steps, and document verify/rollback procedures in their README files.
 - Author and maintain admin-only docs in `WDS_Website/content/projects/gsp.md` and `content/docs/gsp/*` (front-matter + the **Admin Documentation** banner). Cross-link these guides from panel features that need deep dives.
-- Refresh user-facing help in `modules/faq/` (RSS + UI) so the seven core topics—panel basics, file browser, Adminer/MySQL, FTP/SFTP, task scheduler, sub-users, and support—link to the latest WDS admin docs.
+- Refresh user-facing help in `Panel/modules/faq/` (RSS + UI) so the seven core topics—panel basics, file browser, Adminer/MySQL, FTP/SFTP, task scheduler, sub-users, and support—link to the latest WDS admin docs.
 - Track cross-repo progress in `WDS-Team/docs/wds-gsp-migration.md` and update `.github/copilot-instructions.md` + `.github/agent.md` in lockstep whenever these guardrails change.
 - Enforce the shared security settings everywhere: SSH port 12322, MySQL accounts `localuser@localhost` and `remoteuser@<reporter-ip>`, shared secret stored at `/home/gameserver/tools/.password`, and mention optional DR/monitoring tools in admin docs when relevant.
 
 ## Deployment model & paths
-- `modules/billing/` houses the public storefront. Those files are always present inside the panel repo and get deployed either (a) as the root of a dedicated virtual host or (b) through the panel module loader (`home.php?m=billing`).
+- `Website/` houses the public storefront. Those files live at repo root alongside `Panel/` and are deployed as the root of a dedicated virtual host.
-- Because the storefront and the control panel live in the same tree, you may include panel helpers when needed. Use the dedicated bridge include (`modules/billing/includes/panel_bridge.php`) instead of sprinkling ad-hoc `../../includes/...` calls.
+- Because the storefront and the control panel live in the same repo, you may include panel helpers when needed. Use the dedicated bridge include (`Website/includes/panel_bridge.php`) instead of sprinkling ad-hoc `../../Panel/includes/...` calls.
-- We keep Apache/Nginx vhosts pointed at `modules/billing/`, so every storefront URL must look root-relative (see critical section below). Never expose `/modules/billing` in any URL sent to a browser or external service.
+- We keep Apache/Nginx vhosts pointed at `Website/`, so every storefront URL must look root-relative (see critical section below). All user-facing URLs must be root-relative.
 - Before touching billing logic or module wiring, skim `.github/module-map.md` to remember how the panel modules depend on each other.
 
-## CRITICAL: Website file paths and URLs (modules/billing)
+## CRITICAL: Website file paths and URLs (Website/)
-- **The billing website files in `modules/billing/` are deployed at the WEBSITE ROOT when live.**
+- **The billing website files in `Website/` are deployed at the WEBSITE ROOT when live.**
-- **Never output `/modules/billing/` in any link, redirect, script tag, or webhook URL. All user-facing URLs must be root-relative**, e.g. `/payment_success.php`, `/cart.php`.
+- **All user-facing URLs must be root-relative**, e.g. `/payment_success.php`, `/cart.php`.
 - Continue to use root-relative URLs inside HTML/JS and when building PayPal return/cancel links. The deployment tooling rewrites the document root; hardcoding `/modules/billing` breaks both standalone hosting and module embedding.
 
 ### Examples of CORRECT usage
@@ -41,14 +41,14 @@ header('Location: /modules/billing/cart.php');
 - Server-side includes may use absolute filesystem paths, but route those through the bridge helpers when panel context is required:
   - ✅ `require_once(__DIR__ . '/includes/config.inc.php');`
   - ✅ `require_once(__DIR__ . '/includes/panel_bridge.php');`
-- Avoid copy/pasting panel bootstrap code; lean on the helpers already shipped inside `modules/billing/includes/`.
+- Avoid copy/pasting panel bootstrap code; lean on the helpers already shipped inside `Website/includes/`.
 
 ## 1) What to read first
 - `.github/module-map.md` – living diagram of how the panel, billing site, daemons, and cron jobs talk to each other.
-- `modules/billing/` – storefront runtime, payment handlers, provisioning bridge.
+- `Website/` – storefront runtime, payment handlers, provisioning bridge.
-- `modules/config_games/server_configs/` – authoritative XML metadata for every supported game.
+- `Panel/modules/config_games/server_configs/` – authoritative XML metadata for every supported game.
-- `modules/` – control-panel modules (billing runs here too when embedded).
+- `Panel/modules/` – control-panel modules.
-- `includes/` & `ogp_api.php` – database layer, shared helpers, remote agent operations.
+- `Panel/includes/` & `Panel/ogp_api.php` – database layer, shared helpers, remote agent operations.
 
 ## 2) Planning mode (default)
 While scoping multi-file work, do **not** emit PHP/SQL/XML or run shell commands unless a maintainer explicitly says “Generate code now.” Plans should cover:
@@ -59,18 +59,18 @@ While scoping multi-file work, do **not** emit PHP/SQL/XML or run shell commands
 ## 3) Scope & principles
 - **Single session across panel + storefront.** Every billing page must call `session_name('opengamepanel_web')` before `session_start()`. Always keep `$_SESSION['user_id']`, `$_SESSION['users_login']`, `$_SESSION['users_group']`, and `$_SESSION['website_user_id']` in sync so that logging into either surface signs the visitor into both.
 - **Auth reuse.** Preferred order when verifying credentials: `users_pass_hash` (modern hash) → legacy `users_passwd` (MD5). Upgrading to a modern hash is allowed so long as panel logins keep working.
-- **Bridge for panel helpers.** Use `modules/billing/includes/panel_bridge.php` to load panel classes (`OGPDatabase`, `OGPRemoteLibrary`, XML parsers) when the storefront needs to provision servers or read panel-only metadata. Do not reinvent ad-hoc copies of panel logic.
+- **Bridge for panel helpers.** Use `Website/includes/panel_bridge.php` to load panel classes (`OGPDatabase`, `OGPRemoteLibrary`, XML parsers) when the storefront needs to provision servers or read panel-only metadata. Do not reinvent ad-hoc copies of panel logic.
-- **Storefront runtime.** Public pages continue to use mysqli with credentials from `modules/billing/includes/config.inc.php`. Provisioning steps may request an `OGPDatabase` handle from the bridge.
+- **Storefront runtime.** Public pages continue to use mysqli with credentials from `Website/includes/config.inc.php`. Provisioning steps may request an `OGPDatabase` handle from the bridge.
-- **Provisioning pipeline.** Always funnel server creation or renewals through the shared provisioner (`modules/billing/includes/provisioner.php`). This helper wraps the old `create_servers.php` logic and ensures PayPal captures, cron jobs, and panel clicks all follow the same code path.
+- **Provisioning pipeline.** Always funnel server creation or renewals through the shared provisioner (`Website/includes/provisioner.php`). This helper wraps the old `create_servers.php` logic and ensures PayPal captures, cron jobs, and panel clicks all follow the same code path.
-- **Catalog = XML.** Never hardcode game metadata. Parse `modules/config_games/server_configs/*.xml` at runtime; new XMLs must show up automatically.
+- **Catalog = XML.** Never hardcode game metadata. Parse `Panel/modules/config_games/server_configs/*.xml` at runtime; new XMLs must show up automatically.
 - **Regions/Nodes = live DB.** Pull nodes/locations from the panel DB (`gsp_remote_servers`, etc.). Respect admin enable/disable flags and never mirror node lists into flat files.
-- **Game XML wiki parity.** We ship a PHP-rendered version of https://github.com/OpenGamePanel/OGP-Website/wiki/XML-Notes inside `modules/billing/` (linked from the storefront admin area). Keep it updated so maintainers can edit XMLs without leaving the repo.
+- **Game XML wiki parity.** We ship a PHP-rendered version of https://github.com/OpenGamePanel/OGP-Website/wiki/XML-Notes inside `Website/` (linked from the storefront admin area). Keep it updated so maintainers can edit XMLs without leaving the repo.
 
 ## 4) Functional requirements
 ### 4.1 Catalog (from XML)
-- Parse every XML under `modules/config_games/server_configs/`.
+- Parse every XML under `Panel/modules/config_games/server_configs/`.
 - Normalize: game key, display name, install/update commands, default ports, mod metadata.
-- XML pages (`modules/billing/docs.php` and the new XML-notes mirror) must stay in sync so AI-powered edits can cross-reference expectations.
+- XML pages (`Website/docs.php` and the new XML-notes mirror) must stay in sync so AI-powered edits can cross-reference expectations.
 
 ### 4.2 Authentication & sessions
 - Website registration must create/maintain panel users. Set both the legacy `users_passwd` and the modern hash column.
@@ -81,24 +81,24 @@ While scoping multi-file work, do **not** emit PHP/SQL/XML or run shell commands
 - Flow: add to cart → invoices (`billing_invoices`) → PayPal order (`api/create_order.php`) → capture (`api/capture_order.php`) → immediately hand off to `BillingProvisioner`.
 - Mark invoices paid **only** after verifying PayPal response/webhook. Support multiple servers per payment: loop through every paid invoice and either create a new order or extend an existing service.
 - For renewals, extend `end_date` from its current value and keep status at `installed`. For new services set status `installing`, invoke the provisioner, then switch to `installed` on success.
-- Provisioner is responsible for calling `modules/billing/create_servers.php` logic, adding homes, assigning ports, enabling FTP, and logging/notifications. Never bypass it.
+- Provisioner is responsible for calling `Website/create_servers.php` logic, adding homes, assigning ports, enabling FTP, and logging/notifications. Never bypass it.
 
 ### 4.4 Regions/Nodes (multi-remote)
 - `remote_servers` and `remote_server_ips` tables remain the source for available locations. Admin tooling (`adminserverlist.php`) must let staff toggle availability and restrict services per location.
 - When a node is globally disabled it must disappear (or show as unavailable) in ordering and admin tools.
 
 ### 4.5 Billing automation (website-side)
-- Cron/workers under `modules/billing/cron-shop.php` still suspend/delete expired services. Renewals triggered via PayPal must update `billing_orders.status` and `end_date` consistently so cron jobs can pick up where they expect.
+- Cron/workers under `Website/cron-shop.php` still suspend/delete expired services. Renewals triggered via PayPal must update `billing_orders.status` and `end_date` consistently so cron jobs can pick up where they expect.
-- Keep audit logs in `modules/billing/logs/` whenever automatic provisioning, renewals, refunds, or coupon adjustments happen.
+- Keep audit logs in `Website/logs/` whenever automatic provisioning, renewals, refunds, or coupon adjustments happen.
 
 ## 5) Data model alignment (no DDL during planning)
 - Use panel tables as the source of truth (`gsp_billing_orders`, `gsp_billing_services`, `gsp_billing_invoices`, `gsp_game_mods`, etc.).
 - Multi-remote fields (`remote_server_id`, IP IDs) already exist—never introduce duplicates in the storefront DB.
-- When you truly need schema changes, follow the naming conventions, provide migrations under `modules/billing/*.sql`, and describe the plan first.
+- When you truly need schema changes, follow the naming conventions, provide migrations under `Website/sql/`, and describe the plan first.
 
 ## 6) Coding standards & security
 - Parameterize SQL or escape inputs with mysqli real_escape-string helpers.
-- Harden sessions (regenerate IDs on login, honor `modules/billing/timestamp.txt` for public timestamps).
+- Harden sessions (regenerate IDs on login, honor `Website/timestamp.txt` for public timestamps).
 - CSRF-protect every POST/DELETE-like operation in the storefront admin.
 - Verify PayPal signatures, never trust client-side status.
 - XML parsing: disable external entities, enforce file size limits.
@@ -106,10 +106,10 @@ While scoping multi-file work, do **not** emit PHP/SQL/XML or run shell commands
 - Licensing: leave upstream license headers intact.
 
 ## 7) Validation checklist
-- Read `.github/module-map.md`, `modules/billing/`, panel helpers, and XMLs before proposing architecture changes.
+- Read `.github/module-map.md`, `Website/`, panel helpers, and XMLs before proposing architecture changes.
 - Confirm catalog pages only use XML metadata.
 - Confirm node selectors reflect current DB state (respect enabled flags).
-- Test that logging into either the panel (`index.php`) or storefront (`modules/billing/login.php`) logs you into both.
+- Test that logging into either the panel (`Panel/index.php`) or storefront (`Website/login.php`) logs you into both.
 - PayPal capture should mark invoices paid, create/extend orders, and schedule provisioning instantly. Verify multi-item carts create all services.
 - `BillingProvisioner` must be exercised via PayPal capture, panel module (`create_servers.php`), and any admin “retry” buttons.
 - Documentation admin links must expose the XML-notes PHP mirror and the game docs browsers.
@@ -136,9 +136,9 @@ While scoping multi-file work, do **not** emit PHP/SQL/XML or run shell commands
 
 When making small content or page edits to the website, ensure the following pages display a human-friendly "Last updated" timestamp at the very bottom of the page (visible to site visitors):
 
-- `modules/billing/index.php`
+- `Website/index.php`
-- `index.php` (site root)
+- `Panel/index.php` (panel root)
-- `modules/dashboard/dashboard.php`
+- `Panel/modules/dashboard/dashboard.php`
 
 Requirements:
 - The text must read exactly: "Last updated at YYYY-MM-DD HH:MM:SS" (24-hour time) where the timestamp reflects the deliberate edit time of the page (see acceptance criteria below).
@@ -156,7 +156,7 @@ Testing checklist:
 - If using automated deploys, ensure the deploy process preserves or updates the canonical timestamp source (e.g., touch file, update metadata) so the displayed value is accurate.
 
 Maintainer update requirement:
-- The canonical human-friendly timestamp is stored in `modules/billing/timestamp.txt` and MUST be updated whenever site files or content are edited and deployed.
+- The canonical human-friendly timestamp is stored in `Website/timestamp.txt` and MUST be updated whenever site files or content are edited and deployed.
 - Format and wording: use a single-line plain-text entry such as: "Last Updated at 7:25am on 2025-15-11". This exact text (including capitalization) is what appears in theme footers.
 - Update process: include the `timestamp.txt` change in the same commit/PR as any content change that should alter the "Last Updated" time, or ensure your deployment process updates the file automatically (for example, a post-deploy hook that writes the current deploy time in the agreed format).
 - Rationale: themes are non-PHP files and may not support SSI on all servers; keeping a single canonical plain-text file reduces duplication and avoids server-side includes.

.github/module-map.md

@@ -6,32 +6,32 @@ This file captures how the control panel, storefront, agents, and helper scripts
 
 | Area | Key files | Responsibilities | Downstream callers |
 | --- | --- | --- | --- |
-| Database bootstrap | `includes/functions.php`, `includes/database_mysqli.php` | Creates the `OGPDatabase` instance and exposes helpers such as `resultQuery()`, `addGameHome()`, and logging. | Every panel page, `modules/billing/includes/panel_bridge.php`, cron jobs. |
+| Database bootstrap | `Panel/includes/functions.php`, `Panel/includes/database_mysqli.php` | Creates the `OGPDatabase` instance and exposes helpers such as `resultQuery()`, `addGameHome()`, and logging. | Every panel page, `Website/Website/includes/panel_bridge.php`, cron jobs. |
 | Session helpers | `includes/helpers.php` (`startSession()`) | Sets `session_name('opengamepanel_web')`, sanitizes request vars, loads locales. | `index.php`, `home.php`, provisioning pages, storefront session bridge. |
-| Remote control | `includes/lib_remote.php` | Wraps agent RPC (install/update, FTP user management, rsync, SteamCMD). | `modules/gamemanager/*`, `modules/billing/create_servers.php`, cron jobs. |
+| Remote control | `Panel/includes/lib_remote.php` | Wraps agent RPC (install/update, FTP user management, rsync, SteamCMD). | `Panel/modules/gamemanager/*`, `Website/create_servers.php`, cron jobs. |
-| XML parser | `modules/config_games/server_config_parser.php` | Converts `modules/config_games/server_configs/*.xml` into PHP arrays used for provisioning and pricing metadata. | `modules/gamemanager`, `modules/billing` (catalog + provisioner), cron installers. |
+| XML parser | `Panel/modules/config_games/server_config_parser.php` | Converts `Panel/modules/config_games/server_configs/*.xml` into PHP arrays used for provisioning and pricing metadata. | `Panel/modules/gamemanager`, `Website/` (catalog + provisioner), cron installers. |
 | API surface | `ogp_api.php`, `includes/api_functions.php` | HTTP API for third-party tooling. Exposes operations such as starting/stopping homes, querying stats. | Mobile apps, automated provisioning, selected billing workflows. |
 | Cron/automation | `scripts/` (`cron-shop.php`, `status/*`, etc.) | Suspends/unsuspends services, refreshes status caches, runs backups. | Triggered via system cron or panel scheduler. |
 
 ## High-level flows
 
-1. **Auth/session** – Driven by `index.php` (panel) and `modules/billing/login.php` (storefront). Both set `$_SESSION['user_id']`, `users_login`, `users_group`, and `website_user_id`. The shared session cookie `opengamepanel_web` means logging into either surface immediately authenticates the other.
+1. **Auth/session** – Driven by `index.php` (panel) and `Website/login.php` (storefront). Both set `$_SESSION['user_id']`, `users_login`, `users_group`, and `website_user_id`. The shared session cookie `opengamepanel_web` means logging into either surface immediately authenticates the other.
 2. **Catalog** – `modules/config_games` hosts XML definitions. Panel modules (`gamemanager`, `config_games`) and storefront pages (`serverlist.php`, `order.php`, documentation pages, and the XML-notes mirror) parse these files for display and provisioning metadata.
-3. **Provisioning** – Orders land in `gsp_billing_orders`. `modules/billing/create_servers.php` allocates homes, assigns nodes/IPs, configures mods, kicks off SteamCMD/rsync/manual installers, and then syncs the resulting `home_id` back into `billing_orders`, `billing_invoices`, and `billing_transactions` so paid services never stay orphaned. The same provisioner is invoked by:
+3. **Provisioning** – Orders land in `gsp_billing_orders`. `Website/create_servers.php` allocates homes, assigns nodes/IPs, configures mods, kicks off SteamCMD/rsync/manual installers, and then syncs the resulting `home_id` back into `billing_orders`, `billing_invoices`, and `billing_transactions` so paid services never stay orphaned. The same provisioner is invoked by:
-   - PayPal capture endpoint (`modules/billing/api/capture_order.php`).
+   - PayPal capture endpoint (`Website/api/capture_order.php`).
    - Panel module page `home.php?m=billing&p=provision_servers`.
-   - Cron/repair actions in `modules/billing/cron-shop.php`.
+   - Cron/repair actions in `Website/cron-shop.php`.
 4. **Renewals** – `cron-shop.php` inspects `billing_orders.end_date` and toggles `status` between `installed`, `invoiced`, `suspended`, and `deleted`. PayPal renewals extend `end_date` in `capture_order.php` and immediately flip `status` back to `installed`.
-5. **Documentation** – `modules/billing/docs.php`, per-game folders under `modules/billing/docs/`, and the XML wiki mirror (PHP port of `XML-Notes`) are used by both admins and AI helpers to craft game templates.
+5. **Documentation** – `Website/docs.php`, per-game folders under `Website/docs/`, and the XML wiki mirror (PHP port of `XML-Notes`) are used by both admins and AI helpers to craft game templates.
 
 ## Panel modules (selected)
 
 | Module | Key files | Primary responsibilities | Upstream/Downstream dependencies |
 | --- | --- | --- | --- |
-| `dashboard` | `modules/dashboard/dashboard.php` | Landing page once authenticated. Pulls stats from homes, invoices, and support modules. Shows "Last updated" footer based on `modules/billing/timestamp.txt`. | Reads `billing_orders`, `game_homes`, `tickets`. |
+| `dashboard` | `Panel/modules/dashboard/dashboard.php` | Landing page once authenticated. Pulls stats from homes, invoices, and support modules. Shows "Last updated" footer based on `Website/timestamp.txt`. | Reads `billing_orders`, `game_homes`, `tickets`. |
-| `gamemanager` | `modules/gamemanager/server_monitor.php`, `modules/gamemanager/game_monitor.php` | Shows owned homes, start/stop, update, reinstall, port usage. Uses XML to know command lines. | Relies on `lib_remote`, `config_games`, `user_games` assignments. |
+| `gamemanager` | `Panel/modules/gamemanager/server_monitor.php`, `Panel/modules/gamemanager/game_monitor.php` | Shows owned homes, start/stop, update, reinstall, port usage. Uses XML to know command lines. | Relies on `lib_remote`, `config_games`, `user_games` assignments. |
 | `config_games` | `modules/config_games/add_mod.php`, `server_config_parser.php`, XML files under `server_configs/` | Admin UI for XML definitions. Controls what appears in storefront/service catalog. | Feeds `gamemanager`, billing catalog, cron installers. |
-| `steam_workshop` | `modules/steam_workshop/admin.php`, `user.php`, `includes/functions.php`, `navigation.xml` | Admin profile defaults + per-home mod management. Profile defaults can now be refreshed from game XML and the user route is explicitly exposed via `p=user`. | Uses `config_games` XML metadata + `server_homes`/assignment tables; feeds workshop agent updater. |
+| `steam_workshop` | `modules/steam_workshop/admin.php`, `user.php`, `Panel/includes/functions.php`, `navigation.xml` | Admin profile defaults + per-home mod management. Profile defaults can now be refreshed from game XML and the user route is explicitly exposed via `p=user`. | Uses `config_games` XML metadata + `server_homes`/assignment tables; feeds workshop agent updater. |
 | `user_games` | `modules/user_games/add_home.php`, `assign_home.php`, `edit_home.php` | Admin workflow to add homes manually or edit assignments. Shares DB tables with billing provisioner. | Uses `game_homes`, `remote_servers`, `billing_orders`. |
 | `administration` / `user_admin` | CRUD around users, groups, permissions, expire dates. | Sets roles consumed by storefront admin guard and provisioning ACLs. |
 | `server` | `modules/server/*` | Remote server management (agents, IPs, ports, reinstall keys). Billing uses these tables for available nodes/locations. |
@@ -42,7 +42,7 @@ This file captures how the control panel, storefront, agents, and helper scripts
 | `news`, `circular`, `faq` | Content modules for panel UI. | Use standard MVC wrappers, share session/auth. |
 | `cron` | Scheduler UI feeding `scripts/` commands. | Maintains job metadata that OS cron reads. |
 
-## Storefront (modules/billing)
+## Storefront (Website/)
 
 | Area | Key files | Notes |
 | --- | --- | --- |
@@ -50,7 +50,7 @@ This file captures how the control panel, storefront, agents, and helper scripts
 | Auth | `login.php`, `register.php`, `reset_password.php`, `forgot_password.php`, `includes/login_required.php`, `includes/admin_auth.php` | Share `opengamepanel_web` session, call into panel DB to validate roles. |
 | Admin | `admin.php`, `adminserverlist.php`, `admin_orders.php`, `admin_coupons.php`, `admin_config.php`, `my_orders_panel.php` | Manage services, coupons, prices, and provisioning. `adminserverlist.php` controls service availability per node. |
 | PayPal API | `api/create_order.php`, `api/capture_order.php`, `webhook.php`, `logs/payment_capture.log` | Implements REST checkout. The cart stamps PayPal `custom_id` with the exact invoice IDs being purchased; capture/webhook handlers use that to mark the correct invoices paid, create/extend orders, and kick provisioning idempotently. |
-| Provisioning bridge | `create_servers.php`, `includes/provisioner.php`, `includes/panel_bridge.php` | Shared between panel module and storefront backend. Encapsulates whole server creation/renewal pipeline. |
+| Provisioning bridge | `create_servers.php`, `includes/provisioner.php`, `Website/includes/panel_bridge.php` | Shared between panel module and storefront backend. Encapsulates whole server creation/renewal pipeline. |
 | Cron helpers | `cron-shop.php`, `diag_remote.php` | Automations for renewals, diagnostics, health checks. |
 | Documentation | `docs.php`, `docs/*`, `docs/admin_xml_notes.php` (PHP mirror of XML wiki) | Provide guidance for editing XML and game configs directly inside repo. |
 | Logs/data | `logs/`, `data/`, `timestamp.txt` | Payment JSON archives, debug traces, and "Last updated" canonical string. |
@@ -59,21 +59,21 @@ This file captures how the control panel, storefront, agents, and helper scripts
 
 | Component | Location | Purpose |
 | --- | --- | --- |
-| Remote agent | `modules/gamemanager` talks to standalone agent binaries configured per `remote_servers`. | Executes installs, updates, start/stop commands. Provisioner relies on it for SteamCMD and rsync workflows. |
+| Remote agent | `Panel/modules/gamemanager` talks to standalone agent binaries configured per `remote_servers`. | Executes installs, updates, start/stop commands. Provisioner relies on it for SteamCMD and rsync workflows. |
-| Apache/Nginx vhosts | `/etc/apache2/sites-available` (not in repo) | Point either the storefront domain or panel subpath at `modules/billing/`. Required for shared session cookie scope. |
+| Apache/Nginx vhosts | `/etc/apache2/sites-available` (not in repo) | Point either the storefront domain or panel subpath at `Website/`. Required for shared session cookie scope. |
 
 ## Data touchpoints
 
-- **Users** – `gsp_users` table is shared. Registration uses `modules/billing/register.php`, admin pages use `modules/user_admin`. Password upgrades must not break panel logins.
+- **Users** – `gsp_users` table is shared. Registration uses `Website/register.php`, admin pages use `Panel/modules/user_admin`. Password upgrades must not break panel logins.
 - **Billing tables** – `gsp_billing_services`, `gsp_billing_orders`, `gsp_billing_invoices`, `gsp_billing_coupons`. Admin edits (pricing, enable/disable, locations) are done via `adminserverlist.php`; automation uses `cron-shop.php`.
 - **Homes/Mods/IPs** – Stored in `gsp_game_homes`, `gsp_game_mods`, `gsp_remote_server_ips`. Provisioner writes to these tables; `gamemanager`, `litefm`, `ftp`, and `user_games` read them.
-- **Logging** – `$db->logger()` writes to `ogp_logs`. Storefront-specific logs live in `modules/billing/logs/` for quick inspection (payment capture, provisioning outcomes, coupon usage).
+- **Logging** – `$db->logger()` writes to `ogp_logs`. Storefront-specific logs live in `Website/logs/` for quick inspection (payment capture, provisioning outcomes, coupon usage).
 
 ## Usage tips
 
-1. **Need a DB object inside `modules/billing`?** Include `includes/panel_bridge.php` and call `billing_get_panel_db()`. It sets up constants, loads helpers, and caches the `OGPDatabase` instance so multi-call flows (e.g., capture → provision → email) reuse it.
+1. **Need a DB object inside `Website/`?** Include `Website/includes/panel_bridge.php` and call `billing_get_panel_db()`. It sets up constants, loads helpers, and caches the `OGPDatabase` instance so multi-call flows (e.g., capture → provision → email) reuse it.
-2. **Want to change provisioning?** Update `modules/billing/includes/provisioner.php` once. `create_servers.php`, PayPal webhooks, cron jobs, and admin repair flows all use it.
+2. **Want to change provisioning?** Update `Website/includes/provisioner.php` once. `create_servers.php`, PayPal webhooks, cron jobs, and admin repair flows all use it.
-3. **Working on XML or documentation?** Update the XML file under `modules/config_games/server_configs/`, regenerate docs if needed, and keep the PHP XML-notes mirror (`modules/billing/docs/xml_notes.php`) accurate so the admin link stays trustworthy.
+3. **Working on XML or documentation?** Update the XML file under `Panel/modules/config_games/server_configs/`, regenerate docs if needed, and keep the PHP XML-notes mirror (`Website/docs/xml_notes.php`) accurate so the admin link stays trustworthy.
 4. **Need to know who uses a table?** Search `.github/module-map.md` first; the table above lists the canonical readers/writers for each major schema.
 
 _Last updated: 2025-11-20._

.gitignore

@@ -1,16 +1,16 @@
 # Ignore database configuration files with sensitive credentials
-modules/billing/includes/config.inc.php
+Website/includes/config.inc.php
-includes/config.inc.php
+Panel/includes/config.inc.php
-status/api/config.php
+Panel/status/api/config.php
-status_api_local.php
+Panel/status_api_local.php
 
 # Ignore logs
-modules/billing/logs/*.log
+Website/logs/*.log
-modules/billing/logs/*.txt
+Website/logs/*.txt
 
 # Ignore data directory (payment JSONs)
-modules/billing/data/*.json
+Website/data/*.json
-!modules/billing/data/.gitkeep
+!Website/data/.gitkeep
 
 # Ignore backup files
 *.backup
@@ -30,5 +30,5 @@ Thumbs.db
 # Ignore temporary files
 /tmp/
 *.tmp
-modules/billing/data/*.log
+Website/data/*.log
-tools/__pycache__/
+Panel/tools/__pycache__/