Files
fitme3070.pt/shared/platform-tools/ASSETS.md
T
andreandClaude Opus 5 4d40adbf64 Vendor platform-tools: everything this site runs is now in one repo
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>
2026-09-13 23:06:23 +01:00

3.5 KiB

Assets de front-end na frota andmore

Convenção fixada a 2026-09-01, quando os oito sites deixaram de carregar JavaScript e CSS de CDNs.

A regra

Nada de front-end sai para a rede em produção. Tudo é servido do próprio domínio, está no git, e tem a versão no nome da pasta.

public/vendor/<biblioteca>-<versão>/…      (o hub usa public/assets/vendor/,
                                            que é onde já tinha o Bootstrap)

Porquê, e não é gosto por arrumação:

  • um CDN em baixo leva o back-office com ele — e o CSS do Bootstrap a faltar não é «sem estilo», é uma página ilegível;
  • um CDN comprometido corre código de terceiros na sessão de quem está autenticado como administrador, e nenhuma destas tags tinha SRI;
  • e uma versão que vem de @1 ou @5.3 muda debaixo dos pés sem ninguém decidir nada.

De onde vem cada coisa

Composer, sempre que o pacote exista. Instala-se com composer require e copia-se o ficheiro de distribuição para public/vendor/:

twbs/bootstrap          → bootstrap-<versão>/{css,js}/
twbs/bootstrap-icons    → bootstrap-icons-<versão>/  (+ fonts/)
components/jquery       → jquery-<versão>/jquery.min.js

Vendorizado à mão, quando não há pacote. Descarrega-se uma vez, commita-se, e deixa-se um ORIGEM.md ao lado com o URL de origem e o comando para actualizar. É o caso do DataTables, Chart.js, Cropper, Flatpickr, SortableJS, html2canvas, qrcodejs, signature_pad, html5-qrcode, Font Awesome, jszip e pdfmake.

DataTables: build combinado, e porque não vem do composer

O único pacote no packagist é datatables/datatables, congelado na 1.10.21 (2020), que usa $.isArray e $.trim — ambas removidas na jQuery 4. Ir pelo composer prendia a frota à jQuery 3 para sempre.

Usa-se o build combinado do construtor oficial, que é um ficheiro com o core, os Buttons, o Responsive e a integração Bootstrap 5:

https://cdn.datatables.net/v/bs5/dt-2.3.4/b-3.2.6/r-3.0.6/datatables.min.js
https://cdn.datatables.net/v/bs5/dt-2.3.4/b-3.2.6/r-3.0.6/datatables.min.css

Substituiu até cinco <script> por site. Os botões de exportação (CSV, Excel, imprimir) já vêm lá dentro; só o jszip e o pdfmake ficam à parte, e só onde se exporta.

A armadilha, que já custou duas homes

base_url() não existe em todo o lado. Na fotografia e na mstudio, o site público (public/index.php, public/site/includes/head.php) não carrega o config/functions.php. Um <?= base_url('vendor/…') ?> ali dá fatal e a página passa a servir o ecrã de erro.

Usa sempre o caminho absoluto /vendor/…. O docroot é a raiz do domínio em todos os sites, portanto é equivalente, e funciona haja ou não bootstrap.

Não usar

  • is_file($local) ? $local : $cdn — não é uma rede de segurança. É a promessa de que, no dia em que um ficheiro faltar, a página vai buscar código a um terceiro sem ninguém dar por isso.
  • <link rel="preconnect"> para CDNs — não há para onde ligar.
  • Cópias sem versão no nome (assets/js/dataTables.min.js). Ninguém sabe qual é, e a próxima pessoa não tem como descobrir sem comparar bytes.
  • jQuery slim. Não traz $.ajax, e portanto nenhum DataTables em server-side processing funciona com ela. A dance esteve assim.

Estado a 2026-09-01

Todos os sites: jQuery 4.0.0 e DataTables 2.3.4. Zero CDN.

Continua a sair para a rede, por decisão à parte: o Google Fonts, em dance, fotografia, mstudio, silver, quack e design.