Closed jamaa closed 2 years ago
Hi @jamaa,
This is an issue with the widget itself. The shortcode doesn't output empty <p>
tags.
Since you're using the Block editor on your website (a.k.a. Gutenberg), try using the Shortcode block instead.
I am already using the Shortcode block: But I guess the problem is not the plugin then. When you say it's an issue with the widget, does this mean it's an issue with the theme?
Couldn't say. The theme is a paid one so I can't test it unless I buy it (which I won't since I don't plan to use it haha).
One quick way to find out: switch to another theme for a moment (eg. Twenty Twenty One) then check whether the issue persists or not and report back your results.
I am using the free version of Nikkon.
But I do believe it occurs in Twenty Twenty One as well:
Maybe the Shortcode only outputs a linebreak, which is then converted to a <p>
by Wordpress?
looking at my screenshot, I just realized there is an additional empty <p>
after the <h4>
as well
Oh, you're right! I was able to reproduce that with just the shortcode and the Twenty Twenty One theme. How odd. But yeah, it's not the shortcode, it's WordPress doing that for some reason.
I'll see if I can do something to prevent WordPress from adding empty tags to the shortcode (maybe it's as you say: WP may be converting line breaks to paragraphs automatically).
For the time being (since this might take a while, I'm busy with work at the moment) a "hacky" solution would be to hide empty <p>
tags via CSS like so:
.widget_block p:empty {
display: none;
}
I'll leave a comment here with my findings as soon as I can.
Thanks, the CSS workaround works for now.
Alright, so apparently the Block based editor doesn't handle shortcodes very well at the time of writing (current WordPress version is 5.8.1). Here's what I did:
<p>
tags. Removing header_start
, header_end
, wpp_start
, and wpp_end
from the shortcode fixed the issue, no more empty <p>
tags! (But then you can't use your custom HTML markup with the shortcode, it's clear that the Block Editor gets confused when shortcodes use HTML tags in its parameters).<p>
tags.</p>
to their values (eg. when you use header_start="<h4 class='widget-title'>"
the plugin receives </p><h4 class='widget-title'>
). This is what I think causes the bug: when WordPress receives the data returned by the plugin to display the shortcode on screen, it finds these </p>
tags and attempts to close them, hence why you get <p></p>
in your HTML code when the shortcode is finally rendered. This happens with the shortcode when used on the sidebar as well, even if you don't use any HTML-related parameters.Unfortunately this doesn't seem to be something that I can fix from within the plugin. This looks like a WordPress issue.
So, the options we have now are:
<p>
tags until the WP team fixes the problem; or<p>
tags, even on the sidebar. The block also has a Custom HTML option that allows you to change its HTML markup to whatever you want.If you have any questions at all don't hesitate to ask.
Thanks for looking into this. I will definitely try the new WordPress Popular Posts block.
Bug description I am using the following WPP shortcode in a widget (theme: Nikkon https://demo.kairaweb.com/#nikkon ). The HTML output contains an additional empty
<p>
tag before the popular posts list, causing a layout issue.This is the full shortcode I am using:
[wpp header="Beliebte Bilder" header_start="<h4 class='widget-title'>" header_end="</h4>" wpp_start="<ol>" wpp_end="</ol>" range="last30days" limit=10 stats_views=0 order_by="views"]
If you check the footer on https://bilder.mzibo.net and inspect it, you can find an additional empty
<p>
tag before<h4 class="widget-title">Beliebte Bilder</h4>
and see that the heading "Beliebte Bilder" is positioned lower than the other headings, due to this<p>
tag.Admittedly, I am not sure whether this additional
<p>
tag is inserted by the plugin, by the theme, or by Wordpress itself.To Reproduce Steps to reproduce the behavior:
<p>
tag before the<h4>
tagExpected behavior I expect no additional
<p>
tag to be output in the HTML.Screenshots
Environment:
Additional context