🐛 fix(feed): fix "Visit website" link with skin config

[be-next]

Summary

We've observed an inconsistent behavior in the generation of Atom feed links, specifically regarding the construction of the href attribute for the visit_the_site link. The issue arises depending on the skin variable's value in the config.toml file. When the skin variable is not set (i.e., left as an empty string ""), the XPath expression /atom:feed/atom:link[2]/@href successfully retrieves the intended URL stored in config.base_url. However, when the skin variable is initialized with a value (e.g., "red"), the mentioned XPath expression fails to function as intended, leading to incorrect href values in the generated Atom feed.

This behavior suggests that the insertion of an additional <link> element related to the skin configuration alters the document structure, affecting the index-based XPath selection.

Changes

To address this variability and ensure a more stable and reliable generation of the visit_the_site link, irrespective of the skin configuration or any other dynamic content that might affect the <link> elements order, we propose to directly use the /atom:feed/@xml:base XPath expression. This expression directly targets the xml:base attribute of the <feed> element, which consistently contains the config.base_url value.

This solution offers a more robust approach to determining the href attribute for the visit_the_site link, as it does not rely on the specific order or presence of <link> elements within the Atom feed. It ensures that the link always correctly points to the base URL as defined in the site's configuration, regardless of any changes to other parts of the feed structure.

The suggested change involves modifying the XSL transformation used to generate the Atom feed's HTML representation. Specifically, we will replace the /atom:feed/atom:link[2]/@href expression with /atom:feed/@xml:base for setting the href attribute of the visit_the_site link.

Type of change

• Bug fix (fixes an issue without altering functionality)
• New feature (adds non-breaking functionality)
• Breaking change (alters existing functionality)
• UI/UX improvement (enhances user interface without altering functionality)
• Refactor (improves code quality without altering functionality)
• Documentation update
• Other (please describe below)

---

Checklist

• I have verified the accessibility of my changes
• I have tested all possible scenarios for this change
• I have updated theme.toml with a sane default for the feature
• I have made corresponding changes to the documentation:
  • Updated config.toml comments
  • Updated theme.toml comments
  • Updated "Mastering tabi" post in English
  • (Optional) Updated "Mastering tabi" post in Spanish
  • (Optional) Updated "Mastering tabi" post in Catalan

[welpo]

Nice catch! Thank you.