Panel/Panel/modules/website

Gameservers.World Website Module

This module is the public Gameservers.World sales and documentation website.

Purpose

• Keep the public site inside the GSP repository at Panel/modules/website/
• Remove location-dependent include logic from the old standalone Website/ tree
• Keep marketing pages working even when billing configuration is missing
• Centralize URL and filesystem path handling so the site is portable

Structure

Panel/modules/website/
  index.php
  serverlist.php
  order.php
  cart.php
  checkout.php
  payment_success.php
  payment_cancel.php
  docs.php
  login.php
  register.php
  forgot_password.php
  reset_password.php
  account.php
  my_account.php
  orders.php
  my_orders.php
  invoices.php
  my_servers.php
  staff.php
  staff_services.php
  staff_locations.php
  staff_coupons.php
  staff_orders.php
  staff_invoices.php
  staff_payments.php
  staff_paypal.php
  staff_settings.php
  staff_provisioning.php
  staff_migrations.php
  webhook.php
  pricing.php
  locations.php
  support.php
  doc_asset.php
  api/
    create_order.php
    capture_order.php
  includes/
    bootstrap.php
    billing.php
    footer.php
    header.php
    navigation.php
    paths.php
  assets/
    css/
    js/
    images/
  pages/
    home.php
    game_servers.php
    cart.php
    documentation.php
    pricing.php
    locations.php
    support.php
  config/
    config.example.php
    pricing.php
    services.php

URL helpers

The website uses a central bootstrap instead of scattered relative paths.

• website_url('serverlist.php')
• website_asset('css/site.css')
• panel_url()
• login_url()
• website_order_url(1)
• documentation_url('minecraft')

Navigation and homepage

The shared header keeps the main navigation short:

• Home
• Game Servers
• Documentation
• Support
• Account/Login
• Custom Projects
• Control Panel

Pricing and locations pages can remain available through the footer or direct links, but the public homepage carries concise pricing and location summaries so the desktop and mobile menus stay focused.

Billing, database, and staff behavior

The public site does not include Panel/modules/billing/includes/config.inc.php directly.

Instead it:

1. Parses Panel/includes/config.inc.php when present
2. Parses Panel/modules/billing/includes/config.inc.php when present
3. Uses the discovered database values only for pages that need catalog data
4. Falls back cleanly when no usable billing or panel DB config is available

Effects:

• index.php, docs.php, locations.php, pricing.php, and support.php still load
• serverlist.php shows a clean fallback message instead of a fatal include error
• shared navigation never crashes because billing config is missing

Sales and billing tables are installed through the staff migration runner:

• staff_migrations.php

The runner is idempotent and uses the current configured Panel table prefix. It creates invoice, order, payment, coupon, password-reset, PayPal webhook, website settings, and provisioning-attempt tables when missing. It also adds missing catalog columns to an existing billing_services table.

Website staff pages are separate from GSP Panel administration. They manage website sales, catalog, pricing, coupons, invoices, payments, PayPal settings, and the paid-order provisioning queue. Access currently requires a Panel admin account.

Staff links must point to staff.php and related staff_*.php website pages. Do not use the Panel activity logger as the website staff dashboard.

Shared Accounts

The Panel user table is the identity source for the website. Website login checks the same users table and legacy Panel password hash format instead of creating a second password database.

The website and Panel run on different parent domains, so PHP session cookies are not shared. SSO is deferred in the current implementation. Users can use the same username and password on both sites, but the website and Panel keep separate sessions. Control Panel and staff links point directly to the configured Panel URL.

sso.php endpoints are compatibility redirects only. They do not create tokens or sessions.

Successful website login redirects to my_account.php by default, or to a saved safe internal return path such as cart.php?checkout=1. account.php remains as a compatibility route.

Ordering

The active catalog route is serverlist.php. Order buttons point to the website entry point:

• order.php?service_id=...

That page validates service_id server-side against enabled catalog rows, then lets anonymous visitors configure slots and location before adding the service to the session cart. Login or registration is required only when the customer proceeds to checkout. The removed billing/order.php route is obsolete and should not be used for customer-facing links.

The website owns catalog display, cart storage, checkout intent, pricing display, and customer confirmation. Payment approval and final server provisioning remain server-side responsibilities; browser requests must not call private provisioning methods directly.

Checkout creates invoice/order records only after login or registration. The anonymous cart remains in the website session until that point. PayPal order creation and capture are handled through api/create_order.php and api/capture_order.php; webhook.php verifies PayPal webhook signatures and deduplicates events.

PayPal credentials must not be committed to source. Preferred runtime settings:

• GSP_WEBSITE_PAYPAL_CLIENT_ID
• GSP_WEBSITE_PAYPAL_CLIENT_SECRET
• GSP_WEBSITE_PAYPAL_WEBHOOK_ID

The staff PayPal page can store fallback settings in website_settings, but secrets are masked after save.

More detail: docs/modules/website_billing_rebuild.md.

Service catalog display

The public game-server catalog is a compact row/list view. It should show customer-facing service names, user-friendly platform labels, short descriptions, pricing, ordering, and documentation actions. Raw XML/config keys are used internally for service lookup and documentation routing, but should not be shown as the public platform label.

website_service_platform() derives platform labels from service/config values:

• Linux: linux, linux32, linux64
• Windows: win, win32, win64, windows
• Cross-platform: both Linux and Windows markers
• Unknown: no recognizable platform marker

The order/configuration page keeps the card layout but displays the same derived platform label. The staff service editor uses expandable rows so service ID, enabled status, display name, platform, price, slot range, image status, and locations are easier to scan.

Documentation source

Customer documentation is read from the existing billing docs directory:

• Panel/modules/billing/docs/

This keeps the website portable without duplicating the documentation tree.

Deployment

Preferred Apache approach:

1. Point the Gameservers.World vhost DocumentRoot to Panel/modules/website
2. Expose billing separately under /billing/ with an Apache Alias
3. Set panel_url, login_url, and billing_base_url in config/config.php or config/config.local.php

Example:

<VirtualHost *:80>
    ServerName gameservers.world
    ServerAlias www.gameservers.world
    DocumentRoot /var/www/html/GSP/Panel/modules/website

    <Directory /var/www/html/GSP/Panel/modules/website>
        AllowOverride All
        Require all granted
        DirectoryIndex index.php
    </Directory>

    Alias /billing /var/www/html/GSP/Panel/modules/billing
    <Directory /var/www/html/GSP/Panel/modules/billing>
        AllowOverride All
        Require all granted
        DirectoryIndex index.php
    </Directory>
</VirtualHost>

Alternate front-controller approach:

• Keep a tiny public index.php outside the repo tree that requires Panel/modules/website/index.php
• Do not duplicate the full website into a second location

Configuration

1. Copy config/config.example.php to config/config.php or config/config.local.php
2. Set:
   • public_base_url
   • billing_base_url
   • panel_url
   • login_url
   • Runlevel Systems company and project-request URLs
   • support links
3. Keep any environment-specific config out of Git

Runlevel Systems Project Request Integration

The website keeps its custom-development CTA URL centralized in:

• Panel/modules/website/config/services.php

Optional overrides can be placed in:

• Panel/modules/website/config/config.php
• Panel/modules/website/config/config.local.php

The current project request URL is:

• https://runlevelsystems.com/start-project.php

Homepage CTA location:

• Panel/modules/website/pages/home.php

Shared footer branding location:

• Panel/modules/website/includes/footer.php

The public wording distinguishes between ordinary support and project work:

• support is for troubleshooting, service issues, and existing features
• project requests are for custom scripts, mods, integrations, automation, migrations, dashboards, and GSP feature work

Use the shared config values instead of scattering the Runlevel Systems URL or company name through templates.

Pricing and Platform Reference

Internal pricing planning remains in:

• pricing/gameservers_world_pricing_catalog.xlsx

Public website summary values are centralized in:

• Panel/modules/website/config/pricing.php

Optional environment-specific overrides can be placed in:

• Panel/modules/website/config/config.php
• Panel/modules/website/config/config.local.php

Public pricing guidance currently exposes:

• standard hosting starts at $0.50 per slot
• selected lightweight legacy servers can start around $4 per month
• most standard plans use a 16-slot minimum
• fixed-cap or small co-op games may use different slot limits
• custom development and complex integration work are quoted separately

Platform wording is also centralized in config/pricing.php so hardware references stay secondary and easy to update. The website should keep customization, legacy-game support, fair pricing, backups, and monitored capacity as the primary sales message. Hardware copy should remain a small platform note rather than a headline feature.

Pages currently displaying pricing or platform summary copy:

• index.php
• serverlist.php
• pricing.php

If pricing or example host details change later:

1. Update the workbook if it is the internal reference source
2. Update config/pricing.php with the approved public summary
3. Override values in config.php or config.local.php only when deployment-specific differences are required
4. Recheck homepage, server catalog, and pricing page copy for consistency

Manual link checks

Verify:

1. index.php
2. serverlist.php
3. docs.php
4. pricing.php
5. locations.php
6. support.php
7. login.php
8. header navigation
9. footer links
10. mobile navigation
11. asset URLs
12. billing_url() destinations

Portability notes

• No /var/www/html/... filesystem assumptions
• No gameservers.world/panel assumptions
• No repeated ../../../ path climbing
• Internal page links and assets route through helpers
• Database config is optional for non-catalog pages