Recent Activities

WIP 9ffeb4

Repo => Channel to match old command 1e3a63

Use `swissup.extra` params as primary source 69fcf1

Update command descriptions 48a007

Remove useless comment e857e3

Array offset cannot be null e4017c

Add swissup:update command

- Update swissup/* packages only; -w also updates their 3rd party dependencies
- Move ensureRepositoryEnabled into PackageAbstractCommand to share with update
- Drop disabled modules check: setup:upgrade runs with --safe-mode=1 anyway

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> 3c3f3b

WIP 434bf2

WIP a8a711

Remove unused code 599915

Installer => ModuleManager 0f7da5

Drop outdated code (Magento < 2.3.3) e5542c

Remove outdated code 7c5b9a

Open links in new tab 81a541

"How to update" added to the grid 4fdc59

Add latest version to the grid 21367b

Move outdated modules to the top of the grid be87e7

Add outdated badge to the Swissup menu aae4b5

Version 1.13.1 5b7b24

Fixed invisible update instructions when Mollie Payments is installed 72aab6

feat(content-builder): per-field AI generate button (#142)

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> 7b910b

Merge pull request #157 from breezefront/fix/156-icon-crop-accuracy

fix(content-builder): icon crop accuracy is the model's aim, not our arithmetic (#156) 81a57b

docs(content-builder): squaredUp() isn't the #156 icon-crop fix — model aim is

Investigated before changing anything: the model's boxes for the reference's icon strip were already in the wrong place (bunched, sometimes identical across distinct icons), not a good box distorted by our grid math. See PR for evidence. df3739

chore(release): 1.8.5 604e25

fix(content-builder): tell the model an icon's region is expected, not offered (#154) (#155)

Split from #146: extraction now keeps a boxed icon, but the model wrote
no image_regions entry for any icon prop at all — nothing to keep.

IMAGE_REGION_RULES named icons twice, both about how to box one once
you decided to. Nothing said an icon was expected output rather than
an option, and the per-prop rule ("one entry per image prop you want
filled") left the wanting to the model, which declined every time on
Dmitry's reference.

Four changes: an explicit "every icon gets a region" rule naming
text_block cards one by one; a rule that size is not a reason to skip
one (self-censoring undersized boxes was the same silence as never
considering them); a worked text_block example with a real icon
region, not only prose; and a line clarifying image_regions/band are
node keys, not props, since the "unlisted props are discarded" rule
reads as covering them too.

Verified with real builds against example-real-layout.png on two
vision models (gpt-4o-mini, gpt-4o): both now emit icon_source=image
with a real media path. gpt-4o needed a retry once (malformed JSON
mid-reply, unrelated to icon wording) but boxed icons in every one of
4 runs.

Prompt-only change, per the issue's scope. ImageExtractor and
AssetPolicy untouched. 83df18

fix(content-builder): tell the model an icon's region is expected, not offered (#154)

Split from #146: extraction now keeps a boxed icon, but the model wrote
no image_regions entry for any icon prop at all — nothing to keep.

IMAGE_REGION_RULES named icons twice, both about how to box one once
you decided to. Nothing said an icon was expected output rather than
an option, and the per-prop rule ("one entry per image prop you want
filled") left the wanting to the model, which declined every time on
Dmitry's reference.

Four changes: an explicit "every icon gets a region" rule naming
text_block cards one by one; a rule that size is not a reason to skip
one (self-censoring undersized boxes was the same silence as never
considering them); a worked text_block example with a real icon
region, not only prose; and a line clarifying image_regions/band are
node keys, not props, since the "unlisted props are discarded" rule
reads as covering them too.

Verified with real builds against example-real-layout.png on two
vision models (gpt-4o-mini, gpt-4o): both now emit icon_source=image
with a real media path. gpt-4o needed a retry once (malformed JSON
mid-reply, unrelated to icon wording) but boxed icons in every one of
4 runs.

Prompt-only change, per the issue's scope. ImageExtractor and
AssetPolicy untouched. cc0fe5

Version 1.6.10 5b55b3

Merge pull request #110 from swissup/fix/issue-109-aggregation-bucket-size

fix(category filter): request all term buckets from the search engine (#109) 0c2c7c

fix(category filter): resize only the category aggregation (#109)

Lifting the bucket limit for every faceted field at once lets the buckets
of all the high cardinality attributes add up beyond the cluster's
search.max_buckets - 10000 on Elasticsearch 7.0-7.10 - and the engine
answers that with too_many_buckets_exception, so the whole listing errors
out instead of one facet losing its tail.

Resize the fields named in the new fieldNames argument, which holds just
category_ids by default. An empty list restores the previous behavior of
resizing every term aggregation.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> 8a902c

test: use the DataProvider attribute, not the annotation (#109)

PHPUnit 12 no longer reads data providers from annotations, which is what
the rest of Test/Unit was migrated away from in #107.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> 552c4e

fix(category filter): request all term buckets from the search engine (#109)

Magento hardcodes the Elasticsearch/OpenSearch terms aggregation size to
500, so the engine returns only the 500 most popular values of a faceted
field and silently drops the rest. On a catalog whose result set spans
more categories than that, the category filter loses the child categories
with the lowest product counts, while the header menu keeps showing them.

The existing fallback to Category::getProductCount() cannot cover for it:
addCountToCategories() runs against a search collection whose SQL select
only carries the ids of the current page, so the count comes back as 0 and
the option is skipped altogether.

Raise the term bucket size with a plugin on the aggregation query builder.
The size is a DI argument, so it can be tuned per project.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> 233e61

Version 1.6.9 47aee3

Merge pull request #108 from swissup/fix/issue-107-phpunit12-test-migration

Migrate Test/Unit off removed PHPUnit APIs (PHPUnit 12 / PHP 8.5) e5c066

Migrate Test/Unit off removed PHPUnit APIs for PHPUnit 12 / PHP 8.5

The CI runner targets PHP 8.5, whose only compatible PHPUnit is 12.x/13.x.
Test/Unit used several APIs removed in PHPUnit 10-12, so the suite could not
run there. Migrate them and refresh stale mocks that drifted from the code:

- setMethods() (removed v10) -> onlyMethods(); RequestInterface builder
replaced with createMock(Request\Http) since the stubbed methods
(isAjax, getFullActionName) are not on the interface.
- $this->at() (removed v10) -> plain willReturn() stub on getBlock.
- ->will($this->returnValue()) (removed v12) -> willReturn().
- Data provider methods made static and switched from the @dataProvider
doc-comment (ignored under PHPUnit 12) to the #[DataProvider] attribute.
- AbstractFilterTest: Price::initRange() now reads the product collection
via Layer::getCurrentCategory(), not Layer::getProductCollection(); the
setUp mock is rewired accordingly.
- ViewTest/IndexTest: gate isAjaxlayerednavigationRequest() now checks
Http::isAjax() and getParam('aln', false); stubs updated to match.

Verified: PHPUnit 10.5 (PHP 8.3) 34/34 green. Under PHPUnit 12.5 the module
tests run and pass; the ObjectManager helper's protected getMockBuilder()
call is a magento/framework 103.0.8-p1 limitation, fixed in later releases.

Refs swissup/module-ajaxlayerednavigation#107

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> b5904f

Version 1.36.0 c893e0

Version 1.4.10 be8702

KlarnaKp integration 41d1eb

Version 1.4.9 4aa797

Version 1.36.0 c6b511

Fix readonly env: deploy jsbuild during static content deployment f29be0

Fix "Maximum call stack size exceeded" in jsbuild

mage/requirejs/static.js patches the global require.load and parks the
previous function on require._load. That patch is not idempotent, and its
modules are reachable two ways on a FireCheckout page: as the plain
<script> we inject after require.js, and via the bundles entry below.
requirejs keeps `defined` per context, so with a second context on the
page (e.g. "$" next to "_") the jsbuild factory runs twice: require._load
then holds the first wrapper, whose own fallback is itself, and
require.load recurses forever. Symptoms are the RangeError plus
"Load timeout for modules: mage/requirejs/text".

Pin require._load to the real loader before static.js can install the
wrapper, so any number of jsbuild evaluations stay harmless.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> bed9ef

Replace curl-powered deployment with Asset\Publisher
This commit should improve speed of jsbuild in development mode a13472

Replace curl-powered deployment with Asset\Publisher
This commit should improve speed of jsbuild in development mode 46c4d4

Version 1.9.0 910446

Version 1.9.0 1ed62b

docs(property-panel): clarify bcb:fieldRowReady scope and caveats (#46)

Code review found the header comment read as a blanket claim ("a field
row" fires the event) when only ordinary ungrouped props built by
_renderSingleProp actually emit it — the label row and grouped props
(e.g. spacing) don't. Also note $row isn't attached to the live panel
yet at fire time (no layout reads), and that renderer is a shared
singleton per prop.type that subscribers must not mutate.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> a68c9f

Emit bcb:fieldRowReady extension point for field rows a9234a

feat(property-panel): emit bcb:fieldRowReady extension point for field rows (#46)

After a field row is built, appended to the form, and bound on change,
property-panel.js now fires 'bcb:fieldRowReady' on $(document) with
{ prop, component, $row, $field, renderer }. A third-party module can
subscribe and append a control to $row without patching this file or
reaching into the DOM, and without touching $field's value collection
or change binding.

Also documents the field-renderer contract (render/getValue) as public
in the file header, since the extension point relies on it.

No new AMD registry and no wrapper around $field — the two walls
described in the issue stay as they are; this only adds the missing
hook point. d841c3

feat(FeaturedProduct): introduce less variables 9d348a

refactor(FeaturedProductRenderer): replace image URL and alt text with pre-rendered HTML 623392

Fixed FAQ items readability on light theme, closes #44 091320

Fixed avoid using self-closing tag with non-void html element 9a3123

Added hide on pages checkbox list prop type ccf9e8

Updated dependent fields logic 278125

feat(accordion): enable product attribute as body source for FAQ items b26684

feat(accordion): add support for per-item icons in FAQ items b7607f

Correct page cleanup when BCB is closed a40061

Merge pull request #38 from breezefront/feat/108-newsletter-and-missing-components

feat(components): inline newsletter layout (#108) 57dafb

fix(components): newsletter heading follows an inherited text colour (#108)

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> c56d7d

fix(a11y): real heading elements and decorative icons (#41)

Newsletter rendered its section heading as <div class="...__heading h2">:
invisible to assistive technology and absent from the document outline,
even though it is the heading of a page band. It now emits a real h1-h6
element chosen by a new heading_type prop (default h2), matching what
text_block already does. Same fix for the featured_product name, which
was also a styled div.

Breeze styles the tag and the class off a single selector list -
`h2, .h2 { ... }` in theme-frontend-breeze-blank/web/css/base/
_typography.less - so under a Breeze theme, dropping the class for the
tag is visually neutral. Under a non-Breeze theme .h2 is not styled at
all, so those headings were rendering as plain body text and now pick up
the theme's own h2 size: a fix rather than a regression, but not a no-op.
Either way it changes the markup of existing pages, which is why this is
split out of #38.

text_block borrowed the heading text for its icon alt and wrapped inline
SVG in a plain div, so a screen reader announced the heading twice, or
three times when the SVG carried its own <title>. The icon is decorative
in every design that uses it: alt="" on the image branch, aria-hidden on
the SVG wrapper. A case that needs a real name should get an explicit
icon_alt prop rather than reusing the heading.

The admin H1 guard only fired on banner's headline_type, so raising a
text_block - and now a newsletter - to H1 skipped the warning. It now
watches heading_type too; _countH1 already counted both.

Also corrects the selector these three comments cite: the rule is
`h1, .h1` in the Breeze theme, not `:where(h1), .h1` in the module.

product_grid was checked and already emits a real h2. Accordion item
titles remain divs wrapping an <a> trigger; the heading+button pattern
there is a larger change and stays open.

Refs #41 53edaa

fix(components): collage layout for flat-colour CTA, decorative icon a11y (#108)

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> 6e2743

feat(components): inline newsletter layout (#108)

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> 85ed20

Changes for header/footer page: publish spinner, layout picker with images 25b2ae

Version 1.2.2 214d13

Fixed ignored text color when heading used in content c92d33

Explicitly set navigation item paddings cb77b1

Added labels for footer containers 780d47

Version 3.2.2 330f6d

Allow to remove `displaY:block` from complex prices markup 389332