This at least is a workaround that does what I want.
If there is no other solution, I will consider using this. But I donāt really want to explain to the content managers how to codeā¦
Another option although itās not optimal, is you can add a class to the image that provides a negative top/bottom margin to offset any paragraph tag.
@TheDancingCode
thanks for that! I might actually test that at some point, but since I donāt know what iād be doing but copying code monkey-style, this will unfortunately have to wait until i have more time. but i guess, there is no straight forward solution (or explaination, why it is behaving differently sometimes).
Temporary Solution
btw. when using the Image Caption plugin, they are at least in a <figure> tag which I can use. unfortunatelly only, when i also actually add text or at least a space. which is what i will be doing for now, i guess.
I found another workaround, for anyone interested.
With the shortcode-core plugin installed, you can surround the image in a shortcode such as [div] ![my image](my_image.jpg) [/div] or, more appropriately, [figure] ![my image](my_image.jpg) [/figure], avoids the image being surrounded in paragraph tags, and the shortcode tag can be given a class and styled accordingly: [figure class="a_class"].
Not much different than just using HTML, but itās somethingā and does allow you to keep using markdown image links.
Another update: I referenced this thread and after tinkering with the php, updated and corrected some of the code to create a working plugin that removes <p> tags from around images.
Iām an amateur, so Iām open to corrections and suggestions here or via github.
Use āidentical comparisonsā: if ($processcontent == true) should be if ($processcontent === true) else a value of āxxxā would be considered to be true too.
You turn the page content into a DOMDocument and replace the original content with DomDocument::saveHTML(). This will not save the pageās content, but inserts a new DOMDocument into the page.
The resulting page will therefor become a nested HTML document:
<!DOCTYPE html>
<html lang="en">
<head>
...
</head>
<body>
...
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<?xml encoding="UTF-8">
<html>
<body>
<!--- the parsed page content -->
</body>
</html>
...
</body>
</html>
Instead of using heavy weight DOMDocument, you might consider trying a regex. The following is a rough example:
$class = $config['class'];
// Search for <p> and <a> (may not exist)
$pattern = '/<p>(<a[^>]*>\s*)?';
// Search <img> tag. Skip when value $class exists anywhere in tag. Regex uses negative lookahead
$pattern .= $class ? '(<img(?:[^>](?!' . $class . '))*>)' : '(<img[^>]*>)';
// Search for </a> (it may not exist) and closing </p>
$pattern .= '(\s*<\/a>\s*)?<\/p>/';
$content = preg_replace($pattern, '$1$2$3', $page->content());
The regex is about >25 times faster.
It saves you approx 25 lines of code.
It will currently not work when 2 images are not separated by empty line in Markdown.
An <img> containing value of ā$classā anywhere inside tag will be skipped.
As saidā¦ it is a rough example and Iām no professional either. So I make mistakesā¦
Feedback on submitting a plugin:
I think your willingness to spend time and effort to contribute to the community will be highly appreciated. But, IMHO it also comes with a responsibility. The community trusts plugins to have a certain level of quality and launches production websites using itā¦
So, I applaud you for asking feedback!
For the time being, you might consider asking the Grav team to hold back the submission of your plugin until your code has been tested thoroughly.
Hope you do not consider this feedback as being negative, but instead as one with a positive intentionā¦
Thanks, @anon76427325 for all that very helpful feedback! I was obviously over-enthusiastic, and probably shouldnāt have submitted the plugin. The code is all just patched togetherāI only managed to combine and edit stuff based on what I could learn without any real foundational knowledge of php, or twig for that matter.
Regarding the regex, I found multiple comments on stackoverflow warning against using regex to parse HTML. The code I started with used regex, but I switched based on that advice.
Iāll try to understand and implement your suggestions, and suggest to the grav team not to implement my plugin. Thanks again.
Although itās true that parsing HTML with RegExp generally isnāt a good idea, the pattern weāre looking for is so specific and the markdown output so predictable that itās really quite safe to use it here.
Have a look at the code I posted earlier. Itās simple, fast and it works.