Files
KantSites/tests/TestSchema.php
T
kantarciandClaude Opus 5.5 e15b2517b1 Translate pages, areas, menus, forms and posts field by field instead of rebuilding them
A site can have further languages (Settings → Languages). A page is built once; each language
adds only its texts, keyed by the stable block IDs, plus its own address under /en/… (ADR 111,
document schema v27, migration 20261009000100 for page_translation).

- Editor: DE | EN switch, a list of all texts with original, state (missing, translated,
  original changed) and filter; structure stays with the main language. Undo, drafts,
  publishing and revisions cover all languages at once.
- Website: /en and translated slugs, lang, canonical, hreflang with x-default, og:locale,
  sitemap; links to translated pages follow the language; a language switch block.
- Header, footer and linked sections translate the same way; menu entries carry labels per
  language; fixed template texts come from a small dictionary.
- Forms: labels, help, options, button and success message per language; messages and the
  step script speak the language, the submission and the email stay in the main language.
- Posts, archives, category names, consent text and the 404 page follow the language.
- Single-language sites see none of it and never touch the new table.

The forms administration becomes an overview with one row per form and its own edit page;
fields are one line each with details collapsed.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-09 16:56:52 +02:00

71 lines
2.6 KiB
PHP

<?php
namespace App\Tests;
use Doctrine\DBAL\Connection;
use Doctrine\DBAL\Schema\Schema;
use DoctrineMigrations\Version20260912000100;
use DoctrineMigrations\Version20260912000200;
use DoctrineMigrations\Version20260912000300;
use DoctrineMigrations\Version20260912000400;
use DoctrineMigrations\Version20260912000500;
use DoctrineMigrations\Version20260912000600;
use DoctrineMigrations\Version20260912000700;
use DoctrineMigrations\Version20260912000800;
use DoctrineMigrations\Version20260912000900;
use DoctrineMigrations\Version20260912001000;
use DoctrineMigrations\Version20260912001100;
use DoctrineMigrations\Version20260912001200;
use DoctrineMigrations\Version20260912001300;
use DoctrineMigrations\Version20260913000100;
use DoctrineMigrations\Version20260914000100;
use DoctrineMigrations\Version20260915000100;
use DoctrineMigrations\Version20260916000100;
use DoctrineMigrations\Version20260917000100;
use DoctrineMigrations\Version20261009000100;
use Psr\Log\NullLogger;
/**
* The schema a migrated installation has, built for a fresh test database.
*
* The list used to stand in three places, so a new migration was three edits and the fixtures
* drifted apart. It stands here once. Indexes come from the same postUp() helpers the migrations
* use, because on SQLite an index added the ordinary way rebuilds the table.
*/
final class TestSchema
{
public static function build(Connection $db): void
{
$schema = new Schema();
foreach ([
Version20260912000100::class,
Version20260912000200::class,
Version20260912000300::class,
Version20260912000400::class,
Version20260912000500::class,
Version20260912000600::class,
Version20260912000700::class,
Version20260912000800::class,
Version20260912000900::class,
Version20260912001000::class,
Version20260912001100::class,
Version20260912001200::class,
Version20260912001300::class,
Version20260913000100::class,
Version20260914000100::class,
Version20260915000100::class,
Version20260916000100::class,
Version20260917000100::class,
Version20261009000100::class,
] as $migration) {
(new $migration($db, new NullLogger()))->up($schema);
}
foreach ($schema->toSql($db->getDatabasePlatform()) as $sql) {
$db->executeStatement($sql);
}
Version20260912000400::applyIndexes($db);
Version20260912000600::applyIndexes($db);
Version20260912000900::applyIndexes($db);
}
}