When the server is MariaDB but only MySQL 8's mysqldump is installed
(e.g. dockware/web), the dump aborted with "Unknown table
'COLUMN_STATISTICS' in information_schema (1109)".
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- register the list page lazily and wrap it with wrapComponentConfig
- sw-button/sw-alert/sw-progress-bar -> mt-button/mt-banner/mt-progress-bar
- beforeDestroy -> beforeUnmount (Vue 3)
- split the combined `import type` that broke the Vite build
- Vite outputs to public/administration/assets/: update .gitignore and the CI asset check
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- shopware/core ~6.7.0; 6.6 stays on the 0.0.x line
- drop the sw-settings navigation entry; the settingsItem card in
Settings > System is the only entry, like core settings modules
- dev container on dockware/shopware:6.7.14.2
BREAKING CHANGE: Shopware 6.6 is no longer supported.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- composer.json 0.0.6, CHANGELOG entries of the withdrawn 0.1.0/0.1.1 merged into [0.0.6]
- version-changelog: version must exceed the latest published release (main may carry a
version whose release was withdrawn), instead of exceeding main's version
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
- phpunit: 'Resolve the latest Shopware Version' uses composer show against require.shopware/core
from the plugin's composer.json (the Packagist scrape returned nothing on the first run)
- release: build the registry zip from an explicit file list without a leading ./ so the
composer.json entry is stored at the zip root
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
- resolve the latest 6.6.x from Packagist; cache key shopware-<version>-installed-v1
- cache the project plus a SQL dump of the installed shopware_test database; on a hit restore
the dump instead of running system:install (~4.6 min)
- rename the step 'Install Shopware (once)' to 'Install Shopware'
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Gitea's registry answered 400 'composer.json file is missing' for the shopware-cli zip
(single top-level folder). Repack the same prebuilt content with composer.json at the root.
Drop the tag-exists skip guard so a half-finished release can be re-run; reuse an existing
release/asset. Bump to 0.1.1.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
DATABASE_URL already ends in _test so the TestBootstrapper finds an installed DB and
skips its own migration run; FORCE_INSTALL (which failed with an unknown database) removed.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
- one PR workflow (plugin-checks) with version-changelog, package, phpunit jobs
- .gitea/actions/package: package + validate + assert, used by PR and release
- phpunit: FORCE_INSTALL so the TestBootstrapper installs its own test DB
- protect-main.sh: required context is now plugin-checks / version-changelog
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
- phpunit: cache the prepared project (vendor + phpunit) monthly via cache restore/save;
drop system:install/plugin:install (TestBootstrapper installs into its own test DB, so
every migration ran twice, ~5.5 min each); relax InnoDB durability on the CI database
- package: save the tested zip keyed by the commit's tree hash; release restores it and
only re-packages on a miss, but always validates and asserts the zip
- cancel superseded PR runs (concurrency)
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
- drop the separate validate job (the zip is validated after packaging); same in release
- shared scripts/ci/assert-built-assets.sh (BusyBox-safe), now also used by release
- actions/cache for npm, shopware-cli and composer
- phpunit: shopware-cli image instead of a 4.5 min apt install; MariaDB 10.11
(11.4 broke Shopware's migrations: Duplicate column 'sorter_key')
- protect-main.sh: drop the removed validate context
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Replaces the curl/tar install and setup-node steps; the image ships the
CLI plus its PHP/Node toolchain.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
setup-php hangs on the runner even with runner=self-hosted; the CLI download
returned a non-gzip body once under concurrent load.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
- validate job needs no PHP (the package job already validates without it)
- phpunit: runner=self-hosted so setup-php does not hang under act; replace the
unhealthy service healthcheck with a TCP wait loop
- .config/shopware-extension.yml: set compatibility_date
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
- plugin-checks workflow: shopware-cli validate, package + built-JS assertion, phpunit
- release: validate, package from the merge commit, validate the zip, create the release
via the Gitea API, publish the same zip to the Composer registry
- scripts/protect-main.sh sets required status checks via tea api
- bump to 0.1.0
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
- Wires the backend from/to filter into the UI via sw-filter-panel with
a hand-built date-filter config (no DAL entity needed — sw-filter-panel's
only external dependency, filterService, persists through the generic
user_config entity, not one for the filtered resource).
- Makes the datetime and sizeBytes columns sortable (ascending/descending)
using the same Mixin.getByName('listing') core list pages use, which
also persists sort state in the URL query string.
- Replaces the ad hoc `new Date(value).toLocaleString()` with
Shopware.Utils.format.date, matching the existing fileSize formatting
and respecting the admin's locale/timezone.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The installed PHPUnit (12.x, ahead of this plugin's ^10.0 dev
constraint) no longer parses the @dataProvider PHPDoc annotation,
so both tests silently ran their data-provider method with zero
arguments and failed with ArgumentCountError.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The admin date filter can send a naive local date string for "from" but
a UTC Z-suffixed instant for "to" (sw-date-filter widens it client-side
via Date#toISOString()). Comparing those directly against dump
timestamps (parsed in PHP's default timezone) shifted the effective
cutoff by the timezone offset. Re-express both bounds in the app's
default timezone before applying the day boundary.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
haylanandClaude Bot