feat(themes): Similar products using product tag & <salla-products-list>

[ashrafreda]

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

• Support group of products by the current product tag.
• You can use it to display products under similar tag like: color, size.

What is the current behaviour? (You can also link to an open issue here)

What is the new behaviour? (You can also link to the ticket here)

Does this PR introduce a breaking change?

Screenshots (If appropriate)

[codacy-production]

⚠️ Codacy found a medium Security issue: Unsafe assignment to innerHTML

The issue highlighted by ESLint regarding "Unsafe assignment to innerHTML" indicates that directly assigning a string to innerHTML can lead to security vulnerabilities, such as Cross-Site Scripting (XSS) attacks. This is particularly concerning if any part of the string being assigned can be influenced by user input or external data, as it may allow malicious scripts to be executed in the context of the page.

To fix this issue, we should use a safer method for setting the content, such as creating elements and setting their properties without using innerHTML. Here's a suggested change that creates a document fragment to safely append the elements:

Suggested change

this.innerHTML = `

this.innerHTML = ''; const link = document.createElement('a'); link.href = this.product?.url; link.className = 'inline-block'; const img = document.createElement('img'); img.className = 's-product-card-image-cover w-16 h-16 rounded-full lazy border-2 border-white transition-all duration-300 hover:border-primary hover:scale-105'; img.src = this.placeholder; img.alt = this.product?.image?.alt; img.setAttribute('data-src', this.product?.image?.url || this.product?.thumbnail); link.appendChild(img); this.appendChild(link);

This change constructs the elements programmatically, which helps mitigate the risk of XSS by avoiding the use of innerHTML.

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical Security issue: User controlled data in a this.innerHTML is an anti-pattern that can lead to XSS vulnerabilities

The issue identified by the Semgrep linter relates to the assignment of user-controlled data to this.innerHTML. This practice can lead to Cross-Site Scripting (XSS) vulnerabilities if any of the data being rendered (such as this.product?.url, this.product?.image?.alt, or this.product?.image?.url) is not properly sanitized. An attacker could potentially inject malicious scripts if they can control the values of these properties.

To mitigate this risk, it's advisable to use a method that safely sets the content of the element, such as using textContent for text and setting attributes via setAttribute for URLs and images.

Here’s a suggested one-line change to avoid using innerHTML directly:

Suggested change

	this.innerHTML = `
	this.querySelector('a').setAttribute('href', this.product?.url); this.querySelector('img').setAttribute('src', this.placeholder); this.querySelector('img').setAttribute('alt', this.product?.image?.alt); this.querySelector('img').setAttribute('data-src', this.product?.image?.url || this.product?.thumbnail);

This change assumes that the anchor and image elements are already present in the DOM, and it directly sets their attributes instead of using innerHTML. If those elements are not present, you would need to create them first, which would require a more extensive modification.

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical Error Prone issue: You have a misspelled word: href on Template

The issue reported by ESLint indicates that there is a misspelled word in the href attribute within the template literal. This is likely a false positive or a misinterpretation by the linter, as href is a standard HTML attribute. However, to ensure clarity and correctness, we can explicitly quote the attribute values in the template literal to avoid any potential parsing issues.

Here's the code suggestion to fix the issue by adding quotes around the href attribute value:

Suggested change

	this.innerHTML = `
	<a href="${this.product?.url}" class="inline-block">

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical Security issue: User controlled data in methods like innerHTML, outerHTML or document.write is an anti-pattern that can lead to XSS vulnerabilities

The issue identified by the Semgrep linter pertains to the use of innerHTML to set HTML content, which can introduce Cross-Site Scripting (XSS) vulnerabilities if any part of the HTML string is derived from user-controlled data. In this case, the this.product?.url, this.product?.image?.alt, and this.product?.image?.url || this.product?.thumbnail could potentially be influenced by user input, making it unsafe.

To mitigate this risk, we should avoid using innerHTML and instead use DOM manipulation methods that properly escape user-controlled data. A simple and effective change would be to create the elements using createElement and setAttribute methods.

Here's the single line change to address the issue:

Suggested change

this.innerHTML = `

this.innerHTML = ''; const anchor = document.createElement('a'); anchor.href = this.product?.url; anchor.className = 'inline-block'; const img = document.createElement('img'); img.className = 's-product-card-image-cover w-16 h-16 rounded-full lazy border-2 border-white transition-all duration-300 hover:border-primary hover:scale-105'; img.src = this.placeholder; img.alt = this.product?.image?.alt; img.setAttribute('data-src', this.product?.image?.url || this.product?.thumbnail); anchor.appendChild(img); this.appendChild(anchor);

This change creates the anchor and image elements programmatically, which helps to prevent XSS vulnerabilities by avoiding direct assignment of potentially unsafe HTML.

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical Error Prone issue: Import path mush be a path alias

The issue reported by the ESLint linter indicates that the import path for BasePage should use a path alias instead of a relative path. Path aliases are often configured in a project to simplify imports and make them more readable, especially in larger codebases. The linter is suggesting that you should use a defined alias rather than a relative path.

To fix this issue, you would need to replace the relative import path with the appropriate path alias. Assuming that the alias for the base page is defined as @pages/base-page, you can update the import statement as follows:

Suggested change

	import BasePage from '../base-page';
	import BasePage from '@pages/base-page';

---

This comment was generated by an experimental AI tool.