feat: add extra fields#144
Open
ahuininga-orisha wants to merge 6 commits into
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes #25
The Tweakwise XML feed specification defines
<brand>,<image>, and<url>as dedicated first-class fields on every<item>element. Without these fields populated, Tweakwise JS integrations cannot render product images or link to product pages directly from the feed, and brand-based filtering or display relies on the generic<attributes>block rather than the purpose-built field. This change adds all three fields to the export feed and makes the source attributes configurable per store view so merchants with a custom brand attribute (e.g.toppy_brandinstead ofmanufacturer) can wire it up without code changes.<url>is now written as a fully qualified product URL, built from the store's base URL, the product'surl_keyattribute, and thecatalog/seo/product_url_suffixconfig value (e.g..html). This ensures the URL is valid and store-scoped.<image>is now written as a fully qualified media URL, resolved by prepending the store's media base URL and thecatalog/productpath prefix to the relative image path stored in the configured image attribute.<brand>is written from the value of a configurable attribute. If the attribute is a select (e.g.manufacturer), the option label is resolved — not the raw option ID.isGroupedExport, brand attribute code, base URL, media URL, URL suffix) are resolved once per store before the product loop viabuildStoreContext, avoiding redundant lookups on every product.How to test
Scenario 1 —
<url>and<image>appear in the feed with correct valuesimage.url_keyand animageassigned.bin/magento tweakwise:export.var/feeds/tweakwise.xml).<item>element for the product from step 3.<url>element is present and equals{store_base_url}/{url_key}{url_suffix}(e.g.https://example.com/my-product.html).<image>element is present and equals{store_media_url}/catalog/product{image_path}(e.g.https://example.com/media/catalog/product/m/y/my-product.jpg).Scenario 2 —
<brand>is exported as the option label, not the raw option IDmanufacturer.<item>in the feed.<brand>Acme</brand>is present with the label, not a numeric option ID.<brand>element is written.Scenario 3 — Custom brand attribute is respected
toppy_brand).<brand>in the feed contains the value from that attribute.Scenario 4 — Disabling image or brand omits the field and skips loading EAV data
-- Disabled --and save.<brand>or<image>element appears in any<item>.Scenario 5 — Products without
url_keyor image produce no empty elementsno_selection) and nourl_key.<url>or<image>elements are written for that product.Scenario 6 — Brand and image attributes vary per store view
manufactureron the default store view.-- Disabled --.<brand>elements appear for the default store view products but not for the second store view products.