GSP/Panel
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

small fixes

Browse source
This commit is contained in:
Frank Harris 2026-06-17 09:15:42 -05:00
parent bd3875743e
commit 28533be24d
9 changed files with 310 additions and 524 deletions
Download patch file Download diff file Expand all files Collapse all files

22
docs/modules/PANEL_UPDATE.md
View file

@ -23,6 +23,22 @@ The update page uses these settings:
- `gsp_update_panel_post_update_command`
- `gsp_update_backup_before`
The current admin UI shows these directly:
- Repository URL / Path
- Branch / Channel
- Repository Root
- Backup Path
- Backup Retention
- Backup Before Update
The current admin UI keeps these derived or advanced:
- Panel Path is derived from Repository Root plus `/Panel`
- Panel Source Folder is fixed to `Panel`
- Git Executable is hidden and defaults to `git`
- Post-update Command remains under Advanced Settings
## Defaults
- Repository URL / Path: `http://forge.runlevelsystems.com/dev/GSP.git`
@ -58,9 +74,15 @@ The backup directory is created recursively if missing.
Retention is enforced after each successful backup.
Current count labels:
- `Managed Backups Stored` means all managed updater snapshots discovered in the backup base
- `Rollback Backups Available` means only full timestamped backups that the restore flow can actually restore
## Rollback Workflow
- The rollback selector lists managed backups.
- The restore action only accepts full timestamped backups from `gsp_get_available_backups()`.
- Restoring a backup restores the Panel tree and metadata.
- Missing website archives are ignored because the active backup path is Panel-focused.
- Apache config restore is optional.

29
docs/modules/UPDATE.md
View file

@ -20,7 +20,7 @@ The active update page is intentionally narrow:
- shows the installed Panel version
- shows the current git branch and commit when available
- exposes editable repository settings for the Panel update only
- exposes a reduced set of commonly changed repository settings for the Panel update only
- can create a Panel backup
- can update the Panel from the configured repository and branch
- can roll back to an existing Panel backup
@ -43,6 +43,22 @@ The admin page stores these settings in the Panel settings table:
- `gsp_update_panel_post_update_command`
- `gsp_update_backup_before`
The active UI now exposes these commonly changed settings directly:
- Repository URL / Path
- Branch / Channel
- Repository Root
- Backup Path
- Backup Retention
- Backup Before Update
The active UI now treats these as derived or advanced:
- Panel Path is derived as `Repository Root + /Panel`
- Panel Source Folder is fixed to `Panel`
- Git Executable is hidden and defaults to `git`
- Post-update Command remains available under Advanced Settings
Defaults:
- Repository URL / Path: `http://forge.runlevelsystems.com/dev/GSP.git`
@ -66,20 +82,25 @@ Retention is enforced after each successful backup.
If retention is `5`, the newest five managed backups are kept and older managed backups are pruned automatically.
Current backup counters on the admin page:
- `Managed Backups Stored` counts all managed updater snapshots returned by `gsp_get_managed_backup_entries()`, including full and component-style entries when present
- `Rollback Backups Available` counts only full timestamped backups returned by `gsp_get_available_backups()` that the restore flow can actually use
## Implementation Notes
- `gsp_update_settings()` and `gsp_validate_update_settings()` remain top-level in `Panel/modules/administration/panel_update.php`.
- `gsp_checkout_update_source()` remains a top-level compatibility helper for the configured repository checkout.
- `gsp_do_configured_git_update()` now applies only the Panel source folder into the configured Panel path.
- `gsp_do_configured_git_update()` now applies only the fixed `Panel` source folder into the derived Panel path.
- The page no longer depends on website or agent update settings.
## Update Flow
1. Save or submit repository settings.
2. Validate repository URL, branch, repo root, Panel path, and backup settings.
2. Validate repository URL, branch, repo root, and backup settings.
3. Create a backup when enabled.
4. Clone the configured repository source and branch into a temporary checkout.
5. Copy only the configured Panel source folder into the configured Panel path.
5. Copy only the fixed `Panel` source folder into the derived Panel path.
6. Preserve `Panel/includes/config.inc.php`.
7. Run module updates/post-update hooks.
8. Write version metadata and `LAST_UPDATE.txt`.

57
docs/modules/dashboard.md
View file

@ -9,17 +9,16 @@ Main landing dashboard with widgets and quick server overview.
## Current Status
- Functional
- Uses the existing collapsible widget layout for customer-facing quick actions
- Uses a fixed four-card customer dashboard layout
## Dependencies
- Panel dashboard widgets
- user permissions
- shared Panel URL helpers
## Database Tables
- `widgets`
- `widgets_users`
- none required for the active customer dashboard card layout
## Agent Interaction
@ -40,12 +39,12 @@ Main landing dashboard with widgets and quick server overview.
## Known Issues
- some default widget IDs are legacy and limit how far the collapsible layout can be expanded without a schema change
- legacy widget infrastructure still exists in the module for historical compatibility, but the active customer dashboard no longer depends on it
## Missing Functionality
- richer status and alert surfaces
- deeper async server-status embedding without adding remote checks to normal dashboard loads
- deeper account summaries if a future design needs per-user metrics beyond the Game Monitor link
## Suggested Future Improvements
@ -55,31 +54,41 @@ Main landing dashboard with widgets and quick server overview.
- Keep / Improve
## Runlevel Systems Project Request Integration
## Current Dashboard Cards
- Dashboard render file: `Panel/modules/dashboard/dashboard.php`
- Dashboard styles: `Panel/modules/dashboard/dashboard.css`
- Shared Panel project URL helper: `Panel/includes/functions.php`
- Shared Discord invite helper: `Panel/includes/functions.php`
- Shared server-status route helper: `Panel/includes/functions.php`
- Theme base: active SimpleBootstrap icon set
Current project request URL:
Rendered cards:
- `https://runlevelsystems.com/start-project.php`
- `Account Overview`
- button: `View My Servers`
- route: `home.php?m=gamemanager&p=game_monitor`
- `Custom Server Code`
- button: `Request Custom Development`
- URL: `https://runlevelsystems.com/start-project.php`
- opens in a new tab
- `Support`
- buttons:
- `Create Support Ticket`
- `Join Discord`
- support route: `home.php?m=tickets&p=submitticket`
- Discord URL: `https://discord.gg/qt9Hnkj6cv`
- `Server Status`
- button: `View Server Status`
- route: `server_status.php`
- opens separately so dashboard rendering does not wait on remote checks
Dashboard behavior:
Support versus custom development:
- retained collapsible sections:
- `Account Overview`
- `Custom Server Code`
- `Support`
- removed duplicate standalone sections:
- `Custom Server Development`
- `Support and Troubleshooting`
- support remains the path for routine troubleshooting, service issues, and existing features
- the custom-development CTA points users at Runlevel Systems for project work such as custom scripts, mods, integrations, automation, migrations, dashboards, and advanced server tooling
- the Discord support invite should use:
- `https://discord.gg/qt9Hnkj6cv`
- `Custom Server Code` should open the Runlevel project request in a new tab
- `Support` should keep ticketing and Discord support separate from paid project work
- `Server Status` stays available from the dashboard, but remote checks are intentionally deferred to the separate status page so normal dashboard loads do not block on agent/network timeouts
- support is for routine troubleshooting, service issues, and help using included features
- custom development is for scripts, integrations, automation, migrations, mods, and new tooling
Behavior change:
- collapsible behavior was removed from the active customer dashboard blocks
- the old blank-space-prone widget columns are no longer used for the four main customer actions

24
docs/modules/status.md
View file

@ -56,26 +56,34 @@ Admin status page for server/node state.
## Display Rules
- Removed the old `Hostname` column
- Removed the repeated per-row `Last Checked` column
- Keep one overall `Checked:` timestamp above the table
- Removed Panel-to-server latency from the customer-facing page
- Keep:
- `Server Name`
- `Location / IP`
- `Status`
- `Agent Status`
- `Panel-to-server latency`
- `Last Checked`
- Latency wording must remain truthful:
- current label: `Panel-to-server latency`
- this is a server-side connectivity check from the Panel host
- it is not customer-browser latency and must not be presented as the player's ping
- Status values should remain compact and truthful:
- `Online`
- `Timed out`
- `Agent unavailable`
- `Unknown`
Latency note:
- Browser ICMP ping is not available from the Panel UI
- The previous Panel-to-server latency values were removed because they do not represent the customer's connection to the game-server location
- Do not attempt to ping the customer's IP from the Panel or from a game server
## Theme Notes
- The status page should visually match the active dark Panel theme
- Use responsive table wrapping for mobile widths instead of forcing a wide desktop table into the viewport
- Keep the page compact and avoid repeated explanatory cards
## Suggested Future Improvements
- optional browser-side latency testing only if each location has a safe public health endpoint and the implementation can remain honest about what is being measured
- optional browser-side location latency testing only if each location has a safe public HTTP or HTTPS health endpoint and the implementation remains honest about what is being measured
## Recommendation

17
docs/modules/update.md
View file

@ -46,12 +46,12 @@ Panel update and patch management.
## Missing Functionality
- richer update history and rollback guidance
- live progress polling for asynchronous remote agent updates
- clearer operator documentation around backup counts and derived settings
## Suggested Future Improvements
- keep admin-only and document carefully
- add status polling for `component_update` logs after the agent has restarted
- add richer update history summaries if the page later needs deeper audit visibility
## Recommendation
@ -63,9 +63,12 @@ The primary update implementation lives in `Panel/modules/administration/panel_u
Current update targets:
- Panel files
- Website files
- Linux agents
- Windows/Cygwin agents
- Panel files only in the active admin UI
The updater uses a single configured Git repository with component source folders such as `Panel`, `Website`, `Agent_Linux`, and `Agent-Windows`. Remote agents are updated through the encrypted `component_update` XML-RPC method and preserve hosted game data and agent configuration folders.
Active UI behavior:
- Repository Root is the primary deployment path setting
- Panel Path is derived internally as `Repository Root + /Panel`
- Panel Source Folder is fixed to `Panel`
- Git Executable is hidden and defaults to `git`
- Post-update Command remains available only as an advanced field