Add data-ps-fragment markers to dynamic fragments

[Codencode]

Questions	Answers
Description?	Adds semantic data-ps-fragment markers for notifications, product-add-to-cart, and product-additional-info, allowing integrations to identify dynamic blocks from the final HTML without adding dedicated before/after hooks or cache-specific logic to the theme. The markers are applied directly to the existing block containers. The notifications container is always present, even when empty, so the fragment can be identified when the page is initially generated and handled dynamically on subsequent cached requests. product-additional-info is also marked because it is already returned by the native product AJAX refresh flow and contains the displayProductAdditionalInfo hook. This allows integrations to regenerate the whole block through the standard ProductController flow instead of rebuilding hook parameters manually. The data-ps-fragment attribute is also documented in CONTEXT.md as part of Hummingbird's semantic data-ps-* attributes. The related LiteSpeed Cache implementation is available in litespeedtech/lscache_prestashop#107 and depends on these markers to isolate the dynamic blocks from the full-page cache and regenerate them through ESI. This approach replaces the dedicated theme hooks previously proposed in #988. If this PR and the related LiteSpeed Cache PR are merged, #988 can be closed.
Type?	improvement
BC breaks?	no
Deprecations?	no
Fixed ticket?
Sponsor company	Codencode snc
How to test?	1. Use the Hummingbird theme with the changes from this PR. 2. Open a product page and verify that the product-add-to-cart container contains data-ps-fragment="product-add-to-cart". 3. Verify that the product-additional-info container contains data-ps-fragment="product-additional-info". 4. Verify that the notifications area is wrapped with data-ps-fragment="notifications" even when there are no notifications. 5. Check that the page renders normally and that the Add to cart block, additional product information, and notifications keep their existing behavior.

[Codencode]

@tblivet I’d be interested in your thoughts on this approach, especially since you had some concerns about the previous hook-based solution in #988.

This PR moves to semantic data-ps-fragment markers instead of adding dedicated before/after hooks to the theme, with the related LiteSpeed implementation in litespeedtech/lscache_prestashop#107.

Do you think this direction addresses the concerns you raised on #988? Any feedback or suggestions would be very welcome.

[Codencode]

@tblivet, a quick follow-up on this PR.

On the LiteSpeed side I’ve now simplified the implementation quite a bit by reusing the native ProductController refresh flow, so the integration no longer needs to duplicate core product/notification logic.

At this point, the main thing I’d like to confirm is whether adding these data-ps-fragment attributes to the Hummingbird markup is acceptable from the theme side.

The intent is for them to act only as semantic markers identifying dynamic blocks such as product-add-to-cart and notifications; they don’t introduce any Hummingbird-specific behavior by themselves.

Do you see any issue with having these attributes in the theme markup, or would this approach be acceptable for Hummingbird?

Thanks 🙏

[tblivet]

Hi @Codencode 👋 I much prefer this approach over the dedicated hooks from #988.
My only hesitation: right now the markers exist to serve a third-party module (LiteSpeed Cache). So I'm wondering whether we should ship the attributes in the theme itself, or only specify data-ps-fragment in the documentation as a public contract that any cache/integration module can rely on.
@kpodemski @jolelievre what do you think?

[Codencode]

Thanks @tblivet, I understand the concern.

From my point of view, having a semantic marker like data-ps-fragment directly in the theme could add value beyond LiteSpeed itself, because it would make PrestaShop themes easier to integrate with external caching or rendering systems without relying on theme-specific classes or IDs.

Of course, this does not mean every cache system would automatically become fully compatible, but I’m working in that direction and I think cache integration is an important topic for a CMS like PrestaShop.

That said, I understand the hesitation about introducing markup mainly driven by a third-party integration, so I’m happy to wait for @kpodemski and @jolelievre’s feedback before pushing this further.