Skip to content

v1.2.0 — Storefront Extensions: reproducible builds, Shopware Cloud app, install-blocking fixes

Choose a tag to compare

@ackm04 ackm04 released this 23 Aug 18:33
· 19 commits to main since this release

Ten installable artifacts, all rebuilt from the current source by
scripts/package-all.sh.

If you tried to install from v1.1.0, that is why it did not work. No release
asset on this repo was ever built by CI — the release workflow sat in a
subdirectory where GitHub never reads it, so every zip was uploaded by hand and
they had drifted from the source.

Read this first

Platform Download Notes
Shopware Cloud / 6.6+ (App) tack-shopware-app.zip New — never shipped in a release before. Upload under Extensions → My Extensions → Upload.
Shopware self-hosted (plugin) tack-shopware.zip Extract to custom/plugins/TackQuote
WooCommerce tackquote-for-woocommerce.zip Plugins → Add New → Upload
OpenCart 4.x tack.ocmod.zip Do not rename this file. See below.
OpenCart (source only) tack-opencart-source.zip Not installable — reading copy
PrestaShop tack-prestashop.zip Module Manager → Upload a module
Magento 2.4 tack-magento2.zip unzip tack-magento2.zip -d <root>/app/code
Zen Cart tack-zencart.zip Copy the contents of store-root/ only
Squarespace / Wix tack-squarespace.zip, tack-wix.zip Code snippets

OpenCart: the filename is load-bearing

OpenCart derives the extension code from the zip filename, and every
namespace and event action in this package hard-codes tack. A zip under any
other name installs successfully and then returns 404 on every route, with
nothing in the error log. Keep it tack.ocmod.zip.

Zen Cart: copy the contents, not the folder

The archive separates what goes on the server from what must not. Copy the
contents of store-root/ into your store root. Leave zc_install/ (the SQL)
and the README on your own machine — the previous README told you to copy them
in, which published install.sql under your web root.

Fixed in this release

  • Magento's v1.1.0 asset was never installable. Its top-level directory was
    magento2/ instead of Vendor/Module/, so Magento could never discover the
    module. It also contained eight files that exist nowhere in this repository.
  • PrestaShop merchants were never offered the v1.1.0 upgrade. The module
    declared version 1.0.0 at every tag, and PrestaShop keys upgrades off that
    value.
  • PrestaShop's "no API key set" warning could never appear. config.xml said
    need_instance=0 while the class said 1, so the module installed, reported
    itself active, rendered no button, and explained nothing.
  • PrestaShop advertised order sync that does not exist. Claim corrected.
  • Zen Cart README no longer instructs you to publish the SQL under your web root.
  • WooCommerce packaging no longer risks shipping tests and dev config.
  • Versions bumped where they had never been bumped at all.

Known gaps (documented, not fixed)

  • Zen Cart install.sql is not idempotent. A second run creates a duplicate
    empty config group, then fails on a duplicate key. The README has the cleanup.
  • Zen Cart quote button on a custom template. The template file hardcodes
    template_default asset paths, so on a custom template the CSS/JS 404 and the
    button does nothing. The README documents the two manual edits.
  • Magento credential cache. After an admin edits API credentials they stay
    cached for up to 15 minutes; the observer that flushed them was one of the
    eight files that only ever existed in the old published asset.
  • Magento license metadata declares GPL-2.0-or-later while the repo LICENSE
    is MIT. Unresolved deliberately.

How these were verified

php -l on every shipped PHP file (8.3, plus 7.4 where a plugin declares that
floor); the Shopware manifest validated against manifest-3.0.xsd with
name==directory (that name is concatenated into the registration proof HMAC, so
a mismatch breaks registration silently); Zen Cart SQL executed against MySQL 8
on the authentic v1.5.8a schema; OpenCart's 29 in-repo tests passing; secret
scans clean on all ten artifacts. Every layout rule came from the vendor's own
documentation, not from a sibling directory.

GitHub Actions is billing-blocked on this account, so these were built locally
with the same script the workflow invokes.

What's Changed

  • feat(shopware): TackQuoteApp — an App installable on Shopware Cloud by @ackm04 in #2

Full Changelog: v1.1.0...v1.2.0