<div> that opens before <hr id="system-readmore"> and closes after it<div>. This breaks the browser's HTML parser, which then nests the subsequent <div class="blog-item"> elements inside the first item's content instead of keeping them as siblings in the grid container.As a result, the multi-column grid layout is completely broken — all items appear stacked in a single column instead of being displayed side by side.
Affected template: Cassiopeia (default Joomla 5 template), but this affects any template using the core featured/blog view layouts.
Workaround (template override):
Replace line 87 in default_item.php:
<?php echo $this->item->introtext; ?>With:
<?php
$introtext = $this->item->introtext;
preg_match_all('/<(div|span|p|section|article|ul|ol|li|table|tr|td|th|thead|tbody)[\s>]/i', $introtext, $openTags);
preg_match_all('/<\/(div|span|p|section|article|ul|ol|li|table|tr|td|th|thead|tbody)>/i', $introtext, $closeTags);
if (count($openTags[0]) !== count($closeTags[0])) {
$doc = new \DOMDocument();
libxml_use_internal_errors(true);
$doc->loadHTML('<div>' . mb_convert_encoding($introtext, 'HTML-ENTITIES', 'UTF-8') . '</div>', LIBXML_HTML_NOIMPLIED | LIBXML_HTML_NODEFDTD);
libxml_clear_errors();
$body = $doc->getElementsByTagName('div')->item(0);
$fixed = '';
if ($body) {
foreach ($body->childNodes as $child) {
$fixed .= $doc->saveHTML($child);
}
}
echo $fixed ?: $introtext;
} else {
echo $introtext;
}
?>This only runs DOMDocument when tags are actually unbalanced, so there is no performance impact for well-formed articles.
Root cause: In components/com_content/tmpl/featured/default_item.php (line 87), the introtext is output without any HTML sanitization:
<?php echo $this->item->introtext; ?>When an article's content has an HTML tag that spans the readmore break, the introtext will contain unclosed tags. The template should close any unclosed HTML tags before outputting them.
Note: The same issue likely affects components/com_content/tmpl/category/blog_item.php as well.
5.4
Intro articles should display in the configured multi-column grid layout regardless of how the article content is structured around the readmore break. The template should sanitize introtext output and close any unclosed HTML tags before rendering.
All intro articles are rendered in a single column. The browser's HTML parser nests the subsequent blog-item divs inside the first item because of the unclosed tag in its introtext, breaking the CSS grid layout entirely.
Joomla 5.4.4, Cassiopeia template (default, no child template), PHP 8.x
No response
| Labels |
Added:
bug
|
||
| Labels |
Added:
No Code Attached Yet
|
||
If it does that... Why do I have to check the matching tags though? Hmmm... I did an override, for me this is solved. 🤗 Oh, I'm logged in with a different account on my mobile.
Yes, that's true, even in Joomla! 6.1. However, if the editor is working with DIVs, it simply needs to know what it's doing here.
We actually have the same issue—breaking HTML standards—in other places as well.
If you’re working in the Joomla! default setup and create a free text module, type some text into it, and then load it into an article using {loadmoduleid xxx}, the module is output with an opening DIV by default, while the surrounding
element isn’t closed yet. As a workaround, I’ve simply defined an output layout without DIVs in my own templates, which the editor just has to select in module settings.
But even if that’s not the case, the browser closes the P element itself, thereby correcting the error, and the consequences are less severe.
In my opinion, when using DIVs—which I don’t consider as a standard practice—an editor must ensure that they are closed before using additional functions, such as “read more.” Personally, I would provide the user with such a feature via a module (with the DIV Code in it), as described above, so they cannot place other functions in the wrong spot.
Yes, that's true, even in Joomla! 6.1. However, if the editor is working with DIVs, the editor simply needs to know what it's doing here.
We actually have the same issue—breaking HTML standards—in other places as well.
If you’re working in the Joomla! default setup and create a free text module, type some text into it, and then load it into an article using {loadmoduleid xxx}, the module is output with an opening DIV by default, while the surrounding
element isn’t closed yet. As a workaround, I’ve simply defined an output layout without DIVs in my own templates, which the editor just has to select in module settings.
But even if that’s not the case, the browser closes the P element itself, thereby correcting the error, and the consequences are less severe.
In my opinion, when using DIVs—which I don’t consider as a standard practice—an editor must ensure that they are closed before using additional functions, such as “read more.” Personally, I would provide the user with such a feature via a module (with the DIV Code in it), as described above, so they cannot place other functions in the wrong spot.
Yes, that's true, even in Joomla! 6.1. However, if the editor is working with DIVs, the editor simply needs to know what it's doing here.
We actually have the same issue—breaking HTML standards—in other places as well.
If you’re working in the Joomla! default setup and create a free text module, type some text into it, and then load it into an article using {loadmoduleid xxx}, the module is output with an opening DIV by default, while the surrounding "P" element isn’t closed yet. As a workaround, I’ve simply defined an output layout without DIVs in my own templates, which the editor just has to select in module settings.
But even if that’s not the case, the browser closes the P element itself, thereby correcting the error, and the consequences are less severe.
In my opinion, when using DIVs—which I don’t consider as a standard practice—an editor must ensure that they are closed before using additional functions, such as “read more.” Personally, I would provide the user with such a feature via a module (with the DIV Code in it), as described above, so they cannot place other functions in the wrong spot.
When you insert the readmore element from the button does it not update the content to prevent this from happening. I'm sure it used to do that