AS1024/itflow
1
0
Fork 0
mirror of https://github.com/itflow-org/itflow synced 2026-08-27 09:55:12 +00:00
Code Issues Packages Projects Releases Wiki Activity

Remove DB Update from WebUI as this is handled by the update_cli backend

Browse Source
This commit is contained in:
johnnyq
2026-08-26 22:59:17 -04:00
parent 51c925522c
commit 14c38b9814
3 changed files with 42 additions and 71 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
admin/database_updates.php
View File

@@ -18,7 +18,7 @@
*/
// Check if our database versions are defined
// If undefined, the file is probably being accessed directly rather than called via post.php?update_db or update_cli.php
// If undefined, the file is probably being accessed directly rather than called via update_cli.php
if (!defined("LATEST_DATABASE_VERSION") || !defined("CURRENT_DATABASE_VERSION") || !isset($mysqli)) {
echo "Cannot access this file directly.";
exit();
@@ -27,7 +27,7 @@ if (!defined("LATEST_DATABASE_VERSION") || !defined("CURRENT_DATABASE_VERSION")
// Migration files include-guard against this constant
define("FROM_DB_UPDATER", true);
// Outputs for the caller (post/update.php, update_cli.php)
// Outputs for the caller (update_cli.php)
$database_updates_applied = []; // Versions successfully applied this run
$database_updates_error = null; // "version: error message" if a migration failed

40
admin/post/update.php
View File

@@ -3,11 +3,12 @@
defined('FROM_POST_HANDLER') || die("Direct file access is not allowed");
/*
* Queueing is the ONLY way to update the application. There used to be an ?update handler
* here that ran git pull (or a hard reset) inside this request; it is gone deliberately.
* scripts/update_cli.php replaces the files this request is executing from and then applies
* the migrations that came with them, which is not something to do half way through a page
* load, and a host where PHP cannot run external commands could never do it at all.
* Queueing is the ONLY update path from the web - files and database both. There used to be
* an ?update handler here that ran git pull inside this request, and an ?update_db one that
* ran the migrations; both are gone deliberately. scripts/update_cli.php replaces the files
* this request is executing from and then applies the migrations that came with them, which
* is not something to do half way through a page load, and a host where PHP cannot run
* external commands could never do the first half at all.
*
* The row is written as well as the settings column: config_update_queued_at is what
* cron/app_update.php acts on, and cron_job_run_now is what gets the dispatcher to look
@@ -20,9 +21,10 @@ if (isset($_GET['queue_update'])) {
enforceAdminPermission();
// The files can be newer than the schema - that is the window this whole page exists to
// close - and the column the queue is written to arrives with a migration
// close - and the column the queue is written to arrives with a migration. There is no
// longer a button that applies migrations on their own, so the way out is the shell.
if (!settingsColumnExists($mysqli, 'config_update_queued_at')) {
flashAlert("Apply the database update first - queueing needs a schema change this install has not caught up with yet.", 'error');
flashAlert("Queueing needs a schema change this install has not caught up with yet - run php scripts/update_cli.php from a shell once, and it will work from then on.", 'error');
redirect();
}
@@ -36,27 +38,3 @@ if (isset($_GET['queue_update'])) {
redirect();
}
if (isset($_GET['update_db'])) {
validateCSRFToken();
// Get the current version
require_once ('../includes/database_version.php');
// Perform upgrades, if required - populates $database_updates_applied and $database_updates_error
require_once ('database_updates.php');
if ($database_updates_error) {
logAudit("Database", "Update", "$session_name ran a database update that failed at $database_updates_error");
flashAlert("Database update failed at $database_updates_error - the version was not advanced past the last successful update, so it is safe to retry", "error");
} else {
logAudit("Database", "Update", "$session_name updated the database structure");
flashAlert("Database structure update successful");
}
sleep(1);
redirect();
}

69
admin/update.php
View File

@@ -193,25 +193,35 @@ $app_update_available = !empty($pending_commits);
first: some releases need manual steps, and this page will not do them for you.
</div>
<?php if ($app_update_available && $db_update_available) { ?>
<p class="text-muted">
<i class="fas fa-fw fa-info-circle me-1"></i>Both are pending. Queueing the update covers both -
cron applies the files and then the migrations they bring, in that order, in one run.
</p>
<?php } ?>
<?php if ($app_update_available || !$shell_available) { ?>
<?php /* One action covers both halves - scripts/update_cli.php always runs the database
phase, whether or not the file phase moved anything - so the two are reported
together under one button rather than as separate steps. The db_update_available
arm of the condition matters: a schema behind its code with nothing to pull is
exactly the state that needs queueing, and without it the button would not draw. */ ?>
<?php if ($app_update_available || $db_update_available || !$shell_available) { ?>
<div class="mb-4">
<h6 class="text-uppercase text-secondary">Application files</h6>
<h6 class="text-uppercase text-secondary">Pending</h6>
<?php if ($app_update_available) { ?>
<p class="mb-2">
<strong>Application files:</strong>
<?= count($pending_commits) ?> commit<?= count($pending_commits) === 1 ? '' : 's' ?>
behind <code><?= escapeHtml("origin/$repo_branch") ?></code>.
</p>
<?php } else { ?>
<?php } elseif (!$shell_available) { ?>
<p class="mb-2">
This server cannot check <code><?= escapeHtml("origin/$repo_branch") ?></code>, so there may
or may not be anything waiting. Queueing an update when there is nothing to do is harmless.
<strong>Application files:</strong> this server cannot check
<code><?= escapeHtml("origin/$repo_branch") ?></code>, so there may or may not be anything
waiting. Queueing an update when there is nothing to do is harmless.
</p>
<?php } ?>
<?php if ($db_update_available) { ?>
<p class="mb-2">
<strong>Database:</strong> schema is at
<strong><?= escapeHtml(CURRENT_DATABASE_VERSION) ?></strong> and this code expects
<strong><?= escapeHtml(LATEST_DATABASE_VERSION) ?></strong>. Parts of the app will error
until the update runs.
</p>
<?php } ?>
@@ -225,43 +235,26 @@ $app_update_available = !empty($pending_commits);
<small>
<?php if ($update_queue_available) { ?>
Queue Update hands the job to cron, which runs
<code>scripts/update_cli.php</code> in its own process - it updates the files and then the
database, with no request timeout, as the user that owns the files. It resets the files to
<code><?= escapeHtml("origin/$repo_branch") ?></code>, so local changes to them are lost.
<code>scripts/update_cli.php</code> in its own process - it updates the files and then
applies every pending migration, with no request timeout, as the user that owns the
files. It resets the files to <code><?= escapeHtml("origin/$repo_branch") ?></code>, so
local changes to them are lost. A migration that fails part way stops without advancing
the recorded version, so it is safe to queue again once the cause is fixed.
<?php if (!$cron_is_running) { ?>
<strong class="text-warning">Cron is not checking in, so a queued update will sit there
until it is.</strong>
<?php } ?>
<?php } else { ?>
<strong>Apply the database update below first.</strong> Queueing an update needs a schema
change this install has not caught up with yet. From a shell,
<code>php scripts/update_cli.php</code> does both in one step.
<strong>This install cannot queue yet.</strong> Queueing needs a schema change it has not
caught up with, so this one has to be started from a shell:
<code>php scripts/update_cli.php</code>, as the user that owns the files. It updates the
files and the database in one step, and Queue Update works from then on.
<?php } ?>
</small>
</p>
</div>
<?php } ?>
<?php if ($db_update_available) { ?>
<div class="mb-4">
<h6 class="text-uppercase text-secondary">Database</h6>
<p class="mb-2">
Schema is at <strong><?= escapeHtml(CURRENT_DATABASE_VERSION) ?></strong> and this code expects
<strong><?= escapeHtml(LATEST_DATABASE_VERSION) ?></strong>. Parts of the app will error until
this is applied.
</p>
<a class="btn btn-dark confirm-link" href="post.php?update_db&csrf_token=<?= $_SESSION['csrf_token'] ?>">
<i class="fas fa-fw fa-database me-2"></i>Update Database
</a>
<p class="text-muted mt-2 mb-0">
<small>
A large instance can take a minute or more. If it fails part way it stops without advancing
the recorded version, so it is safe to run again after fixing the cause.
</small>
</p>
</div>
<?php } ?>
<?php } ?>
<?php if ($app_update_available) { ?>