Add banner upload functionality to the shop home screen

[AleksandarBoljanovic]

What is the goal?

• Add the functionality to upload a banner for the shop's home page to the integration-core, and ensure this new configuration can be received via the configuration webhook sent by the merchant portal.

References

• Issue: LIS-111

How is it being implemented?

• BannerService - saves admin-uploaded banners to pub/media/sequra/banners/{storeId}/{COUNTRY}_{displayLocation}.ext}, deletes them, and (new) relocates them when only the display location changes so admins don't have to re-upload.
• Storefront block + template + CSS + 4 layout XMLs - render a banner on home, product, category, and cart pages
• Setup/Uninstall.php - clears pub/media/sequra/banners on uninstall.
• Setup/Patch/Data/Version330.php - one-shot migration that re-registers the store integration via StoreIntegrationMigrateTask. Targets module version 3.3.0 - the next release on etc/module.xml is expected to be 3.3.0 so this patch applies.
• Services/Bootstrap.php - removes the dead StoreIntegration DataAccess entity registration (dropped in integration-core).
• CI / phpstan - bumps actions/checkout and actions/cache to @v5 (Node 24)

How is it tested?

• Run the command to check the PHP syntax
• Manual tests
  • New installation
    • Install and enable the SeQura module in the Magento 2 system.
    • Test the onboarding flow.
    • Log in SeQura portal
    • Test Banner upload image for each supported country and page
  • Existing installation
    • Update the SeQura module in the Magento 2 system.
    • Test module behavior
    • Log in SeQura portal
    • Test Banner upload image for each supported country and page

[m1k3lm]

Overview

Adds a storefront banner system: admins can upload images per country/page via the merchant portal; the module stores them under pub/media/sequra/banners/{storeId}/... and renders them on home, product, category listing, and cart pages. Includes a BannerService (filesystem-backed storage with base64 decode + MIME validation), a CountryResolverService (visitor country detection), a Block + phtml template, four layout XMLs, an uninstall cleanup, and a Version330 data patch.

---

High-impact concerns

• Block caching (Block/Banner.php). The block extends Template but does not override getCacheKeyInfo() and the layouts do not set cacheable="false". Under FPC/block cache the first request's banner — including the resolved country — will be cached and served to other visitors. Either set cacheable="false" on the block in layout, or override getCacheKeyInfo() to include $storeId, $country, and $displayLocation plus a TTL. Otherwise visitors from different countries see each other's banners (or nothing), and the API call hits on every cache miss.

• Version330::apply() swallows Throwable and returns normally. When migration fails, the patch is recorded as applied by Magento and never retries. If StoreIntegrationMigrateTask is critical for the upgrade, rethrow so setup:upgrade fails loudly. If it's truly best-effort, the log line should be louder than logError.

• Empty alt="" on banner images (banner.phtml). Accessibility + SEO issue for a marketing banner. Plumb an altText field through the API response or use a sensible default (e.g. "seQura financing").

• No automated tests for BannerService (457 lines, base64 + MIME + filesystem ops + cross-extension cleanup + relocate-on-rename). At minimum unit-test decodeBase64, assertIsValidImage, resolveExtension, relativePathFor, and changeBannerImageDisplayLocation's happy/missing/same-location branches.

---

Smaller issues

• BannerService::changeBannerImageDisplayLocation — when no source exists OR old === new, returns a URL synthesized with a defaulted .png extension regardless of whether anything is there. Caller has no signal the file is missing; admins may see a broken <img src>. Either return null/empty or document the contract clearly.
• BannerService::storeSegment() falls back to literal 'default' directory when StoreContext has no storeId, while getMediaBaseUrl() falls back to StoreManager's default store. Asymmetry could produce 404s in edge cases — worth aligning.
• Block\Banner::getBannerData() catches Exception, not Throwable. Some SDK paths can surface Error (e.g. type errors from a malformed response); upgrading to Throwable keeps render bulletproof.
• Bootstrap.php removes the StoreIntegration repository registration. The Version330 patch migrates the entity first — ordering looks correct, but please smoke-test an upgrade from an installation with existing StoreIntegration rows.
• banner.phtml correctly uses rel="noopener noreferrer" with target="_blank". ✓

---

Nice work on input validation, multi-variant cleanup, and the relocate-on-rename flow — those are well factored. The storefront caching story is the one that will bite in production, so let's address that before merge.

unreviewed review

[m1k3lm]

The Block/Banner.php caching issue should be solved.