Updating to Venta Theme 1.7.1 (product list and PDP gallery) ​

1.7.1 sits on top of 1.7.0.1 and carries 21 tickets across the theme, the theme module, ElasticSuite, Back In Stock and PayPal. Three of them rework surfaces most projects touch: grid/list switching on the product list becomes a client-side CSS toggle with persisted toolbar preferences, the PDP gallery renders through the image resizer, and images placed in CMS content can render as responsive <picture> markup.

One dependency constraint moves - the theme now requires Image Resizer ^0.1.18, and the gallery work depends on it. There is no Magento or Hyvä version change and no build-stack migration.

One removal breaks silently for projects that override the ElasticSuite list shimmer.

Recommended reading before starting:

• Updating to 1.7.0.1, if you are not on it yet
• Image Resizer Extension, which produces the renditions and owns the pregeneration command
• CMS Responsive Images, for the directive, the widget and the role sizes
• File Review, for the override reconciliation routine

Breaking change: the list-mode shimmer is gone ​

The list-item-shimmer block is removed from ElasticSuite's view/frontend/layout/hyva_catalog_category_view_type_layered.xml and view/frontend/layout/hyva_catalogsearch_result_index.xml, together with the shimmerCardList config key and getShimmerCardList() in Block/Product/AdvancedCatalog.php. One skeleton now serves both view modes: view/frontend/templates/product/shimmer/grid.phtml mirrors the card structure and the list-mode CSS restyles it, the same way the real card works after MHP-780. product/shimmer/list.phtml is kept on disk but nothing renders it any more.

If your theme ships a product/shimmer/list.phtml override, move that skeleton into your product/shimmer/grid.phtml override before you deploy, then delete the list.phtml override so nobody maintains a dead file. Keep the grid skeleton's markup structurally identical to the real card, since list mode is applied to it by CSS rather than by a separate template.

Two smaller removals in the same block, which do fail loudly:

• getDefaultListMode() was public. Any template, subclass or module calling it breaks.
• The constructor no longer takes Magento\Catalog\Helper\Product\ProductList. A subclass of AdvancedCatalog that forwards the old argument list, or a di.xml entry that supplies that argument, fails DI compilation.

The infinite-scroll JSON config no longer carries shimmerCardList either, so custom JS reading it gets undefined.

The commands that tell you whether any of this applies to your project are in the pre-flight checklist.

Prerequisites ​

• Venta Theme 1.7.0.1. If you are further back, work through Updating to 1.7.0.1 first, and the guides before it as needed.

• Node 20 or newer for the theme build, as in 1.7.0. The child-theme CSS rebuild is mandatory in this release rather than an optional follow-up, and it has to happen inside the maintenance window (§3).

• Image Resizer 0.1.18. The theme's constraint moves from ^0.1.17 to ^0.1.18, and the PDP gallery needs it. Confirm the version is reachable before you start:

  bash

  composer show magebitcom/magento2-image-resizer -a | head -20

• Nothing else on the server side. Hyvä stays at 1.5.2, Hyvä Checkout at 1.3.12, and Magento stays where it is.

Pre-flight checklist ​

Run this while the project is still on 1.7.0.1. It produces the rebase worklist, and it finds the two changes nothing tells you about at deploy time: the removed shimmer and a project view.xml that shadows the new roles.

1. Inventory your template overrides in the reworked areas ​

git -C app/design/frontend/<Vendor>/<ProjectTheme> ls-files \
  'Magento_Catalog/templates/product/list/**' \
  'Magento_Catalog/templates/product/view/gallery*' \
  'Magento_Swatches/templates/product/listing/**' \
  'Magento_Theme/templates/html/footer.phtml' \
  'Magento_Wishlist/**' \
  'Magento_Sales/**' \
  'Hyva_Checkout/**'

Everything this prints goes on the worklist for §6, which lists what each file needs.

Two entries have to be resolved before the deploy, because deploying without them ships a regression rather than a stale template:

• Magento_Theme/templates/html/footer.phtml. Nothing else renders the reCAPTCHA notice after this release, so a stale footer override means the storefront carries no disclosure at all.
• product/shimmer/list.phtml, from the check below.

The rest can be re-based after the deploy. An unreconciled product-list or gallery override leaves the old behaviour in place; it does not remove a disclosure or break the build.

2. Check for the removed shimmer and AdvancedCatalog API ​

find app/design/frontend/<Vendor>/<ProjectTheme> app/code -path '*shimmer/list.phtml'
grep -rn "shimmerCardList\|getDefaultListMode" app/design app/code \
  --include='*.phtml' --include='*.php' --include='*.js' --include='*.xml'
grep -rn "AdvancedCatalog" app/code app/design --include='*.php' --include='*.xml'

The third grep is the one that catches the DI-compile failure. A subclass forwarding the old constructor argument mentions neither shimmerCardList nor getDefaultListMode, and a di.xml argument or a layout XML reference to the removed list-item-shimmer block only shows up once XML is in scope. See the breaking change for what each hit needs.

3. Check for a project view.xml ​

find app/design/frontend/<Vendor>/<ProjectTheme> -name view.xml

If that prints a path, the project file shadows the vendor one entirely and has to be reconciled in §2 before the deploy. If it prints nothing, the project inherits Venta's file and there is nothing to do.

What changed ​

Product list view modes switch client-side ​

Grid/list switching no longer reloads the page. The switcher toggles a class on the products wrapper, the choice is stored in the product_list_toolbar_preferences localStorage entry, and Magento_Catalog/templates/product/list/js/view-mode-restore.phtml re-applies it inside the products wrapper before first paint. No reload, no AJAX request and no URL change, on both the category and the search list.

What this means for the markup:

• Magento_Catalog/templates/product/list.phtml always renders the grid card. The legacy Magento_Catalog/templates/product/list/item-list.phtml card is retained but no longer rendered, in the same way as the shimmer template above.
• List view is styled by a new mode-list Tailwind variant in web/tailwind/base/custom-variants.css, active under the wrapper's products-list class, with the differences written inline as mode-list: utilities in the card templates. web/tailwind/components/product.css keeps only the list price styling, scoped by products-grid-card.
• The grid card renders the list-only regions (mobile name header, short description, attribute list, compare checkbox, list add-to-cart and wishlist rows) inside wrappers that are hidden in grid mode and shown through mode-list:contents. They render only when the product list passes the show_description flag, which is set when the mode is switchable or list is the configured default, so widgets, carousels and grid-only stores keep the lean grid card.
• The switcher and the client-side toggle are gated on a products-mode-switchable wrapper class, which comes from isModeSwitchable() on the theme module's toolbar block. That needs the view switcher enabled on the block and more than one allowed view mode, so List Mode under Stores > Configuration > Catalog > Catalog > Storefront has to be "Grid (default) / List" or "List (default) / Grid". On "Grid Only" or "List Only" the store keeps its configured layout and renders no switcher, which is also why widgets and carousels (they disable the switcher on the block) never get one.
• The listing swatch renderer drops the is_list_mode flag. It always renders every option, kept in the DOM under the grid visibility classes, and one legend revealed in list mode through mode-list: utilities.

Two server-side consequences:

• getCurrentMode() in the theme module's Block/Product/ProductList/Toolbar.php resolves the view mode from store configuration alone. It ignores the request parameter and the toolbar session, so a product list URL has a single full-page-cache variant and legacy ?product_list_mode= links render identical markup.
• The product list item block cache key now includes show_description, so the lean widget/carousel cards and the full product-list cards are cached separately. This ships as a preference on Hyvä's ProductListItem view model. A project with its own preference on that view model has to fold the new cache key in.

ElasticSuite's category Alpine store no longer tracks the view mode and no longer resets pagination when the mode changes, so switching mode mid-scroll keeps the products already loaded.

Sort order and page size persist ​

The selected sort order, direction and items-per-page are written to the same product_list_toolbar_preferences localStorage entry on toolbar change. A new Magento_Catalog/templates/product/list/js/toolbar-preferences-js.phtml is rendered in <head> on category pages and applies the stored values before first paint, so the toolbar never flashes the store defaults.

The preference is applied by rewriting the URL with location.replace(), so a returning visitor whose stored preference is not already in the URL gets one client-side redirect on the first category page of the session. Explicit product_list_order and product_list_limit parameters in the URL always win, and categories with the "Static block only" display mode are skipped.

• Each sort and page-size combination is its own full-page-cache variant, exactly as it was before when a customer used the toolbar. Nothing new to configure, but a busier long tail of cached URLs.

PDP gallery renders through the image resizer ​

The product gallery served the Magento-generated sizes. It now renders slides, thumbs and the fullscreen dialog through the image resizer with width descriptors and sizes, backed by new etc/view.xml roles (§2). catalog:images:pregenerate covers those roles under the "PDP gallery images" label (§4).

Magento_Catalog/templates/product/view/gallery.phtml is split into partials under Magento_Catalog/templates/product/view/gallery/: picture.phtml, thumbs.phtml and fullscreen-dialog.phtml. A project that overrides gallery.phtml has to re-base onto the split; it is the largest template change in the release.

Along with it:

• Image preload links carry imagesizes with separate mobile, tablet and desktop bands, and no longer carry a width descriptor in the href.
• The PDP sticky bar image reuses the gallery hero rendition instead of requesting its own.
• The hero image paints without waiting for the JavaScript reveal, and a placeholder data URI is no longer left as the final image when the reveal component never initialises.
• Single-image galleries reserve their height, so the page no longer shifts on load.
• The lightbox no longer serves the tablet rendition on desktop, and sizes itself independently of viewport height.
• WebKit no longer preloads the hidden thumbnail strip below the lg breakpoint.
• The sticky bar no longer stays hidden for the rest of the scroll when the out-of-stock form fires during its reveal window.

CMS responsive images ​

An image dropped into a CMS page or block through the WYSIWYG editor was served as the uploaded file: full size, original format, no retina variant and no lazy-load placeholder. 1.7.1 adds a directive and a "Venta - Responsive Image" widget that render one through the image resizer instead. Both go through the same renderer, so they produce identical markup.

Nothing changes for existing content: plain <img> tags keep working, and conversion is opt-in per image (§5). What the upgrade does need is the four cms_image_* roles, which ship in the vendor theme's etc/view.xml, so a project theme with its own file has to carry them (§2). catalog:images:pregenerate covers those roles under the "CMS responsive images" label, scanning cms_page and cms_block content plus saved widget instances (§4).

The directive parameters, the widget fields, the role sizes and the eager/lazy behaviour are on CMS Responsive Images.

Back In Stock events fire only when the value changes ​

Back In Stock 1.1.1 stops venta-oos-state and venta-oos-form-visibility firing on every render of view/frontend/templates/product/subscribe.phtml. They now fire only when the value changes, so custom JS listening on either sees fewer events than before.

category_logo is back in view.xml ​

The 1.7.0 view.xml rework dropped the category_logo entry, which left subcategory tiles on category pages rendering at their full source size on desktop. The 120x120 entry is restored. Its category_logo_mobile sibling was never affected.

The reCAPTCHA notice moves to the footer ​

The "protected by reCAPTCHA" disclosure was repeated under every protected form. It now renders once above the copyright bar in Magento_Theme/templates/html/footer.phtml, driven by a new ReCaptchaNotice view model that also reports whether reCAPTCHA is configured at all.

The per-form notices are removed from the login, login popup, registration, forgot password, account edit, newsletter, contact, coupon and product review forms, and the theme adds a Magento_ReCaptchaFrontendUi/layout/default.xml that removes the shared recaptcha_legal_notice block. Magento's getLegalNoticeHtml() is guarded by a hasElement() check on that block, so removing it empties every per-form notice at once, including the ones in vendor templates the theme does not override (Hyvä checkout login, Send to Friend, Payflow Pro).

Two consequences for overriders:

• If you override Magento_Theme/templates/html/footer.phtml, you do not get the footer notice until you re-base. Nothing else renders it, so the site ships with no disclosure at all.
• If you override any of the nine forms, the notice call in your override now returns an empty string. Nothing breaks, but you are left with an empty wrapper element to clean up.

The compare list is website-scoped ​

The compare list and the header "Compare (N)" link emptied when a customer switched store view. Compare items are now shared across all store views of a website, through a preference on Magento\Catalog\Model\ResourceModel\Product\Compare\Item and a plugin on its collection. A project that already has its own preference on that resource model, or its own store filter on the compare collection, has to reconcile with it.

Configurable variant images in orders, wishlist and cart ​

Configurable items showed the parent product image, or the placeholder, where they should have shown the selected variant. The release fixes:

• the placeholder rendering instead of the variant image for configurable items on the order success page and order view, plus a real placeholder for items whose product no longer exists
• the parent image rendering instead of the variant image on the wishlist and shared wishlist pages
• the wishlist button treating every variant of a configurable as one item, which showed it as saved for variants that were not and removed the wrong item on click
• the wishlist button on the product page saving the configurable instead of the selected variant when the button sits outside the add to cart form
• the placeholder image in the Back In Stock alert email for products with an unassigned thumbnail image role

Storefront fixes ​

Most of these land in templates a project may override, so a row that does not show up on your storefront after the deploy is a re-base job rather than a regression. Check it against §6.

1. Update Composer dependencies ​

{
  "require": {
    "magebitcom/magento2-venta-theme": "1.7.1",
    "magebitcom/magento2-venta-theme-module": "1.7.1",
    "magebitcom/magento2-venta-theme-smile-elasticsuite-module": "1.7.1",
    "magebitcom/magento2-venta-theme-back-in-stock-module": "1.1.1",
    "magebitcom/magento2-venta-theme-paypal": "1.0.3"
  }
}

composer update \
  magebitcom/magento2-venta-theme \
  magebitcom/magento2-venta-theme-module \
  magebitcom/magento2-venta-theme-smile-elasticsuite-module \
  magebitcom/magento2-venta-theme-back-in-stock-module \
  magebitcom/magento2-venta-theme-paypal \
  --with-all-dependencies
composer show magebitcom/magento2-image-resizer   # must report 0.1.18 or newer

The three theme-stack packages share the release version, so ElasticSuite moves to 1.7.1 with the others. --with-all-dependencies is what lets the resizer move up to satisfy the theme's new ^0.1.18; if your project pins the resizer itself, raise that pin in the same run.

The remaining Venta packages have no changes in 1.7.1 and stay where they are: Style Guide 1.0.3 and User Type Switcher 1.0.0. Check the GitHub release for each package before pinning.

2. Reconcile view.xml ​

The CMS image roles, the new gallery roles and the restored category_logo entry ship in the vendor theme's view.xml. A project theme that ships its own file shadows it entirely, and then the renderers resize against roles they cannot resolve.

find app/design/frontend/<Vendor>/<ProjectTheme> -name view.xml

If that prints nothing, skip this step. If it prints a path, copy these entries from vendor/magebitcom/magento2-venta-theme/etc/view.xml:

Under <images module="Magento_Catalog">, for the gallery:

• product_page_image_medium_tablet (342x394) and product_page_image_medium_mobile (412x474)
• product_page_image_fullscreen (1404x1615), product_page_image_fullscreen_tablet (761x875) and product_page_image_fullscreen_mobile (412x474)
• product_page_image_small_mobile (60x70), for the thumb rail

Under <images module="Magebit_VentaTheme">, for CMS images and the category tiles:

• cms_image_hero, cms_image_banner, cms_image_tile, cms_image_inline and their _mobile siblings, each with <frame>false</frame>
• category_logo with type="image" at 120x120, if your file was copied from 1.7.0 or 1.7.0.1 and lost it

3. Rebuild and deploy ​

bin/magento maintenance:enable
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento setup:static-content:deploy -f
bin/magento cache:flush

The CMS image widget is declared in the module's widget.xml, so it appears in the widget chooser once the configuration cache is flushed. Then rebuild theme assets in your child theme. This is not optional in 1.7.1: the mode-list variant, the list-mode utilities on the grid card and the iOS scroll lock all live in the CSS build, so a stale stylesheet leaves list view looking like grid.

cd app/design/frontend/<Vendor>/<ProjectTheme>/web/tailwind
npm ci
npm run build-prod

The rebuild writes new asset files, so deploy static content a second time and only then take the store out of maintenance mode:

bin/magento setup:static-content:deploy -f -t <Vendor>/<ProjectTheme>
bin/magento cache:flush
bin/magento maintenance:disable

4. Warm the image variants ​

Variants are generated on the first request for each image, so an unwarmed store pays for them on live traffic. After this release the command covers the PDP gallery roles as well ("PDP gallery images"), which is the larger of the two sets, so run it even if you use no CMS responsive images yet:

bin/magento catalog:images:pregenerate

Add --async to queue the work instead of processing it inline, then run the consumer:

bin/magento catalog:images:pregenerate --async
bin/magento queue:consumers:start magebit.image_resizer.responsive_generate \
  --single-thread --max-messages=1000

5. Convert existing CMS images ​

Nothing breaks if you skip this: plain <img> tags in CMS content keep working exactly as before. The conversion is opt-in, per image. To find candidates:

SELECT identifier, title FROM cms_block WHERE content LIKE '%<img%';
SELECT identifier, title FROM cms_page  WHERE content LIKE '%<img%';
SELECT instance_id, title FROM widget_instance WHERE widget_parameters LIKE '%<img%';

Widget instances are the third place to look, and the one that is easy to miss. Their parameters are stored in widget_instance.widget_parameters rather than in the CMS tables, and pregeneration scans that table alongside them, so an image placed there is covered the same way.

Replace the tag with the directive, or with the widget through the editor, and pick the role that matches the slot the image sits in. Verify one converted image before doing the rest: the rendered markup should contain a <picture> with a WebP source, and the network panel should show a rendition from media/image_resizer/cache rather than the uploaded file.

The directive is registered on Magento\Widget\Model\Template\Filter, so it also renders in product and category descriptions. Pregeneration does not follow it there. catalog:images:pregenerate scans cms_page, cms_block and widget_instance only, so a directive in a product or category description is never warmed and its renditions are generated on the first request that needs each one.

Re-run pregeneration once the conversions are saved, otherwise the first visitor to each converted page pays for the renditions:

bin/magento catalog:images:pregenerate

6. Reconcile your template overrides ​

Work through the list the pre-flight inventory produced, following the File Review routine. The footer and the ElasticSuite shimmer should already be done, since both had to be resolved before the deploy.

The files most likely to appear, and what each needs:

• Product list card and toolbar. product/list.phtml, product/list/item-grid.phtml, product/list/toolbar/viewmode.phtml, product/list/js/init-toolbar-js.phtml, product/list/quantity.phtml, product/list/price/tier_prices.phtml, product/list/js/compare.phtml and product/list/js/wishlist.phtml. Re-base onto the single-card model: the grid card carries the list regions behind mode-list: utilities, and an override that still renders a separate list card keeps the old reload-based behaviour.
• Gallery. product/view/gallery.phtml split into the gallery/ partials. Re-base rather than patch; the template is substantially different.
• Listing swatches. Magento_Swatches/templates/product/listing/renderer.phtml and product/swatch-item.phtml, which no longer branch on is_list_mode.
• Footer. Magento_Theme/templates/html/footer.phtml, for the reCAPTCHA notice.
• ElasticSuite shimmer. See the breaking change.
• The narrower fixes land in Magebit_VentaTheme::sticky-bar/sticky-bar.phtml, Magebit_VentaTheme::widget/list_block_widget.phtml, Magento_Customer/templates/header/customer-menu.phtml, Magebit_VentaBackInStock::customer/stock/alerts.phtml, the PayPal Express button templates, Magento_Wishlist/templates/item/column/cart.phtml, Magento_Sales/templates/order/info/buttons.phtml, the Hyvä Checkout tooltip, address-list and terms templates, and web/tailwind/components/ui.css, web/tailwind/theme/checkbox.css, web/tailwind/theme/checkout.css and web/tailwind/base/fallback.css.

If you carry a preference of your own on Hyvä's ProductListItem view model, or on Magento\Catalog\Model\ResourceModel\Product\Compare\Item, reconcile it with the theme's: 1.7.1 adds one on each.

Post-upgrade verification ​

1. The bundle loads on the checkout success page. Place a test order through to the success page and confirm venta-bundle.min.js loads with no CSP integrity error in the console. On Magento 2.4.8+ a stale sri-hashes.json blocks it, and the success page is the first place that shows. If it is blocked, re-run setup:static-content:deploy -f after the build-prod run so the hashes match.
2. List view is styled. Switch a category to list view. The cards must take the list layout with no page reload and no URL change. Grid-looking cards in list mode mean the CSS build is stale, so re-run build-prod and static-content:deploy -f.
3. The mode survives navigation. Switch to list, open a product, go back. The list layout must be there on first paint, with no flash of grid.
4. Widget and carousel cards stay lean. A product slider on the homepage must not render the list-only regions (short description, attribute list, compare checkbox). If it does, the show_description flag is being passed where it should not be.
5. Sort and page size persist. Set a sort order, leave the category, come back. The stored value applies before paint, and an explicit ?product_list_order= in the URL still overrides it.
6. Infinite-scroll skeleton is right in both modes. Scroll a long category in grid and in list. The skeleton must match the card in each. A stock skeleton in list view on a project that customised the shimmer means the breaking change was not handled.
7. PDP gallery serves renditions. Open a product. The network panel shows gallery images from media/image_resizer/cache, the hero paints without waiting for JavaScript, a single-image gallery does not shift the page, and the fullscreen dialog serves the desktop rendition on desktop.
8. Variant images are correct. Add a configurable variant to the wishlist and place an order with one. The wishlist, order success page and order view must show the variant image, not the parent or the placeholder.
9. The reCAPTCHA notice renders once. With reCAPTCHA configured, the disclosure appears in the footer and nowhere else. Missing entirely means a footer override needs re-basing.
10. Compare survives a store switch. With two store views on one website, add a product to compare and switch store view. The list and the header count must stay.