This might not be a kirby question per se, but I keep running into this issue with kirby created pages, so maybe I am not the only one and somebody can help me.
If I use kirbytext and use a link tag and put a link into brackets (or add a comma behind it), I get weird line break behaviours, as the link itself is wrapped into an a-tag of course and then the brackets around that don’t “stick” to the tag.
See this screenshot to better understand, what I am talking about:
Is there any way to prevent that and to make brackets, commas and quotation marks stick to the a-tag?
That’s not really under my control, as this will be done by the editors, I’m afraid. Also, the brackets should not be part of the link itself.
Is there maybe some way of Kirby being aware of the surroundings of a tag and then I can treat the stuff accordingly?
I’m really puzzled that I don’t find anybody who has the same problem, because I think I cannot be the only one that has to handle commas after occasional inline links?
This does not really help me, as my issue is not a widow, but rather an unwanted break where there is actually no whitespace but the start or end of an tag.
I have to bump this up, as this issue is still unresolved for me.
Maybe I can ask more generally: Is there any good way to look at the text surrounding the tags and handling tags in relation to this surrounding text? I have now also another case, where I would like to handle a tag differently depending on if it is the last thing withing a textarea field or not. Is there any way to find out stuff like this?
I just tried this and can’t reproduce the described behaviour. Kirby’s default link kirbytag generates perfectly fine HTML for an inline link:
some text ((link: https://example.com text: the link)) more text
turns into
some text (<a href="https://example.com">the link</a>) more text
where both my browsers (Firefox and Chromium, Linux) correctly keep the brackets with the first or last word of the link, respectively. Similarly, a trailing comma sticks with the last word of the link tag.
Could your observed issue be related to some CSS override of the normal wrapping behaviour? I can’t really think of anything else.
I believe the only way would be to use the kirbytags:before hook (considering the order of kirbytext/kirbytag hooks) with an elaborate regex. I did this recently, as I wanted to have an additional attribute added to the link kirbytag before it is being rendered: the following snippet has a regex that detects if a link kirbytag is on a line by itself and adds a class: card attribute to it before Kirby does the rendering.
'hooks' => [
// add a "class: card" to all (link)-kirbytags that are on their own line
'kirbytags:before' => function ($text, array $data = [], array $options = []) {
// the regex detects the "surroundings" of the unrendered kirbytag
$text = preg_replace_callback('/\n\((link)\: (.*?)\)\n/', function ($matches) {
if (strpos($matches[0], ' class: ') !== true) {
// unless the kirbytag already has a class attribute, we add the custom one
return "\n(" . $matches[1] . ': ' . $matches[2] . " class: card)\n";
}
return $matches[0];
}, $text);
// handing back the altered text to the renderer
return $text;
}
],
Maybe this approach could be a lead into the right direction?
Nonetheless, I still believe your problem with brackets and commas is probably not a Kirby issue (or some really odd bug, as I indeed have not been able to reproduce what you describe – I haven’t seen this rendering error in any of my Kirby projects so far).
Thanks @sebastiangreger and @texnixe for looking into this. Strangely, with links I also cannot reproduce this anymore. Since first posting I might have made some changes to my setup, so I am not 100% sure what I changed.
But I do still get this behaviour when using <span> tags that are followed by a comma? @sebastiangreger did you by any chance also test these or did you test the link only? I wonder if this is a general issue with span tags?
Ok. The issue was once again sitting in front of the screen.
For whatever reasons, I had set my span tag to display: inline-block; which just happens to cause this exact issue. The same was probably true for the a tags previously.
Sorry, this really was an oversight on my part.
Still, thanks @sebastiangreger for the kirbytags hook, I think I might use this in my project for the other issue I had.
