andreandClaude Opus 5
4d40adbf64
shared/platform-tools was a git submodule. On this branch it is a plain
directory of tracked files, frozen at ea3616abae30106df283e73a3e2f9e5bb0e6ae90
— the same commit fotografia.andmore.pt pins. Contents are byte-identical to
that tree, verified blob by blob.
The submodule caused every deployment failure this site has had:
- .gitmodules named no `branch`, so the update fell back to
refs/remotes/origin/HEAD — a ref a plain server-side clone never writes.
"Atualizar submódulo" failed with "Unable to find refs/remotes/origin/HEAD
revision in submodule path".
- Its URL was http://, which the origin answers with 523.
- This install is deployed by uploading files, and a submodule is invisible
to that. The tree moved forward while shared/platform-tools stayed on the
old pin, config/functions_secrets.php died on a missing compat_secrets.php,
and the whole site — public pages included — went down.
Each of those was separately fixable. Together they mean a second repository
nobody can see from the deployment path, gating whether the first one boots. A
plain directory deploys like every other file and cannot fall out of step.
The cost is that platform-tools updates no longer arrive by bumping a pin; they
are a copy-over-and-commit. shared/platform-tools/VENDORED.md records the
upstream SHA, the procedure, and which four files differ from upstream in line
endings only (social/*.js, .css, functions_publications.php — CRLF upstream,
normalised to LF here; content otherwise identical).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
78 lines
4.0 KiB
PHP
78 lines
4.0 KiB
PHP
<?php
|
||
// ─── Arranque partilhado dos endpoints do hub ────────────────────────────────
|
||
//
|
||
// Os três endpoints (health, ops, pair) são iguais em todas as plataformas, mas
|
||
// o arranque não é: a frota tem dois stacks. O `config/` (dance, design,
|
||
// fotografia, mstudio, quack, hub) abre a ligação em config/db.php e tem os
|
||
// helpers em config/functions.php; a silver usa `src/` com App\Database.
|
||
//
|
||
// Em vez de dezoito stubs com o arranque copiado — três endpoints × seis sites,
|
||
// e o dobro dos sítios onde uma correcção se esquece —, detecta-se aqui. Um
|
||
// site com um arranque próprio define $pdo antes de incluir isto e este ficheiro
|
||
// não lhe toca.
|
||
//
|
||
// ─── Plataformas sem base de dados ───────────────────────────────────────────
|
||
//
|
||
// O apex (andmore.pt) é uma montra estática: sem base de dados, sem sessão, sem
|
||
// autenticação, e montada read-only no contentor. Continua a ser uma plataforma
|
||
// da frota que vale a pena monitorizar — se estiver em baixo, é a primeira
|
||
// página que um cliente vê.
|
||
//
|
||
// Não pode é ser tratada como as outras. Aqui distingue-se **não ter** base de
|
||
// dados de **não conseguir** abri-la:
|
||
//
|
||
// nem config/db.php nem src/db.php existem → não há camada de dados nenhuma,
|
||
// é o desenho do site. Segue sem.
|
||
// um deles existe mas o $pdo não apareceu → avaria. 503, como antes.
|
||
//
|
||
// A distinção sai da presença dos ficheiros e não de um flag por site, porque um
|
||
// flag é uma coisa a mais para alguém pôr errada: um site com base de dados a
|
||
// arder responderia «sou estático, está tudo bem».
|
||
//
|
||
// Sem base de dados as chaves têm de vir do `.env` — o hub_setting_secret() já
|
||
// lê o .env primeiro, portanto não é caso especial nenhum; é o caminho normal
|
||
// sem o fallback.
|
||
//
|
||
// Deixa em cima da mesa: $pdo (ou null), $hub_has_db_layer, $repo_root, e o
|
||
// functions_hub.php carregado.
|
||
|
||
$repo_root = dirname(__DIR__, 2);
|
||
|
||
/** Este site tem sequer uma camada de dados? Ver a nota acima. */
|
||
$hub_has_db_layer = is_file($repo_root . '/config/db.php')
|
||
|| is_file($repo_root . '/src/db.php');
|
||
|
||
if (!isset($pdo) || !$pdo instanceof PDO) {
|
||
if (is_file($repo_root . '/config/db.php')) {
|
||
require_once $repo_root . '/config/db.php';
|
||
// Nem todas as plataformas carregam o functions.php a partir do db.php
|
||
// (a dsa e o hub carregam; a fotografia e o design não). O require_once
|
||
// sozinho não chega como guarda: quando o db.php o incluiu por outro
|
||
// caminho relativo, o realpath difere e o segundo include rebenta com
|
||
// "Cannot redeclare base_url()".
|
||
if (!function_exists('base_url') && is_file($repo_root . '/config/functions.php')) {
|
||
require_once $repo_root . '/config/functions.php';
|
||
}
|
||
} elseif (is_file($repo_root . '/src/db.php')) {
|
||
require_once $repo_root . '/src/config.php';
|
||
require_once $repo_root . '/src/db.php';
|
||
$pdo = \App\Database::getConnection();
|
||
}
|
||
}
|
||
|
||
require_once __DIR__ . '/functions_hub.php';
|
||
|
||
if ((!isset($pdo) || !$pdo instanceof PDO) && $hub_has_db_layer) {
|
||
// Este site TEM camada de dados e mesmo assim não chegou aqui um $pdo: é
|
||
// avaria, não desenho. Responder 401 daria a entender ao hub que a chave
|
||
// está errada quando o que falta é o arranque.
|
||
hub_json(['ok' => false, 'error' => 'esta plataforma não expôs uma ligação à base de dados ao endpoint do hub'], 503);
|
||
}
|
||
|
||
// Os endpoints leem-no como global (hub_pdo()); o $GLOBALS explícito cobre o
|
||
// caso de este ficheiro ser incluído de dentro de uma função num stub futuro.
|
||
// Numa plataforma estática fica a null de propósito — o hub_pdo() devolve null
|
||
// e quem depende de base de dados salta o seu check em vez de rebentar.
|
||
$GLOBALS['pdo'] = (isset($pdo) && $pdo instanceof PDO) ? $pdo : null;
|
||
$pdo = $GLOBALS['pdo'];
|