{{-- theme-admin no longer swaps the palette. It used to load a complete dark set — its own surfaces, its own orange, its own status triad — which made the console a second product and forced every shared component to work in two worlds. It now carries density only: smaller type, tighter rows, tighter corners. Colour comes from one place. --}} @php $release = App\Services\Deployment\Release::current(); // Seeds the page-wide update watcher below. Computed here, once, for // every console page — not only Settings — because the thing being // watched restarts the containers serving whichever page the // operator happens to have open, so the watcher (and its overlay) // must already exist before that happens, wherever they are. $updateChannel = app(App\Services\Deployment\UpdateChannel::class); $updateState = $updateChannel->state(); $updateStep = $updateState['phase'] !== null ? __('admin_settings.update_step', ['step' => $updateState['phase']]) : null; // Only once a run has actually started, not while merely queued — // otherwise this is the PREVIOUS run's leftovers, read on every page // load whether or not anything is running at all. $updateRunningSince = $updateState['started_at'] !== null ? __('admin_settings.update_since', ['when' => $updateState['started_at']->diffForHumans()]) : null; $updateLog = $updateState['started_at'] !== null ? $updateChannel->lastLog() : null; @endphp

@auth

@endauth

{{-- Maintenance overlay: the console during a deployment. Bound HERE, once, rather than on the settings page's own update card — this is the only binding of updateWatcher (resources/js/app.js) in the app, so it is already in the browser, and stays in the browser, no matter which console page the deploy catches the operator on. Reported bug: the settings card flickered and vanished mid-run, and every OTHER console page showed nothing at all, because nothing was watching there. Client-side is the only way this can work: the containers go down mid-run, which is exactly when the view has to stay visible — a server-rendered maintenance route cannot answer while it is itself offline. No close affordance: the run does not stop because an operator closed a dialog, so offering one would be a lie. It clears itself — window.location.reload() from inside updateWatcher — the moment the build commit changes or `running` goes false, landing the operator back on the very page they were on. --}}

{{-- Queued: the agent has not picked the request up yet, so there is no step yet either. This used to count down to the agent's next tick. It was wrong twice over. Wrong in fact: the countdown target was recomputed on every poll, and where the reported interval was shorter than the timer actually installed it landed in the past every time and reset to a full minute — so it ran backwards four seconds and jumped, forever. And wrong in kind: with the agent woken the moment the request lands there is nothing left to wait for. A sentence, not a clock. --}}

{{ $updateState['instant'] ? __('admin_settings.update_starting') : __('admin_settings.update_starting_queued') }}

{{-- Running: the step, how long it has been going, and the tail of the log — a run that IS stuck is then visibly stuck AT a step, not just a spinner nobody can read anything from. --}}

@livewire('wire-elements-modal') @livewireScripts

{{ __('admin_settings.update_overlay_title') }}