there's really not enough information provided, but from the code you provided, here's what I see:
- the filter being used belongs to a plugin, and is used in places where dynamic content needs to be parsed and formatted for any matching terms you've added to a glossary, optionally adding a tooltip for the term. You're passing a static string
"Label: " to this.
- There are some options under CM Tooltip Glossary > Tooltip - Content > Clean
tooltip text? and CM Tooltip Glossary > Tooltip - Content > Avoid parsing
protected tags?. Have you tried toggling those to see if they provide output as you want?
- Since it seems like this is a formatting issue from the parse filter, eliminating any areas it might interpret wrong could help. For example, construct the string itself and output instead of breaking in and out of PHP on different lines. You can use
the_title inside of your
apply_filters call. You most likely would want the parser to check not just the static string
'Label: ' and meant to also include the title in that parse:
<?php echo ! generate_show_title() ?: apply_filters( 'cm_tooltip_parse', the_title( '<p>Label: ', '</p>', false ), true ); ?>
- Since your example code was adding the line breaks after your static string
'Label: ', then that means using the above code output would be in one line as you desire like:
<p>Label: $title</p>. The line breaks from the parser would still exist, and be output after this. You could wrap the output in something like
trim() I guess:
* Trims the following from output string:
* ' ' : Whitespace
* '\t' : tab
* '\n' : newline
* '\r' : carriage return
* '\0' : NUL-byte
* '\x0B': vertical tab
echo ! generate_show_title() ?: trim( apply_filters( 'cm_tooltip_parse', the_title( '<p>Label: ', '</p>', false ), true ), " \t\n\r\0\x0B" );
The remaining issue I can see from the snippet provided looks like it could be caused by invalid HTML.
Take this basic example:
<p> opening tag would be automatically closed in the browser when it encounters the next
<p> opening tag surrounding "something". So with that basic example, the browser would end up rendering it something like this:
What I would try is to change your surrounding
<p> tag into a
<div> first, and your label/title generally should be in some sort of heading tag. I don't know the full page's markup, so it's hard for me to say, but I'll just go with
<h1> element should contain the main "topic" of the page, and since that's what people usually fill in for
the_title - it's probably the right thing to use:
<?php echo ! generate_show_title() ?: trim( apply_filters( 'cm_tooltip_parse', the_title( '<h1>Label: ', '</h1>', false ), true ), " \t\n\r\0\x0B" ); ?>
Published On: <time datetime="<?php echo esc_attr( get_the_date( 'c' ) ); ?>"><?php echo esc_html( get_the_date() ); ?></time></br>
<?php if ( get_field('date_updated') ) : ?>
Updated On: <?php the_field('date_updated'); ?>
<?php endif; ?>
Here we are using a
<div> to signify a block of content which might include other blocks inside of it. In this case, we have a heading element for the title (
<h1>) and the paragraph content is the accompanying text describing the topic details further with meta information, which we have wrapped in a
<p> tag. Heading elements (h1-h6) are called heading content, which I guess are aptly named.
So you might be wondering why the
<time> element isn't breaking to a new line in the output even though when you inspect it you see it displayed on a new line. That's because this is phrasing content, which basically defines the text inside of the tag and any mark-up it might contain. The
<br> is a line break to signify that the paragraph starts back at the beginning of the next line - sorta like a carriage return ( like the
\r we were stripping out above ). This should only be used when dividing the content in a paragraph is important visually, and not used for spacing between paragraphs. Generally speaking, I try to avoid
<br>'s in any markup, but for this situation our output is just text, and a line break is the right thing to use here. The
<br> at the end that you have added after the
Updated On: $date part is not the right thing to use here. I'm assuming this was being used as you have content to follow it - and wanted space beneath to separate the next paragraph. This should be done visually, with CSS. I think we determined you're using GeneratePress theme - and looking at the styles for
<p> it looks like they have a margin applied to the bottom of those elements to help maintain a unified vertical rhythm on your site. With this markup and styles already defined - you probably don't need to apply any additional CSS to adjust it's appearance as it should match the feel of the rest of your site.
Multiple groupings of phrasing content is what makes a paragraph! Plain text is also phrasing content. For a deeper look into content models, the W3C HTML5 spec is full of all the information you would ever need and not need to know. The important part of this though is if we were to run this through an html validator it would pass as proper markup, and browsers would now be able to display it as intended.
Circling back around to the
<div> we used to replace the
<p> that was in your initial code - you can see i added
page-details-with-tooltip as a className to that element. This can be removed if you don't think it's necessary, but I added this to make it easier to apply CSS styles in context of this specific area in case you wanted to make any changes visually to that area. There are other (usually better) ways to write the selector to refer to that area only in specific contexts in WordPress, which you can read about in my answer in question #275909.
I hope this helps you in solving your issue, and gives you some insight as to some of the problems that might have occurred, more importantly, why they might have occurred! It's very difficult to give a definitive answer to something this specific without actually seeing the issue visually and being able to inspect it in the browser as there are many factors which could be causing white space - from the code, to the markup, to the CSS. I was able to get some oddly spaced output though. After this change. I still recommend double checking #4 above about the plugin settings as they probably have some magic stuff going on if they provided an option to enable/disable cleaning up the output that's being parsed/rendered in the filter just to eliminate that off your checklist!