v1.2.0 — Storefront Extensions: reproducible builds, Shopware Cloud app, install-blocking fixes
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 ofVendor/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 version1.0.0at every tag, and PrestaShop keys upgrades off that
value. - PrestaShop's "no API key set" warning could never appear.
config.xmlsaid
need_instance=0while the class said1, 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.sqlis 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_defaultasset 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
Full Changelog: v1.1.0...v1.2.0