Recent Activities

Version 1.0.4 b799fb

fix: fix exit intent trigger compatibility with Firefox ec09ae

Version 1.1.6 a38173

fix: improve slider accessibility and hide empty title bf25aa

fix: update default heading tag and title class 39ca0c

Version 1.1.5 ee2259

style: hide default pager from items template in highlight widget 09b318

perf: optimize image loading priority for highlight products e5f047

Version 1.7.42

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

Merge pull request #65 from swissup/fix/stale-quick-view-section-64

fix: drop stale popup sections on page load (#64) 0ed54a

fix: ignore the data_id marker when spotting a stale payload (#64 review)

Every section the server answers is stamped with data_id, blocks or not, so
`_.isEmpty()` saw a marker-only ajaxpro-product as a payload and cleared it on
every page load.

On Breeze that clear also removed the storage entry behind customerData's
back, leaving the section_data_ids cookie pointing at a data_id that was no
longer stored — getExpiredSectionNames() then reported the section expired and
reloaded it on every page. Breeze writes storage in reload() alone and its
set() only touches the observable, so clearing the observable is enough.

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

fix: drop only the product payload, once per page (#64 review)

Clearing every popup section also emptied ajaxpro-cart, which
view/minicart/override.js reuses: it opens the cart popup straight from the
markup rendered on page load and only reloads the section when that block is
empty. With the section cleared, every page load triggered an extra
section/load and a minicart click in the first second opened nothing.

Breeze needs the storage entry removed as well — its customerData.set() only
writes the observable, storage is written by reload() alone, so init()
re-hydrated the stale payload on the next page.

Drop the payload once per page: create()/initialize() run again on a
re-created component, when the storage may hold a payload that has just
arrived.

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

fix: drop stale popup sections on page load (#64)

Since disposableCustomerData was dropped in 1.7.36, ajaxpro-product keeps the
product view rendered for a Quick View in mage-cache-storage, and both
component flavors hydrated it back on every page load. That injected a whole
foreign product view into every page — duplicate #product_addtocart_form,
duplicate .column.main, an add-to-cart url pointing at the wrong product —
kept out of sight only by the modal styles.

A popup payload is only meaningful right after the action that produced it, so
anything still stored at page load is stale: clear it instead of binding it.
Live updates keep working through the subscription.

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

Version 1.7.41

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

Merge pull request #62 from swissup/fix/popup-image-styles-61

fix: keep popup image styles off the listing thumbnails (#61) 284113

fix: keep popup image styles off the listing thumbnails (#61)

image_with_borders.phtml renders every product image with a
`product-image-container-<productId>` class and emits a global `<style>`
sizing that class. The ajaxpro-product section renders the same products as
the listing and lands in the document after it, so its rules won and the
listing thumbnail of that product took the popup image size - a 240x300
tile collapsed to 140x140, on page load already, since the stored section
is rendered into the popup wrapper every time.

The section markup now goes through ProductImageStyles::isolate(), which
renames the per-product class (`ajaxpro-` prefix). The popup keeps its own
sizes, the listing keeps its own, and the `product-image-container` base
class that themes style is untouched.

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

Sync code with Magento ("style" position inside listing) bf79c2

Version 1.49.5 a40b6d

Version v1.8.4 eac18a

Merge pull request #27 from swissup/fix/duplicate-switcher-language-id

Fix duplicate switcher-language ID on mobile header switcher a8be67

Fix duplicate switcher-language ID on mobile header switcher

store_language_mobile rendered the same Swissup_Easyflags flags.phtml
template as the desktop store_language switcher but never passed
id_modifier, so both blocks emitted id="switcher-language" and stayed
in the DOM together across breakpoints (only CSS toggled visibility).

Pass id_modifier="mobile" for the mobile block, matching the pattern
already used by navigation.language.switcher (id_modifier="menu").
Desktop store_language keeps the unmodified id for backward compat. 2b04a8

Move easyslide mixin into the swiper bundle group

The easyslide widget itself is bundled under the "swiper" group
(declared by module-easy-slide's own breeze_default.xml), not
"default" - a mixin in the wrong group never loads on pages that use
the slider, since bundle groups only fetch when one of their own
items' load trigger fires. 92057e

Merge pull request #26 from swissup/fix/easyslide-centered-slides-cls

Fix CLS from EasySlide centeredSlides re-center on init 9855dc

Fix CLS from EasySlide centeredSlides re-center on init

centeredSlides re-centers the active slide via a CSS transform once
Swiper mounts, moving already-painted content and counting as a
layout shift on every page load that uses this admin option.
startRandomSlide already hides the slider (opacity: 0) until Swiper
reports init - reuse that same reveal step for centeredSlides via a
theme-level mixin, so the re-center happens before anything is shown. 5f9992

Version v1.8.3 cf5afd

Merge pull request #25 from swissup/claude/busy-chebyshev-550a8e

Fix remaining homepage CLS contributors on 420shop.nl 38a7a7

Fix hero slider CLS regression on autoplay transitions

Live Lighthouse re-test on staging (after the earlier round of homepage
CLS fixes) surfaced a new contributor: switching to the next autoplay
slide caused a ~0.106 layout shift on its own, larger than everything
fixed in the previous commit combined.

Root cause: Swiper's autoHeight option resizes .swiper-wrapper to match
the currently active slide's own box. slider.phtml computes a real
per-image aspect-ratio for every slide, so any two slides with
different native image ratios produce a different wrapper height -
autoHeight then reflows the page on every transition between them.

Fix, scoped to this theme's slider.phtml/// _slider.less override only:
- Force autoHeight off in the JS config passed to the Swiper widget,
regardless of what's stored in the admin slider config.
- Only give the first (initially visible) slide its own precise inline
aspect-ratio, to still reserve the correct box before it loads.
Other slides fall back to the shared CSS aspect-ratio in
_slider.less, so the wrapper's reserved height is fixed once and
never changes as autoplay rotates through slides.

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

Fix remaining homepage CLS contributors on 420shop.nl

Follow-up to the hero-slider CLS fix (#24) — a fresh mobile Lighthouse
run against staging still showed CLS 0.244, unrelated to the slider.
Root causes traced and fixed:

- .jumbotron.hero.block-news (the "Nieuw op 420shop" carousel) was
excluded from the existing min-height reservation, and
#hr_frontPage_box_1/_2 placeholders had no reservation at all —
both left main#maincontent > div.columns to reflow as content
loaded. Added both to the reserved-height selector groups
(mobile + critical-CSS duplicate, kept in sync).

- Hot-stuff promo images (bong/rolling-tray/grinder) have width/height
HTML attrs but no matching CSS aspect-ratio, because their
argento-grid/col-md-4/.image markup was copied from the unrelated
Argento theme family and never got real grid/image CSS in this
Breeze-family theme. Added a scoped aspect-ratio + object-fit rule
for .block-hot-stuff .image img, mirroring the EasySlide fix
pattern, plus flex on .argento-grid to remove the unclearfixed
float ambiguity.

- Same missing-aspect-ratio gap existed on .swiper-slide
.product-image-photo (Bestsellers/NewList carousels); added
aspect-ratio matching the theme's category_page_grid image config.

- Child theme's own Barlow Semi Condensed font-family declarations
used a plain sans-serif fallback instead of the metric-matched
fallback faces already defined in the parent theme, causing
avoidable reflow on font swap. Switched to the full fallback chain
in the 6 places that had it wrong.

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

Merge pull request #24 from swissup/fix/hero-slide-cls

Fix high CLS on hero slider (theme override of easyslide templates) 4ef475

Potential fix for pull request finding

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> be0239

Potential fix for pull request finding

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> 465ba1

Potential fix for pull request finding

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> efa291

Move slider CLS-fix CSS into custom/vendor/_slider.less

Follows the existing _cart.less/_faq.less/etc convention instead of
growing the already-700+-line _custom.less further.

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

Fix high CLS on hero slider (autoHeight collapses slide before Swiper init)

Same root cause and fix as swissup/module-easy-slide#42: slide has no
reserved height before JS runs, and Swiper's autoHeight only sets the
real height after init/image load - visible jump, reported as
0.36-0.47 CLS on the homepage.

Overriding here (rather than waiting on the module release) so it
ships to 420shop.nl now:

- Swissup_EasySlide/templates/{slider,image}.phtml: theme override
of the module templates, carrying the same fix (inline aspect-ratio
per slide, eager+fetchpriority=high on the first slide)
- web/css/_custom.less: matching aspect-ratio/object-fit rules next
to the existing .easyslide-description customizations

Once module-easy-slide#42 is merged and released, these template
overrides can be removed (composer bump + delete the two files).

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

Fixed extracting clean path from iframe URL when layout builder is used 1a5b3b

Merge pull request #34 from breezefront/fix/default-scope-theme-resolution

fix(theme-resolver): resolve Default scope theme from store views 900bf4

test(theme-resolver): cover inactive default store view and all-inactive website

Third review round over c0ae76c found no defects in the fallback ordering
itself, but two branches of it were untested: the scope's default store view
being switched off (the resolver must move on to the first active view, as the
scope selector does) and a website whose store views are all switched off
(nothing to preview, nothing to fall back to). 1b3a31

fix(theme-resolver): follow the previewed store view in the theme fallback

Review of the previous commit (mine and Copilot's) landed on the same problem:
the fallback took the first themed store view out of `getStores()`, in store-id
order, including disabled ones. The scope selector previews a specific store —
the default website's default store for Default scope, the website's own default
store for a website scope (StoreDataProvider::getDefaultStoreId()) — so on a
multi-theme setup the editor could load and save settings for one theme while
the iframe rendered another, with no visible effect from a publish.

The candidate list now mirrors that order: the scope's default store view first,
then its other store views, and inactive views are skipped entirely — their
theme is rendered nowhere. Walking past the previewed store view stays as a last
resort, matching StoreDataProvider's own fall back to the first active store; it
is reachable only when the previewed view has no theme in any scope, where
Magento renders its built-in default and there is no assignment to follow.

The blanket `catch (\Exception)` also reported infrastructure faults as
"No theme is assigned … Assign a theme in Content > Design > Configuration",
losing the real cause. A missing website/group/store stays silent (expected
input); anything else is logged as a warning with the exception attached.

Verified on the local stack with the default-scope row deleted: Default scope
resolves to theme 25 when the previewed store view (store 1) has it, instead of
theme 17 from the lower-id store 3 that the previous commit returned; website
scope resolves through its own default store the same way. Tests: PHPUnit 905. c0ae76

Version 1.0.16 1bcff1

fix(theme-resolver): resolve Default scope theme from store views

The Theme Editor failed with "Unable to determine theme for scope default /
scopeId 0" on installs where design/theme/theme_id was never saved for the
Default Config scope — themes assigned per store view only. Website and store
scopes read that value through ScopeConfig and inherit it; the default scope has
nothing above it, so the lookup came back empty and the resolver threw. The
admin toolbar already fell back to DesignInterface, so the editor loaded and
only the config query failed, which is what the client saw.

getThemeIdByScope now falls back to a store view's theme when the requested
scope has none of its own: the default store view first (then any other one)
for the default scope, and the website's own store views for a website scope.
Store scope keeps no fallback — it inherits from default already, so an empty
value there means nothing is assigned anywhere.

When nothing can be resolved the message now names the cause and the fix
instead of the scope tuple: which scope has no theme, that no store view has
one either, and that a theme has to be assigned in Content > Design >
Configuration followed by a cache flush.

Not a regression from 1.0.15 — that release only touched GraphQL auth headers.
The resolver has behaved this way since multi-scope support was added (5d43943).

Verified against the local stack with the default-scope row deleted: the old
code reproduced the client's exact error, the new code returns a valid config
for both default and website scope. Tests: PHPUnit 904. c085d4

Version 1.6.17 e63fa2

Version 1.6.17 61f0d4

Fixed double-escape in email template c41827

Mage-OS 3.5.0 compatibility: moved block used in email from Adminhtml f636e5

Version 1.2.5 a03b88

fix: improve accessibility e3fbc8

Version 1.2.4 baec1c

Improve Style af5c43

Version 1.3.11 4bec93

fix: 404 page problem #52 b8e23f

fix: improve accesibility 9952f1

fix: problem with small images #51 16c570

Version 1.3.10 67bce0

fix problem with small images 6e172b