Shopware 6 | Update, Test & Release 3.5.0 - #486
Closed
vegimcarkaxhija wants to merge 101 commits into
Closed
Conversation
…e-3.4.0 Update, Test & Release 3.4.0
…e-in-the-checkout-for-specific-merchant Bti 970 apple pay not visible in the checkout for specific merchant
…nvironment-support-for-PayPal-Express Implement sandbox environment support for PayPal Express
…Fields-are-not-editable-during-checkout Bti 1046 credit card hosted fields are not editable during checkout
This reverts commit ff243fc.
…tomer-fields-for-Billink-in-the-checkout Remove optional customer fields for Billink in checkout
…ion-request Add culture in transaction request
new build for express checkout changes
BTI-1288 Update README.md file
error message missing validation
Support 6.7.13.0
…pture-on-Shipment-settings Resolve conflict of auto capture and capture on shipment setting
Shopware 6.7 removed component/payment/payment-fields.html.twig together with its `component_payment_method` block, and renamed base_header / base_footer to base_esi_header / base_esi_footer. Both plugin overrides silently stopped rendering: no error, no log entry. - add component/payment/payment-form.html.twig, overriding `component_payment_form_list`, which restores the translated required message holder, window.buckaroo_back_link and the selected-method-first ordering on 6.7. payment-fields.html.twig is kept unchanged for 6.5/6.6, where core still includes it; exactly one of the two ever renders. - ideal-qr.html.twig declares both the legacy and the 6.7 block names so the minimal header/footer survive on every supported version. - drop page/product-detail/buy-widget-form.html.twig: 6.7 moved the template to component/buy-widget/, which the plugin already overrides, so this file was dead. - drop the no-op `component_payment_fieldset_template` override; core removed that block in 6.7 without replacement. The collapse behaviour is deliberately not reimplemented: core no longer passes visiblePaymentMethodsLimit and no longer truncates the list.
SalesChannelContextServiceParameters has never exposed getContext(); the method is called getOriginalContext() in both 6.6 and 6.7. The call sat in a branch that is unreachable today (the token lookup at the call site and the one in the decorator are the same, so their conditions are mutually exclusive), but it would fatal the moment either side is refactored. The rebuilt parameters also dropped customerId and imitatingUserId, which are now passed through. Also remove two imports of classes that no longer exist in 6.7 (InvalidDocumentException, AsyncPaymentTransactionStruct). Both were unused, so they were harmless, but they are misleading.
The range was pinned to an exact patch upper bound, so every Shopware release needed its own ticket. A range removes that treadmill and matches what other payment plugins do (Mollie >=6.5.8.0 <6.8, Adyen ~6.7.0, MultiSafepay 6.7.*). The floor moves off 6.5.0.0, which was never supportable; 6.5.8.0 is the extended-support release for the 6.5 cycle (maintained until 2027-02-28). The range is a compatibility declaration: it states which Shopware versions the plugin works with. A newer 6.7 patch is picked up automatically without another change here.
The existing suites run without Shopware installed, so they cannot observe template drift: 597 unit tests stayed green while the payment step silently stopped rendering. These tests exercise a real shop instead. - tests/e2e: Playwright suite in its own package.json, so the plugin's webpack tooling is untouched. Six specs covering storefront smoke checks and the payment step, including an assertion on the required-message holder that fails loudly when the payment override stops being applied. - e2e-shopware.yml: reusable job that boots dockware/shopware, installs the plugin through a composer path repository, activates it, builds assets and runs the suite. - e2e.yml: per-PR gate on the newest supported version. - e2e-nightly.yml: walks the whole range composer claims, so that claim is verified rather than asserted. - extension-verifier.yml: the validation the Store runs on upload, non-blocking until the current baseline is cleared. Verified locally against real containers for 6.7.13.0, 6.7.12.2, 6.7.11.1, 6.6.10.22 and 6.5.8.19 - 6/6 on each. The required-message assertion passes through payment-form.html.twig on 6.7 and through payment-fields.html.twig on 6.5/6.6, which is what proves both variants are live. The suite was mutation tested: disabling payment-form.html.twig turns it red with the intended diagnostic, so it would have caught the original regression.
…ort-for-Shopware-6.7.13 Bti 1374 shopware 6 add support for shopware 6.7.13
The Shopware Extension Verifier rejects extra.description below 150 or above 185 characters. Ours were 23 (en-GB) and 24 (de-DE), so the check failed as soon as the verifier was wired into CI. This is a store-submission blocker that predates the verifier, not something it introduced. Verified with shopware-cli extension validate: 2 errors -> 0 errors, exit 0. The two remaining warnings (routes.xml and services.xml should become routes.yaml / services.yaml) are untouched; converting DI config is a larger change and deserves its own ticket.
…tibility-testing-against-real-Shopware-versions test: add shop-level E2E suite and a Shopware version matrix
…sertions The E2E matrix pinned 6.7.13.0, so 6.7.13.1 shipped without ever being tested and would have stayed that way until someone edited the workflow. Both workflows now resolve the newest dockware tag per series at run time. dockware publishes a plain multi-arch tag plus per-arch tags, and a fresh release shows up as -amd64 hours before it gains its manifest (6.7.13.1 is in that window right now). The resolver prefers the plain tag and falls back to -amd64 so a testable release is not skipped. Two assertions were weaker than their names promised: - 'selected payment method is listed first' accepted -1, meaning nothing preselected. If the payment list stopped rendering its selection the test still passed. It now requires a preselected method at index 0. - The buckaroo tag check matched [class*="bk-"] anywhere on the page. It is now anchored to the payment radios, so an unrelated bk- element elsewhere cannot keep it green.
…refix Verified against a real 6.7.13.0 shop: Shopware's own methods (invoice, prepayment, cash on delivery) go through the same payment-method override and come out with a bare `bk-` and no key. Matching [class*="bk-"] therefore proved nothing - it counted all 33 rendered methods, buckaroo or not. Read the key off each radio's wrapper instead and require a non-empty one: 30 of the 33 methods on that shop carry a real key (ideal, bizum, blik, ...). Mutation-tested both tightened assertions by breaking the behaviour they describe; each fails as intended, so neither is vacuous.
… suite The first run with the tightened assertion failed on a clean 6.7.13.1 shop: zero buckaroo methods on the confirm page, only Shopware's own Cash on delivery / Paid in advance / Invoice. Cause is the CI environment, not the plugin. PaymentMethodsInstaller marks the methods active but never writes sales_channel_payment_method, and Shopware only offers methods attached to the sales channel. A developer shop has those rows because somebody configured it by hand; a fresh install has none. This is also why the old page-wide [class*="bk-"] check passed here: the override puts a bare `bk-` on Shopware's own methods too, so it counted them and reported success while nothing buckaroo rendered at all. Attach them after activation and fail the step outright if none could be attached, so a misconfigured shop reports itself instead of surfacing as a confusing template assertion further down.
…sales channels and enabling settings
…tibility-testing-against-real-Shopware-versions Bti 1384 add automated compatibility testing against real shopware versions
…est-Release-3.5.0 Bti 1244 shopware 6 update test release 3.5.0
…oSettle-as-payment-method-deprecated Bti 1340 shopware 6 remove go settle as payment method deprecated
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
4 participants
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.
No description provided.