New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
shortcode output wrapped in p-tags #1148
Comments
I remember adding divs around the shorcode placeholders to prevent this, but this was modified by @halostatue to fix an issue with the relref shortcodes. I guess we can remove the superflous p tags when doing the replacement. |
👍 |
Yea, well, a expansion of the regexp in the last replace func is a 15% slow-down on my not very shortcode-heavy site. For the shortcodereplacement alone:
Back to the thinking box. |
I'm trying to understand the source (not a go dev sorry), and it looks like you're processing the shortcodes and replacing them with shortcode placeholders. Perhaps if you replaced it with a html based placeholder markdown wouldn't wrap it with paragraphs tags. For example:
Anyway, fixing this would be really handy, although it isn't a "end of the world" issue I suppose. I'm working around this by putting div tags around the shortcode on the content itself. |
@darylteo you are correct, that was my initial approach. But @halostatue changed that as it had some other side effects. |
This commit replaces the regexp driven `replaceShortcodeTokens` with a handwritten one. It wasnt't possible to handle the p-tags case without breaking performance. This fix actually improves in that area: ``` benchmark old ns/op new ns/op delta BenchmarkParsePage 142738 142667 -0.05% BenchmarkReplaceShortcodeTokens 665590 575645 -13.51% BenchmarkShortcodeLexer 176038 181074 +2.86% benchmark old allocs new allocs delta BenchmarkParsePage 87 87 +0.00% BenchmarkReplaceShortcodeTokens 9631 9424 -2.15% BenchmarkShortcodeLexer 274 274 +0.00% benchmark old bytes new bytes delta BenchmarkParsePage 141830 141830 +0.00% BenchmarkReplaceShortcodeTokens 52275 35219 -32.63% BenchmarkShortcodeLexer 30177 30178 +0.00% ``` Fixes gohugoio#1148
Even as a copy at the end is needed, this consumes way less memory on Go 1.4.2: ```benchmark old ns/op new ns/op delta BenchmarkParsePage 145979 139964 -4.12% BenchmarkReplaceShortcodeTokens 633574 631946 -0.26% BenchmarkShortcodeLexer 195842 187938 -4.04% benchmark old allocs new allocs delta BenchmarkParsePage 87 87 +0.00% BenchmarkReplaceShortcodeTokens 9424 9415 -0.10% BenchmarkShortcodeLexer 274 274 +0.00% benchmark old bytes new bytes delta BenchmarkParsePage 141830 141830 +0.00% BenchmarkReplaceShortcodeTokens 35219 25385 -27.92% BenchmarkShortcodeLexer 30178 30177 -0.00% ``` See #1148
@darylteo I have tested this one pretty good myself, but it would be cool if you also could take the latest source for a spin and confirm that it it's fixed for you. |
Is it related in any way with |
@nicolinuxfr it is if you use the figure shortcode and similar. |
@bep nope, I'm using plain Markdown to insert images and I have |
@nicolinuxfr yes, but that would be for Blackfriday: https://github.com/russross/blackfriday/issues |
@nicolinuxfr Images would be inline so they should have p's around them, I @bep I will try. I'm installing Hugo via Brew so I'll need to figure out On Tue, Jun 23, 2015 at 5:35 AM, Bjørn Erik Pedersen <
|
@darylteo if you just need the latest commits from the master branch, |
Well, this isn't totally fixed. If I use the follow shortcode
that way:
it render like this:
|
@bclermont to mee that looks like another issue, but I may be wrong. Looks like a Blackfriday issue, but if that is your complete shortcode, your work around would be to replace But could you create another issue for your case? |
@bep I think you're right, I will investigate a little more. is that normal that when I switch |
@bclermont yes, the < syntax was added in 0.14 to handle use cases with raw HTML that didn't need Markdown rendering (or, the Markdown rendering messed it up badly ...) |
I created a separated issue #1387 for that with a project to reproduce the problem |
ALSO - fix snippets. It seems hugo has a bug: gohugoio/hugo#1148 gohugoio/hugo#1387 which is causing YAMLs not to render properly when there's a blank line. removed blank lines.
The original bug appears to still be active in certain situations as described here: https://discuss.gohugo.io/t/shortcodes-and-p-tags/2164/5 Should this issue be reopened or a separate one created? |
Separate. |
This commit replaces the regexp driven `replaceShortcodeTokens` with a handwritten one. It wasnt't possible to handle the p-tags case without breaking performance. This fix actually improves in that area: ``` benchmark old ns/op new ns/op delta BenchmarkParsePage 142738 142667 -0.05% BenchmarkReplaceShortcodeTokens 665590 575645 -13.51% BenchmarkShortcodeLexer 176038 181074 +2.86% benchmark old allocs new allocs delta BenchmarkParsePage 87 87 +0.00% BenchmarkReplaceShortcodeTokens 9631 9424 -2.15% BenchmarkShortcodeLexer 274 274 +0.00% benchmark old bytes new bytes delta BenchmarkParsePage 141830 141830 +0.00% BenchmarkReplaceShortcodeTokens 52275 35219 -32.63% BenchmarkShortcodeLexer 30177 30178 +0.00% ``` Fixes gohugoio#1148
Even as a copy at the end is needed, this consumes way less memory on Go 1.4.2: ```benchmark old ns/op new ns/op delta BenchmarkParsePage 145979 139964 -4.12% BenchmarkReplaceShortcodeTokens 633574 631946 -0.26% BenchmarkShortcodeLexer 195842 187938 -4.04% benchmark old allocs new allocs delta BenchmarkParsePage 87 87 +0.00% BenchmarkReplaceShortcodeTokens 9424 9415 -0.10% BenchmarkShortcodeLexer 274 274 +0.00% benchmark old bytes new bytes delta BenchmarkParsePage 141830 141830 +0.00% BenchmarkReplaceShortcodeTokens 35219 25385 -27.92% BenchmarkShortcodeLexer 30178 30177 -0.00% ``` See gohugoio#1148
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
See
http://discuss.gohugo.io/t/info-img-shortcode-figure-tag-auto-wrapped-in-p-tag-invalid-html/1202/5
The text was updated successfully, but these errors were encountered: