fix(admin): move dump modals into sw-page #content slot so delete works on 6.7

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

.config/shopware-extension.yml

@@ -14,6 +14,8 @@ build:
           - AGENTS.md
           - CLAUDE.md
           - QWEN.md
+          - .config
+          - .gitea
           - .claude
           - .scratch
           - .wayfinder

.gitea/workflows/plugin-checks.yml

@@ -22,26 +22,24 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v4
-        with:
-          fetch-depth: 0
 
-      - name: Check version bump and changelog entry
+      # The version must be higher than the latest *published release* (not just higher than main), so main can
+      # carry a version whose release failed or was withdrawn without blocking the next PR.
+      - name: Check version is unreleased and changelog entry exists
+        env:
+          TOKEN: ${{ secrets.RELEASE_TOKEN }}
         run: |
           set -e
           PR_VERSION=$(grep -m1 '"version"' composer.json | sed -E 's/.*"version"[[:space:]]*:[[:space:]]*"([^"]+)".*/\1/')
-          MAIN_VERSION=$(git show origin/main:composer.json | grep -m1 '"version"' | sed -E 's/.*"version"[[:space:]]*:[[:space:]]*"([^"]+)".*/\1/')
+          LATEST=$(curl -sf -H "Authorization: token ${TOKEN}" "${GITHUB_SERVER_URL}/api/v1/repos/${GITHUB_REPOSITORY}/releases?limit=100" \
+            | jq -r '.[].tag_name' | sed 's/^v//' | sort -V | tail -n1)
+          LATEST="${LATEST:-0.0.0}"
 
-          echo "main version: $MAIN_VERSION"
+          echo "latest release: $LATEST"
           echo "PR version:     $PR_VERSION"
 
-          if [ "$MAIN_VERSION" = "$PR_VERSION" ]; then
+          if [ "$PR_VERSION" = "$LATEST" ] || [ "$(printf '%s\n%s\n' "$LATEST" "$PR_VERSION" | sort -V | tail -n1)" != "$PR_VERSION" ]; then
-            echo "::error::composer.json version ($PR_VERSION) was not bumped from main ($MAIN_VERSION)"
+            echo "::error::composer.json version ($PR_VERSION) is not greater than the latest release ($LATEST)"
-            exit 1
-          fi
-
-          HIGHEST=$(printf '%s\n%s\n' "$MAIN_VERSION" "$PR_VERSION" | sort -V | tail -n1)
-          if [ "$HIGHEST" != "$PR_VERSION" ]; then
-            echo "::error::composer.json version ($PR_VERSION) is not greater than main's ($MAIN_VERSION)"
             exit 1
           fi
 
@@ -50,7 +48,7 @@ jobs:
             exit 1
           fi
 
-          echo "OK: version bumped to $PR_VERSION and documented in CHANGELOG.md"
+          echo "OK: $PR_VERSION is unreleased and documented in CHANGELOG.md"
 
   # Packages the extension (builds admin/storefront assets) and validates the resulting zip,
   # which is the artifact that ships. A separate directory validate would only repeat these checks.
@@ -98,28 +96,41 @@ jobs:
       - uses: actions/checkout@v4
         with:
           path: plugin-src
-      - name: Month stamp (refreshes the cached project monthly)
+      # The cache key follows the Shopware version: a new release inside the plugin's supported range changes
-        id: stamp
+      # the key, so the old project + database are never reused. Bump -v1 to force a refresh by hand.
-        run: echo "month=$(date +%Y-%m)" >> "$GITHUB_OUTPUT"
+      - name: Resolve the latest Shopware Version
-      # The project (incl. vendor/ and phpunit) does not depend on the plugin, so it is cached on its own.
+        id: sw
-      - name: Restore prepared Shopware project
-        id: project
-        uses: actions/cache/restore@v4
-        with:
-          path: shopware
-          key: shopware-6.6-prepared-${{ steps.stamp.outputs.month }}
-      - name: Create Shopware 6.6 project
-        if: steps.project.outputs.cache-hit != 'true'
         run: |
           set -e
-          composer create-project shopware/production:6.6.* shopware --no-interaction --no-scripts
+          # The plugin's own constraint (require.shopware/core, e.g. ~6.6.0) decides which versions are acceptable;
-          composer require --dev phpunit/phpunit:^10 --no-interaction --no-scripts -d shopware
+          # Composer lists the matching ones newest first, the first stable one is the latest.
-      - name: Save prepared Shopware project
+          CONSTRAINT=$(php -r 'echo json_decode(file_get_contents("plugin-src/composer.json"), true)["require"]["shopware/core"];')
-        if: steps.project.outputs.cache-hit != 'true'
+          VERSION=$(composer show shopware/core "$CONSTRAINT" --all --format=json --no-interaction 2>/dev/null \
-        uses: actions/cache/save@v4
+            | php -r '$d = json_decode(stream_get_contents(STDIN), true); foreach ($d["versions"] as $v) { if (preg_match("/^v?\d+(\.\d+)+$/", $v)) { echo ltrim($v, "v"); exit; } }')
+          test -n "$VERSION" || { echo "::error::could not resolve a Shopware version for ${CONSTRAINT}"; exit 1; }
+          echo "Shopware ${VERSION} (constraint ${CONSTRAINT})"
+          echo "version=${VERSION}" >> "$GITHUB_OUTPUT"
+      # Project (vendor/, phpunit, config) and the installed database as a SQL dump. Neither depends on the plugin.
+      - name: Restore Shopware project and database
+        id: shopware
+        uses: actions/cache/restore@v4
         with:
-          path: shopware
+          path: |
-          key: shopware-6.6-prepared-${{ steps.stamp.outputs.month }}
+            shopware
+            !shopware/var/cache
+            !shopware/var/log
+            shopware-db.sql.gz
+          key: shopware-${{ steps.sw.outputs.version }}-installed-v1
+      - name: Create Shopware project
+        if: steps.shopware.outputs.cache-hit != 'true'
+        run: |
+          set -e
+          composer create-project "shopware/production:${{ steps.sw.outputs.version }}" shopware --no-interaction --no-scripts
+          composer require --dev phpunit/phpunit:^10 --no-interaction --no-scripts -d shopware
+      - name: Ensure the MariaDB client
+        run: |
+          command -v mariadb-dump >/dev/null || command -v mysqldump >/dev/null && exit 0
+          (apt-get update -q && apt-get install -y -q --no-install-recommends mariadb-client) || apk add --no-cache mariadb-client
       - name: Wait for the database
         run: |
           for i in $(seq 60); do
@@ -127,9 +138,39 @@ jobs:
             sleep 2
           done
           echo "::error::database service did not come up"; exit 1
-      - name: Relax database durability (throwaway CI database, speeds up the migrations)
+      - name: Relax database durability (throwaway CI database, speeds up the install and the restore)
         run: |
           php -r '$p = new PDO("mysql:host=database;port=3306", "root", "root"); $p->exec("SET GLOBAL innodb_flush_log_at_trx_commit=0"); $p->exec("SET GLOBAL sync_binlog=0");'
+      # One install into shopware_test; the bootstrapper then sees an installed DB, skips its own install and
+      # only activates the plugin (tests/TestBootstrap.php forces plugin installation).
+      - name: Install Shopware
+        if: steps.shopware.outputs.cache-hit != 'true'
+        working-directory: shopware
+        run: bin/console system:install --basic-setup --create-database --force --no-interaction
+      - name: Dump the installed database
+        if: steps.shopware.outputs.cache-hit != 'true'
+        run: |
+          set -e
+          DUMP=$(command -v mariadb-dump || command -v mysqldump)
+          "$DUMP" -h database -P 3306 -u root -proot --skip-ssl --single-transaction --routines --triggers \
+            --databases shopware_test | gzip > shopware-db.sql.gz
+          ls -l shopware-db.sql.gz
+      - name: Save Shopware project and database
+        if: steps.shopware.outputs.cache-hit != 'true'
+        uses: actions/cache/save@v4
+        with:
+          path: |
+            shopware
+            !shopware/var/cache
+            !shopware/var/log
+            shopware-db.sql.gz
+          key: shopware-${{ steps.sw.outputs.version }}-installed-v1
+      - name: Restore the database from the cache
+        if: steps.shopware.outputs.cache-hit == 'true'
+        run: |
+          set -e
+          CLIENT=$(command -v mariadb || command -v mysql)
+          gunzip -c shopware-db.sql.gz | "$CLIENT" -h database -P 3306 -u root -proot --skip-ssl
       - name: Resolve plugin name and install the plugin sources
         run: |
           # plugin directory name = short class name of extra.shopware-plugin-class
@@ -138,11 +179,6 @@ jobs:
           echo "PLUGIN_NAME=${PLUGIN_NAME}" >> "$GITHUB_ENV"
           rm -rf "shopware/custom/plugins/${PLUGIN_NAME}"
           cp -r plugin-src "shopware/custom/plugins/${PLUGIN_NAME}"
-      # One install into shopware_test; the bootstrapper sees an installed DB, skips its own install and
-      # only activates the plugin (tests/TestBootstrap.php forces plugin installation).
-      - name: Install Shopware (once)
-        working-directory: shopware
-        run: bin/console system:install --basic-setup --create-database --force --no-interaction
       - name: Run phpunit
         working-directory: shopware
         run: vendor/bin/phpunit -c "custom/plugins/${PLUGIN_NAME}/phpunit.xml"

.gitea/workflows/release.yml

@@ -126,7 +126,8 @@ jobs:
           fi
           test -f "$ROOT/composer.json" || { echo "::error::no composer.json found in the packaged zip"; exit 1; }
           OUT="$PWD/.build/composer-${{ steps.meta.outputs.zip }}"
-          (cd "$ROOT" && zip -qr "$OUT" .)
+          # explicit file list with the leading "./" stripped, so entries are stored as "composer.json", "src/..."
+          (cd "$ROOT" && find . -mindepth 1 | sed 's|^\./||' | zip -q "$OUT" -@)
           unzip -l "$OUT" | grep -E ' composer\.json$' > /dev/null || { echo "::error::repacked zip has no root-level composer.json"; exit 1; }
           echo "repacked: $OUT"
 

.gitignore

@@ -14,7 +14,7 @@ composer.phar
 
 # Frontend
 *.vite/
-**/public/administration/js/
+**/public/administration/assets/
 **/public/static/js/
 
 # Environment

CHANGELOG.md

@@ -7,26 +7,42 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
-## [0.1.1] - 2026-10-04
+## [0.1.0] - 2026-11-02
+
+### Changed
+
+- Requires Shopware 6.7 (`shopware/core ~6.7.0`); 6.6 stays on the 0.0.x line.
+- Administration: the list page is registered lazily, uses Meteor components (`mt-button`, `mt-banner`, `mt-progress-bar`) and stops polling on `beforeUnmount` (Vue 3).
 
 ### Fixed
 
-- Release pipeline: the Composer registry rejected the packaged zip (`composer.json file is missing`) because `shopware-cli` zips wrap everything in a top-level folder. The same prebuilt content is now repacked root-level for the registry upload.
+- The admin build failed on a combined `import type` statement, so the Settings card never appeared.
-- Release steps are idempotent (existing release and asset are reused, registry 409 counts as published) and the "tag exists -> skip" guard is gone, so a failed release can be re-run to completion.
+- Delete did nothing and the create progress modal never showed: both modals sat outside `sw-page`'s named slots, which Vue 3 drops. They now live in `#content`.
+- Creating a dump failed on MariaDB when only MySQL 8's `mysqldump` was installed (`Unknown table 'COLUMN_STATISTICS'`); it now passes `--column-statistics=0` in that case.
 
-## [0.1.0] - 2026-10-03
+### Removed
+
+- The Settings sidebar navigation entry; the plugin is reached through its card in Settings → System, like core settings modules.
+
+## [0.0.6] - 2026-10-04
 
 ### Changed
 
 - Services and routes are now configured in YAML; the plugin requires PHP `^8.2`.
-- Release pipeline: the packaged `shopware-cli` zip (with prebuilt assets) is validated and used for both the Gitea Release and the Composer registry; the release is created through the Gitea API after packaging, so a failed build no longer leaves an orphan tag.
+- Release pipeline: the packaged `shopware-cli` zip (with prebuilt assets) is validated and used for the Gitea Release; the Composer registry gets the same content repacked root-level (Gitea requires `composer.json` at the zip root). The release is created through the Gitea API after packaging, so a failed build no longer leaves an orphan tag.
-- New PR checks: `shopware-cli` validate, package build and phpunit.
+- New PR checks: `shopware-cli` validate, package build and phpunit (with a cached Shopware project and database).
+- The PR version check compares against the latest published release instead of the version on `main`.
 
 ### Added
 
 - Dedicated `aeon_dump_manager` monolog channel; dump jobs, deletions and purges are logged.
 - Extension icon and `.config/shopware-extension.yml`.
 
+### Fixed
+
+- The packaged zip no longer contains `.gitea/` and `.config/`.
+- Release steps are idempotent (existing release and asset are reused, registry 409 counts as published), so a failed release can be re-run to completion.
+
 ### Removed
 
 - Empty plugin lifecycle overrides.

CLAUDE.md

@@ -53,9 +53,11 @@ activates this plugin inside a real Shopware kernel for the test run (`KERNEL_CL
 `Shopware\Core\Kernel` in `phpunit.xml`). This means tests require a working Shopware installation/DB
 to bootstrap against — they are not runnable as an isolated PHP package.
 
-In CI (`phpunit` job) a Shopware 6.6 project is prepared once (`composer create-project` + phpunit,
+In CI (`phpunit` job) the latest Shopware version allowed by the plugin's `require.shopware/core` constraint
-cached monthly), the plugin is copied into `custom/plugins`, and `system:install` runs once into
+is resolved with Composer. The prepared project (`composer create-project` + phpunit, then `system:install`
-`shopware_test` (MariaDB 10.11 service), so the bootstrapper only activates the plugin.
+into `shopware_test` on a MariaDB 10.11 service) plus a SQL dump of the installed database are cached under
+a key that contains that version, so a new Shopware release invalidates the cache. On a hit the dump is restored instead of reinstalling; the plugin
+is then copied into `custom/plugins` and the bootstrapper only activates it.
 
 ```bash
 vendor/bin/phpunit                              # full suite
@@ -65,7 +67,7 @@ vendor/bin/phpunit tests/SomeTest.php            # single file
 
 ## Dependencies
 
-- PHP `^8.2`, `shopware/core` `~6.6.0` (from `composer.json`); `phpunit/phpunit` `^10.0` as the only
+- PHP `^8.2`, `shopware/core` `~6.7.0` (from `composer.json`); `phpunit/phpunit` `^10.0` as the only
   dev dependency.
 - PSR-4 autoload: `AeonDumpManager\` → `src/`, `AeonDumpManager\Tests\` → `tests/`.
 
@@ -75,8 +77,9 @@ Gitea workflows in `.gitea/`, plugin-agnostic (name/version come from `composer.
 runs from its official Docker image, intentionally unpinned (`latest`): a red build after a CLI release
 means fix the config.
 
-- `workflows/plugin-checks.yml` (PRs into `main`) has three jobs: `version-changelog` (every PR into
+- `workflows/plugin-checks.yml` (PRs into `main`) has three jobs: `version-changelog` (the
-  `main` must bump `composer.json` version and add a matching `## [x.y.z]` CHANGELOG heading), `package`
+  `composer.json` version must be greater than the latest published Gitea release and have a matching
+  `## [x.y.z]` CHANGELOG heading), `package`
   (shared composite action `actions/package`: `shopware-cli extension package`, `extension validate` on
   the zip, `scripts/ci/assert-built-assets.sh`), and `phpunit`. The package job caches the tested zip
   keyed by the commit's tree hash.

composer.json

@@ -3,7 +3,7 @@
     "description": "Export database dumps for Shopware 6 environments.",
     "type": "shopware-platform-plugin",
     "license": "MIT",
-    "version": "0.1.1",
+    "version": "0.1.0",
     "keywords": [
         "shopware",
         "shopware6",
@@ -26,7 +26,7 @@
     },
     "require": {
         "php": "^8.2",
-        "shopware/core": "~6.6.0"
+        "shopware/core": "~6.7.0"
     },
     "require-dev": {
         "phpunit/phpunit": "^10.0"

docker-compose.yml

@@ -1,6 +1,6 @@
 services:
   shopware:
-    image: dockware/shopware:6.6.10.12
+    image: dockware/shopware:6.7.14.2
     container_name: shopware
     ports:
       - "80:80"       # Shop / Admin / Adminer / Mailcatcher (all served via path on this port)

docs/research/changelog-and-php-floor.md

@@ -0,0 +1,167 @@
+# Research: shopware-cli changelog handling and the PHP floor for a Shopware 6.6 plugin
+
+Sources are primary only: `shopware/shopware-cli` source (main branch, fetched 2026-10-04),
+`shopware/docs` (the repo behind developer.shopware.com, main), and `shopware/shopware` tags.
+Paths below are relative to those repos. Refs are branch heads or tags as noted; no commit SHAs
+were pinned.
+
+## Summary
+
+- **`extension package --release` does not parse CHANGELOG.md.** It only generates one, from git commits, and only if `changelog.enabled: true` is set in `.config/shopware-extension.yml`. Our pipeline does not pass `--release`.
+- **Parsing happens elsewhere:** in `account producer extension upload` (Store push) and in `extension get-changelog`. The parser treats every line starting with `#` as a version key.
+- **Our Keep-a-Changelog file is not compatible with that parser.** The key becomes `# [0.1.0] - 2026-10-03`, never `0.1.0`, so the Store upload would fail with "english changelog is missing". This only matters if we later use `account producer extension upload`; today we publish to Gitea and a Composer registry.
+- **Minimal fix if we ever upload to the Store:** add `CHANGELOG_en-GB.md` with `# x.y.z` headings and flat bullets, with no `###` sub-headings. Keep `CHANGELOG.md` for humans; the localized file wins for `en-GB`.
+- **PHP:** Shopware 6.6.x requires `~8.2.0 || ~8.3.0 || ~8.4.0 || ~8.5.0` (6.6.0.0 was `~8.2.0 || ~8.3.0`). Our `php: ^8.2` is consistent but broader than core; it is harmless because `shopware/core ~6.6.0` already pins the effective range.
+- **Recommendation:** keep `^8.2` or use `>=8.2`. Do not copy core's tilde list. Shopware's own docs skeleton declares no `php` at all, only `shopware/core`.
+
+## Q1. Changelog handling
+
+### 1.1 What the parser does (verified in source)
+
+File: `internal/extension/changelog.go` (shopware-cli, main).
+
+File discovery and locale:
+
+```go
+files, err := filepath.Glob(path + "/CHANGELOG*.md")
+...
+language := strings.Trim(strings.ReplaceAll(strings.ReplaceAll(filepath.Base(file), "CHANGELOG", ""), ".md", ""), "_")
+if len(language) == 0 { language = "en-GB" }
+```
+
+- `CHANGELOG.md` maps to `en-GB`.
+- `CHANGELOG_en-GB.md` maps to `en-GB`, and `CHANGELOG_de-DE.md` maps to `de-DE`.
+- If both `CHANGELOG.md` and `CHANGELOG_en-GB.md` exist, both land in the same map slot. `filepath.Glob` returns lexically sorted names and `.` sorts before `_`, so `CHANGELOG_en-GB.md` is processed last and overwrites. This ordering is inferred from Go's documented sorted-directory behaviour; I did not run it.
+
+Section splitting (`parseMarkdownChangelog`):
+
+```go
+for _, line := range strings.Split(content, "\n") {
+    if strings.HasPrefix(line, "#") {
+        ...
+        currentVersion = strings.Trim(strings.TrimPrefix(line, "#"), " ")
+```
+
+- Every line that starts with `#`, at any heading depth, starts a new "version" section.
+- The key is the line minus one leading `#`, with spaces trimmed. Only a single `#` is removed.
+- The body is converted to HTML with goldmark via `internal/markdown`. Headings inside bodies are rendered as `<span class="hN">`.
+- Upstream's own tests use this exact shape: `"# 1.0.0\n\n- Test\n- Test2\n# 2.0.0\n- Test3\n- Test4\n"` (`internal/extension/changelog_test.go`).
+
+Version lookup (`parseExtensionMarkdownChangelog`):
+
+- The key looked up is `ext.GetVersion().String()`, which is the plain version from `composer.json`, for example `0.1.0`.
+- `changelogs["en-GB"][version]` must exist, or it returns an error ("english changelog is missing").
+- `de-DE` is optional and falls back to the English file. If a `de-DE` file exists but lacks the version, it errors.
+- The docs agree: "The zip file contains a `CHANGELOG*.md` file with a changelog entry for the new version. Having a German changelog is optional." (`products/tools/cli/shopware-account-commands/releasing-extension-to-shopware-store.md`).
+
+### 1.2 Where it is used
+
+`GetChangelog()` is called in only two non-test places:
+
+- `internal/account-api/producer_store_upload.go`: `account producer extension upload` sends `de_DE` and `en_GB` texts as the Store changelog.
+- `cmd/extension/extension_changelog.go`: `extension get-changelog`.
+
+Not called from `cmd/extension/extension_package.go`, nor from validation: no `changelog` reference was found under `internal/validation`.
+
+### 1.3 What `--release` does
+
+`cmd/extension/extension_package.go`:
+
+```go
+extensionPackageCmd.Flags().BoolVar(&extensionReleaseMode, "release", false, "Prepare a release build: generate the changelog if enabled and, for apps, remove the secret from manifest.xml")
+```
+
+`internal/extension/zip.go`, `PrepareExtensionForRelease`:
+
+```go
+if ext.GetExtensionConfig().Changelog.Enabled {
+    ...
+    changelogFile := fmt.Sprintf("# %s\n%s", v.String(), content)
+    os.WriteFile(path.Join(extensionRoot, "CHANGELOG_en-GB.md"), ...)
+}
+if ext.GetType() == "plugin" { return nil }
+// apps only: remove setup/secret from manifest.xml
+```
+
+- **Added:** a generated `CHANGELOG_en-GB.md`, containing `# <version>` plus one bullet per git commit between the last tag and the current commit (template `internal/changelog/changelog.tpl`). It only happens if `changelog.enabled: true`. The default is false (`internal/changelog/changelog.go`, `Enabled bool`).
+- **Stripped:** the app secret in `manifest.xml`. This does not apply to plugins, which return early.
+- **Not stripped or rewritten:** an existing `CHANGELOG.md` is left untouched. When enabled, the generated file overwrites any existing `CHANGELOG_en-GB.md`.
+- This confirms `# x.y.z` is the format the tool itself writes.
+- Docs on release mode and `changelog.enabled`: `products/tools/cli/extension-commands/build.md`, "Release mode" section.
+
+### 1.4 Our repo
+
+- `.gitea/actions/package/action.yml:29` runs `shopware-cli extension package . --output-directory .build --filename ... --git-commit "$GITHUB_SHA"`. There is no `--release`, and no `changelog:` key was found in `.config` or `.gitea`.
+- The release notes come from our own awk in `.gitea/workflows/release.yml`, which matches `## [x.y.z]`. That is independent of shopware-cli.
+- `CHANGELOG.md` uses `## [0.1.0] - 2026-10-03` and `### Added/Changed/...`.
+
+### 1.5 Compatibility verdict
+
+Walking `CHANGELOG.md` through `parseMarkdownChangelog` by hand (not executed):
+
+- `## [0.1.0] - 2026-10-03` gives key `# [0.1.0] - 2026-10-03`, which never equals `0.1.0`.
+- Each `### Added` and similar heading becomes its own bogus "version", so the entries under it are split off.
+
+Result: **incompatible.** `account producer extension upload` and `extension get-changelog` would fail with "english changelog is missing". `extension package`, with or without `--release`, would not fail, because it does not call the parser. `extension validate` does not parse it either, as far as I could find.
+
+Minimal change, only needed if we adopt Store upload:
+
+```markdown
+# 0.1.0
+
+- Services and routes are now configured in YAML; the plugin requires PHP `^8.2`.
+- Release pipeline: ...
+```
+
+- Put it in `CHANGELOG_en-GB.md` at the plugin root, with one `# <exact composer version>` section per release and flat bullets. Prefix bullets with Added/Changed/Fixed if the categories matter.
+- No `###` sub-headings, and no brackets or dates in the heading.
+- `CHANGELOG_de-DE.md` is optional.
+- The alternative is to enable `changelog.enabled: true` plus `--release` and let the CLI generate it from commits. That would not use our hand-written entries.
+- The packaged zip must contain the file. I did not verify whether `.config/shopware-extension.yml` pack excludes would remove it.
+
+Not verified: the Store's own server-side handling of the changelog HTML. The CLI source only shows what is sent (`de_DE`/`en_GB` text), not what the Store renders. The Store API and backend are not public.
+
+## Q2. PHP constraint
+
+### 2.1 What Shopware 6.6 requires
+
+`require.php` in `shopware/shopware` `src/Core/composer.json` and the root `composer.json`:
+
+| Ref | `require.php` |
+|---|---|
+| `v6.6.0.0` | `"php": "~8.2.0 \|\| ~8.3.0"` |
+| `v6.6.10.28` (latest 6.6 tag seen) | `"php": "~8.2.0 \|\| ~8.3.0 \|\| ~8.4.0 \|\| ~8.5.0"` |
+
+- The `v6.6.10.28` root `composer.json` has the same line as core.
+- A fetch of the `6.6.x` branch-head `composer.json` returned no usable content, so only the two tags above are verified.
+- Official docs, `guides/hosting/index.md` ("Recommended stack and supported versions"): PHP minimum `8.2+`, recommended `8.4`.
+- `guides/development/dev-environment.md`: "PHP Version | `8.2`, `8.3`, `8.4`, `8.5`".
+- Fetching the rendered developer.shopware.com requirements page returned no PHP row. It defers to the hosting guide, which is the source above.
+- The repo's own `CLAUDE.md` says PHP `^8.1`. That is stale for 6.6, since core requires 8.2+. It is outside this task's scope.
+
+### 2.2 Is `php: ^8.2` right?
+
+`composer.json` today:
+
+```json
+"require": { "php": "^8.2", "shopware/core": "~6.6.0" }
+```
+
+- `^8.2` means `>=8.2.0 <9.0.0`. It is consistent with core's floor.
+- It is wider than core's ceiling (`<8.6`). The plugin's PHP range is the intersection of its own constraint and core's. Because `shopware/core ~6.6.0` is also required, Composer resolves to core's tilde list anyway. The plugin constraint adds no extra restriction in practice.
+- Copying core's `~8.2.0 || ~8.3.0 || ~8.4.0 || ~8.5.0` would only make sense if the plugin itself breaks on a specific PHP minor. That would also force a release every time Shopware adds a PHP minor.
+- Practical conclusion: `^8.2` is fine and not too strict. `>=8.2` behaves the same in practice. The only real argument for changing it is wanting the plugin's PHP floor to stay visible in its own metadata, which `^8.2` already does.
+
+### 2.3 What Shopware's skeletons recommend
+
+- `guides/plugins/plugins/creating-plugins.md` (docs repo): the example plugin `composer.json` has only `"require": { "shopware/core": "~6.7.0" }`. There is no `php` key, and "Depending on other plugins" repeats the same shape.
+- shopware-cli's scaffolding (`internal/extension/create.go`) does not set a `php` constraint; the only `"php"` hit in that package is a test fixture, `internal/extension/root_test.go:233`, with `">=8.1"`.
+- So the official guidance is to constrain `shopware/core` and leave PHP to core. A plugin `php` constraint is optional. If you want one, mirroring the supported floor (`>=8.2` or `^8.2`) is reasonable.
+- I did not find a `SwagPluginSkeleton` repo (fetching `shopware/SwagPluginSkeleton` returned 404).
+
+## Could not verify
+
+- That the Store's server-side processing matches what the CLI sends. The Store backend is not public.
+- That `.config/shopware-extension.yml` pack excludes would keep or remove a `CHANGELOG_en-GB.md` in the zip.
+- The exact ordering behaviour of `filepath.Glob` for the two `en-GB` files was inferred from Go's documented sorted results, not run.
+- No source evidence of whether the Store accepts HTML headings; the CLI renders headings as `<span class="hN">` per a comment in `internal/markdown`.

scripts/ci/assert-built-assets.sh

@@ -13,5 +13,5 @@ check() { # <label> <entry-glob-prefix> <expected path in zip>
   fi
 }
 
-check admin src/Resources/app/administration/src "Resources/public/administration/js/"
+check admin src/Resources/app/administration/src "Resources/public/administration/assets/"
 check storefront src/Resources/app/storefront/src "Resources/app/storefront/dist/"

src/Resources/app/administration/src/module/aeon-dump-manager/index.ts

@@ -1,8 +1,10 @@
 import './acl';
-import './page/aeon-dump-manager-list';
 import deDE from './snippet/de-DE.json';
 import enGB from './snippet/en-GB.json';
 
+// Lazy (async) registration, as core does: the page chunk loads on first visit.
+Shopware.Component.register('aeon-dump-manager-list', () => import('./page/aeon-dump-manager-list'));
+
 Shopware.Module.register('aeon-dump-manager', {
     type: 'plugin',
     name: 'DumpManager',
@@ -27,27 +29,10 @@ Shopware.Module.register('aeon-dump-manager', {
         },
     },
 
-    // Per https://developer.shopware.com/docs/v6.6/guides/plugins/plugins/administration/routing-navigation/add-menu-entry.html —
+    settingsItem: [{
-    // plugins can't register a first-level main-menu entry, so this nests
+        group: 'plugins',
-    // under the core 'sw-settings' navigation node. Clicking Settings in the
-    // main sidebar shows this as a sub-item, landing at #/sw/settings/.
-    navigation: [{
-        id: 'aeon-dump-manager-list',
-        label: 'aeon-dump-manager.general.mainMenuItemGeneral',
-        color: '#ff3d58',
-        path: 'aeon.dump.manager.list',
-        icon: 'regular-database',
-        parent: 'sw-settings',
-        position: 100,
-        privilege: 'aeon_dump_manager.viewer',
-    }],
-
-    // Also shown as a card on the Settings overview page's "System" group,
-    // next to Plugins/Cache — complements the navigation entry above.
-    settingsItem: {
-        group: 'system',
         to: 'aeon.dump.manager.list',
         icon: 'regular-database',
         privilege: 'aeon_dump_manager.viewer',
-    },
+    }],
 });

src/Resources/app/administration/src/module/aeon-dump-manager/page/aeon-dump-manager-list/aeon-dump-manager-list.html.twig

@@ -1,7 +1,7 @@
 {% block aeon_dump_manager_list %}
 <sw-page class="aeon-dump-manager-list">
     <template #smart-bar-actions>
-        <sw-button
+        <mt-button
             v-if="acl.can('aeon_dump_manager.creator')"
             variant="primary"
             :is-loading="pendingJob !== null"
@@ -9,7 +9,7 @@
             @click="onCreate"
         >
             {{ $tc('aeon-dump-manager.list.buttonCreate') }}
-        </sw-button>
+        </mt-button>
     </template>
 
     <template #content>
@@ -75,8 +75,8 @@
                 </template>
             </sw-data-grid>
         </div>
-    </template>
 
+        <!-- sw-page has no default slot (Vue 3 drops unslotted content): modals must live in #content. -->
         {% block aeon_dump_manager_list_progress_modal %}
         <sw-modal
             v-if="pendingJob !== null"
@@ -87,18 +87,18 @@
         >
             <div class="aeon-dump-manager-list__progress-wrapper">
                 <template v-if="pendingJob.status === 'done'">
-                <sw-alert variant="success">
+                    <mt-banner variant="positive">
                         {{ $tc('aeon-dump-manager.list.createSuccess') }}
-                </sw-alert>
+                    </mt-banner>
                 </template>
                 <template v-else-if="pendingJob.status === 'failed'">
-                <sw-alert variant="error">
+                    <mt-banner variant="critical">
                         {{ $tc('aeon-dump-manager.list.createFailed', 0, { error: pendingJob.errorMessage || '' }) }}
-                </sw-alert>
+                    </mt-banner>
                 </template>
                 <template v-else>
-                <sw-progress-bar
+                    <mt-progress-bar
-                    :value="pendingJob.percent || 0"
+                        :model-value="pendingJob.percent || 0"
                         :max-value="100"
                     />
                     <span class="aeon-dump-manager-list__progress-text">
@@ -120,5 +120,6 @@
             @cancel="onCancelDelete"
             @close="onCancelDelete"
         />
+    </template>
 </sw-page>
 {% endblock %}

src/Resources/app/administration/src/module/aeon-dump-manager/page/aeon-dump-manager-list/index.ts

@@ -1,7 +1,8 @@
 import template from './aeon-dump-manager-list.html.twig';
-import type DumpApiService, { DumpFile, DumpJob } from '../../../../service/dump-api.service';
+import type DumpApiService from '../../../../service/dump-api.service';
+import type { DumpFile, DumpJob } from '../../../../service/dump-api.service';
 
-const { Component, Mixin } = Shopware;
+const { Mixin } = Shopware;
 
 interface PendingJob {
     status: string;
@@ -45,7 +46,7 @@ interface ComponentInstance extends ComponentData {
     listFilters: Record<string, unknown>[];
 }
 
-Component.register('aeon-dump-manager-list', {
+export default Shopware.Component.wrapComponentConfig({
     template,
 
     mixins: [
@@ -147,7 +148,7 @@ Component.register('aeon-dump-manager-list', {
         },
     },
 
-    beforeDestroy(this: ComponentInstance) {
+    beforeUnmount(this: ComponentInstance) {
         this.stopPolling();
     },
 

src/Service/DumpBinaryLocator.php

@@ -6,6 +6,7 @@ use AeonDumpManager\Service\Exception\DumpBinaryNotFoundException;
 use Doctrine\DBAL\Connection;
 use Shopware\Core\System\SystemConfig\SystemConfigService;
 use Symfony\Component\Process\ExecutableFinder;
+use Symfony\Component\Process\Process;
 
 /**
  * Picks mariadb-dump/mysqldump depending on what the configured DB connection
@@ -38,6 +39,19 @@ class DumpBinaryLocator
         throw DumpBinaryNotFoundException::create($binaryNames);
     }
 
+    /**
+     * @return list<string> client-specific flags for the located binary
+     */
+    public function extraArguments(string $binary): array
+    {
+        $version = new Process([$binary, '--version']);
+        $version->run();
+
+        return MySqlVariant::needsColumnStatisticsOff($version->getOutput(), $this->isMariaDb())
+            ? ['--column-statistics=0']
+            : [];
+    }
+
     private function isMariaDb(): bool
     {
         // Connection::getServerVersion() is private in the DBAL version this

src/Service/DumpService.php

@@ -173,6 +173,7 @@ class DumpService
             $binary,
             '--single-transaction',
             '--quick',
+            ...$this->dumpBinaryLocator->extraArguments($binary),
             '-h', (string) ($params['host'] ?? '127.0.0.1'),
             '-P', (string) ($params['port'] ?? 3306),
             '-u', (string) ($params['user'] ?? 'root'),

src/Service/MySqlVariant.php

@@ -14,4 +14,18 @@ class MySqlVariant
     {
         return stripos($serverVersion, 'mariadb') !== false;
     }
+
+    /**
+     * MySQL 8+ mysqldump queries information_schema.COLUMN_STATISTICS, which
+     * MariaDB lacks (error 1109); --column-statistics=0 skips it. MariaDB's own
+     * client (version string contains "MariaDB") and MySQL < 8 don't know the flag.
+     */
+    public static function needsColumnStatisticsOff(string $clientVersion, bool $serverIsMariaDb): bool
+    {
+        return $serverIsMariaDb
+            && !self::isMariaDb($clientVersion)
+            // MySQL < 8 prints "Ver 10.13 Distrib 5.7.x": the Distrib number is the real version.
+            && (preg_match('/Distrib (\d+)\./', $clientVersion, $m) === 1 || preg_match('/\bVer (\d+)\./', $clientVersion, $m) === 1)
+            && (int) $m[1] >= 8;
+    }
 }

tests/Service/MySqlVariantTest.php

@@ -21,4 +21,20 @@ class MySqlVariantTest extends TestCase
         yield 'mariadb without legacy prefix' => ['10.11.2-MariaDB', true];
         yield 'mariadb lowercase' => ['10.11.2-mariadb', true];
     }
+
+    #[DataProvider('columnStatisticsProvider')]
+    public function testNeedsColumnStatisticsOff(string $clientVersion, bool $serverIsMariaDb, bool $expected): void
+    {
+        self::assertSame($expected, MySqlVariant::needsColumnStatisticsOff($clientVersion, $serverIsMariaDb));
+    }
+
+    public static function columnStatisticsProvider(): iterable
+    {
+        $mysql8 = 'mysqldump  Ver 8.0.46-0ubuntu0.24.04.4 for Linux on x86_64 ((Ubuntu))';
+        yield 'mysql 8 client, mariadb server' => [$mysql8, true, true];
+        yield 'mysql 8 client, mysql server' => [$mysql8, false, false];
+        yield 'mysql 5.7 client, mariadb server' => ['mysqldump  Ver 10.13 Distrib 5.7.44, for Linux (x86_64)', true, false];
+        yield 'mariadb client, mariadb server' => ['mariadb-dump from 11.4.2-MariaDB, client 10.19 for debian-linux-gnu (x86_64)', true, false];
+        yield 'mariadb legacy mysqldump name' => ['mysqldump  Ver 10.19 Distrib 10.11.6-MariaDB, for debian-linux-gnu (x86_64)', true, false];
+    }
 }