Repository navigation
Shopware - #2478
Open
TaiKamilla wants to merge 7 commits into
Open
Shopware#2478TaiKamilla wants to merge 7 commits into
TaiKamilla wants to merge 7 commits into
Conversation
Contributor
Try this script
COMMUNITY_SCRIPTS_URL=https://raw.githubusercontent.com/TaiKamilla/DevScripts/add-shopware \
bash -c "$(curl -fsSL https://raw.githubusercontent.com/TaiKamilla/DevScripts/add-shopware/ct/shopware.sh)"
Against a core branch as wellAdd Useful flags while testing
|
Contributor
|
✅ Requirements check passed. Thanks for fixing the description — the |
github-actions
Bot
added
requirements missing
github-actions
Bot
removed
requirements missing
Author
|
This might be interesting to you @shyim This is the main project: |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
Member
|
/test |
Contributor
There was a problem hiding this comment.
Proxmox script test failed at 11b70cd:
ct/shopware.sh(pve): install script exited 2: in line 143: exit code 2 (composer exited with status 2): while executing command composer create-project shopware/production /opt/shopware --no-interaction --no-dev --prefer-ct/shopware.sh(incus): failed services: opensearch.service
Logs and details: test result. Push a fix, then ask for /test again.
…Search - Composer refuses mcp/sdk 0.8.1 (advisory PKSA-s52d-n7sx-trsg), which Shopware 6.7.15.0 to 6.7.16.0 require, so create-project failed. Ignore that one advisory as Shopware recommends (only the SDK OAuth middleware is affected and Shopware does not use it, shopware/shopware#22776). The update path sets the same ignore for existing installs. - OpenSearch: raise TimeoutStartSec to 300 (3.x with its bundled plugins needs about a minute on 2 cores, the unit allows 75 s). If it still does not start, print its journal, disable it and install Shopware with MariaDB search instead of failing the whole install. - json: add "platforms": ["pve"].
Author
|
Thanks for running the test. The pve failure wasn't a missing package: Shopware 6.7.15.0 to 6.7.16.0 require |
github-actions
Bot
dismissed
their stale review
November 12, 2026 10:55
Proxmox script test passed at 3c55ed3.
…line shopware/production pins shopware/core to the exact version it was created with, so composer update never upgraded Shopware while the script still reported success. Before updating, widen the constraint to the installed major line (e.g. ~6.7.0); major upgrades stay manual. If the newest release is not complete on Packagist yet, Composer falls back to the newest one it can resolve.
Contributor
There was a problem hiding this comment.
Proxmox script test failed at 30b1148:
ct/shopware.sh(pve): update: exited 1: Composer update failed. The shop is unchanged, check the output above.ct/shopware.sh(incus): update: exited 2: [2026-11-12 14:24:51] [ERROR] in line 933: exit code 2
Logs and details: test result. Push a fix, then ask for /test again.
Member
|
Ignore the update failure, looks to be a problem with the test script! |
github-actions
Bot
dismissed
their stale review
November 12, 2026 15:28
Proxmox script test passed at 30b1148.
Contributor
Proxmox script test@michelroegl-brunner @TaiKamilla ✅ 1/1 passed at
📊 Resources
Built only on pve; comment 📸 ct/shopware.sh (pve) — http://10.99.0.110/admin: after install / after update
📄 ct/shopware.sh (pve) — install log (3001 lines)🔄 ct/shopware.sh (pve) — update log (42 lines)🔁 ct/shopware.sh (pve) — second update logFull logs: workflow run (artifacts |
michelroegl-brunner
approved these changes
Nov 13, 2026
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
✍️ Description
New script: Shopware 6 (open-source e-commerce platform, Symfony + Vue.js) in a Debian 13 LXC, set up following the official Shopware hosting and performance guides (
shopware/docs→guides/hosting/), not a minimal dev install:soap,zstd. php.ini tweaks from Performance Tweaks (zend.assertions, opcache interned strings / max files, realpath cache).MARIADB_VERSION="12.3", the version Shopware CI tests; 13.x is rolling) withmax_allowed_packet 64M,group_concat_max_len 320000and an sql_mode withoutONLY_FULL_GROUP_BY, as the docs ask.fetch_and_deploy_from_url+get_latest_github_release. Two instances, because the docs require different eviction/persistence per data type (Infrastructure → Redis):valkey@cache(:6379, no persistence, volatile-lru): app/system cache (redis_tag_aware), delayed HTTP cache invalidation.valkey@persistent(:6380, AOF everysec, volatile-lru): sessions, cart, number ranges, increment storage, lock store and the Messenger transports (symfony/redis-messenger, one stream per transport).valkey@.servicetemplate withDynamicUser=yes(nouseradd).SHOPWARE_ES_THROW_EXCEPTION=0as in the docs' production example: OpenSearch needs about a minute after a container boot, and this way the shop serves from MariaDB in that window instead of answering 500. Optional viavar_opensearch=nofor small shops (search then falls back to MariaDB). The 2.x apt repo is signed with a SHA1-bound key that Debian 13's sqv rejects, so the 3.x repo +opensearch-release.pgpis used (Shopware supports OpenSearch 3 since 6.7.3.1).messenger:consume async low_priority failed,scheduled-task:run), mails through the queue, monolog levelerror,.env.local.phpdumped.nginx_enable_site.var_admin_user/var_admin_pass(generated withrandom_passwordwhen empty) /var_admin_email, saved to~/shopware.creds.Update:
check_for_gh_releaseagainstshopware/shopware;create_backupof.env.localandconfig/packages/prod(Flex recipes may touch config), maintenance mode →system:update:prepare→composer update→restore_backup→system:update:finish. Stays inside the template's~v6.7.0line; major upgrades (6.8) are manual and noted in the JSON. Valkey binaries are updated the same way againstvalkey-io/valkey.Upstream research: Shopware has no release tarball meant for self-hosting; the documented production install is
composer create-project shopware/production, used here. The official production images (shopware/docker) are Alpine + PHP-FPM + Caddy/Nginx with external DB/Redis/OpenSearch; this script reproduces that stack bare-metal inside one LXC.shopware/core6.7.15.1 requires PHP~8.2 || ~8.3 || ~8.4 || ~8.5.🔗 Related PR / Issue
Link: #
✅ Prerequisites (X in brackets)
🏗️ arm64 Support (X in brackets)
var_arm64=yes: every component publishes arm64 builds (Sury PHP, MariaDB 12.3 trixie repo, OpenSearch 3.x apt, Valkeynoble-arm64tarball, Node). I have no arm64 host to test on.🖥️ Tested on (X in brackets)
Unattended clean runs on Proxmox VE (Debian 13 template, unprivileged, default resources 2 CPU / 6 GB / 20 GB): all services active (nginx, php8.5-fpm, mariadb, valkey@cache, valkey@persistent, opensearch, shopware-worker, shopware-scheduler), storefront 200 (~28-47 ms once cached),
/admin200, Admin API login OK, full reindex queued through the Valkey transport and drained by the worker, 18 OpenSearch indices, 0 CRITICAL entries invar/log, ~2 GB RAM used. Also tested: container restart (all services come back) andupdate_script()run inside the container with the version files removed (Valkey and Shopware both went through the update path, services back up, storefront/admin 200, config restored). Versions installed: Shopware 6.7.15.1, PHP 8.5.12, MariaDB 12.3.3, Valkey 9.1.3, OpenSearch 3.9.0.🛠️ Type of Change (X in brackets)
README,AppName.md,CONTRIBUTING.md, or other docs.🔍 Code & Security Review (X in brackets)
CODE-AUDIT.md&CONTRIBUTING.mdguidelinesAppName.sh,AppName-install.sh,AppName.json)fetch_and_deploy_gh_release,fetch_and_deploy_codeberg_release,fetch_and_deploy_gl_release, orfetch_and_deploy_from_urlinstead ofgit pull.Deviation to flag: Shopware itself is installed and updated with Composer (
composer create-project/composer update), which is the only production install method Shopware documents; there is no deployable release archive.🤖 AI Assistance (X in brackets)
AGENTS.mdand.github/agents/pve-script-creator.agent.mdas guidance, and the output has been reviewed and corrected to match those guidelines.Claude Opus 5.5 (Anthropic) running as an agent, default reasoning effort: researched the Shopware hosting docs and CI matrix, drafted the three files from the EspoCRM template, then iterated through several real unattended installs on Proxmox VE, fixing every failure found (OpenSearch 2.x SHA1 key, stale Symfony container after
composer require, one Messenger stream per transport, version file fromcomposer.lock). Reviewed and approved by the author before submission.📋 Additional Information (optional)
var_opensearch=no4 GB is enough.APP_URLin/opt/shopware/.env.localand the sales channel domain (JSON notes).📦 Application Requirements (for new scripts)
🌐 Source