richie
richie copied to clipboard
attempt to nest a link in blogpost glimpse breaks home page
Bug Report
Problematic behavior/code On the home page, some featured blog posts are randomly broken:

Looking at the source code, it is due to a <a> tag for the category being inserted inside the <a> tag pointing to the blog post... before the former is closed. The way the browser deals with this unexpected markup is that it takes the initiative to close the <a> tag before opening the new one encountered in the source. That's how the page is broken because the markup is then not the way we expect it.
Expected behavior The piece of code responsible for inserting the tag is here : https://github.com/openfun/richie/blob/master/src/richie/apps/courses/templates/courses/cms/fragment_category_glimpse.html#L5
The has_link context variable is set to False when we don't want the link, which should be the case for the category tag displayed inside a blog post glimpse: https://github.com/openfun/richie/blob/master/src/richie/apps/courses/templates/courses/cms/fragment_blogpost_glimpse.html#L57
The mystery is : why isn't the has_link variable set to False on some random blogposts?
Steps to Reproduce I could not find any explanation to this seemingly random behavior.
Environment
- Richie version: 2.6.0
- Platform: Docker
I saw this during working on a new site for the factory. It happen everywhere blogpost glimpse is involved, so in blogpost list view also. Also this happen on all sites from factory but i did not see anything special to reproduce it clearly, this just happen randomly.
And opposed to this issue title, it is not related to "attempt to nest a link", since there is no way to add a link from content in blogpost glimpse (title and excerpt are only plain text).
I've searched quickly to a resolution to the mysterious "has_link" value and i didn't found anything yet. I thought the "has_link" would be set from another context, but searching for this variable elsewhere (from Richie Python code, Richie templates, DjangoCMS templates or Django base templates) did not raised any result.
@sveetch furthermore, this error does not occured when you are logged in as a publisher. And the only workaround I found for now is to republish the blogpost...
@jbpenrath what you have cited is exaclty the old buggy behavior we did have with the category glimpse in blogpost a long time ago. There was something like a cache around the category plugin and so in the blogpost list and detail it rendered the category glimpse with the variant used inside course glimpse. And when switching as an admin, the cat glimpse recovered the correct render.
I don't remember how we solved it, possibly @sampaccoud did it, maybe ask him if he remember the fix.
As a workaround, what do you think to replace :
{% with category_variant="tag" has_link=False %}
{% show_placeholder "categories" blogpost_page %}
{% endwith %}
by
{% get_page_plugins "categories" blogpost_page as category_plugins %}
{% with category_variant="tag" has_link=False %}
{% for plugin in category_plugins %}
{% render_plugin plugin %}
{% endfor %}
{% endwith %}
Or do you think we should totally remove the use of hasLink ?
So you think show_placeholder is at fault here with has_link value ? Personally i can't tell if it will change our wrong behavior or not, i would think that show_placeholder is using render_plugin so this would not change anything, but really i don't know.
The fact we are unable to reproduce clearly the wrong behavior makes it difficult for a diagnostic. The last thing i thought for an easy patch would be to change "has_link" name for each plugin so they won't affect between them.
Did you tested your solution ?
@sveetch you are right, show_placeholder uses render_plugin to retrieve the content.
As we do not yet find how to reproduce this bug I can't really test my solution from my local environment😞.
But I have some leads to explore from Django CMS.
This issue was fixed in PR https://github.com/openfun/richie/pull/1700 and released in 2.15.0.