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
Href attribute not being rendered correctly #266
Comments
I think you mean that |
I don't seem to be able to reproduce it. Do you reproduce it in the demo? |
In the demo it looks ok. @jackmcdade should know more details about how he processes the input before feeding it to the parser. |
Ah i see what it is. We're parsing Markdown before our template language does variable replacement, so it's selectively encoding/stripping/altering the |
Do you think that this is related to an issue with Parsedown? |
Yeah definitely. We just upgraded Parsedown and the issue popped up. Rolling back fixes it. As does using other Markdown parsers. |
Could you help me reproduce it? |
Sure thing, just drop this in the demo:
|
I did that. Parsedown seems to produce identical output as Markdown PHP. Am I missing something? |
I'm not quite sure what to say except that in Statamic that parser doesn't break anything, and Parsedown does. I can set up a sandbox for you if that might help? |
That might help, but before that, could you figure out which is the exact version that introduces the issue? |
I’ll see what I can do. - Jack On January 15, 2015 at 5:30:27 PM, Emanuil Rusev (notifications@github.com) wrote: That might help, but before that, could you figure out which is the exact version that introduces the issue? — |
Did you get a chance to look into it? |
I'm not sure if this is the same issue, but I have recently noticed that there is a problem when you use curly brackets in a markdown link, it doesn't work. Some examples:
Renders out of Parsedown as:
As expected. However, if you have any spaces between the parens, like:
the indentifyLink() fails on the regex: https://github.com/erusev/parsedown/blob/master/Parsedown.php#L1202 and you basically get your markdown spat back at you unprocessed. The problem with that appears to be the space before the opening parens in the first negated set. If you remove that so the resulting regex is:
This now works. However, this is a pretty complex regex and i'm not sure the implications of removing this space for other tags. Perhaps @erusev has some insights as this was changed pretty heavily between 1.14 and current. BTW, I have no issue with curly brackets in HTML links themselves, Parsedown just ignores them and it works fine. eg:
Doesn't get any modified at all, works fine. |
This is expected. The regex expects a valid URL.
Same here. I'm unable to reproduce the issue. It'd be great if @jackmcdade could help us with that. |
FWIW, I got around this in Grav by using on overriden
|
Is this about Parsedown or Parsedown Extra? |
I'm unable to reproduce it, but I can tell you Statamic is using Parsedown Extra. |
Okay, I can reproduce it. Even in the demo. Parsedown Extra only.
But, without the
However, I think it's correct that you are encoding those characters. Is there an option to disable it? |
Same here. Twig tag brackets are encoded if they appear in a
This doesn't:
and results in
|
I did some further investigation on this. The issue is caused by PHP's A similar issue is reported here: One solution would be to loop through all src and href attributes and urldecode them to reverse the encoding. Another could be to rename the attribute to _src and _href, do the DOM processing and rename them back to src and href. |
Since it didn't appear to be possible to reproduce this issue, I'm going to close this one – please reopen if you can reproduce this with the latest version though. |
I've just come across this same issue while working in grav. Came here hoping for a solution. code:
result:
href and src tags broke. Disabling Parsedown Extra fixes it. |
Yah this is an upstream problem with Markdown Extra library, not much we can do. We're probably going to remove Markdown Extra in Grav 2.0 unless they do some significant improvements to it. |
So as @hwmaier has pointed out, the main issue here appears to be caused by ParsedownExtra's use of PHP's We use CommonMark's method of achieving markdown content within HTML is both simpler to use (IMO) and also to implement (see also /cc: @PhrozenByte). Given more modular "agility" in the next Parsedown release, I'd expect that the additional features that ParsedownExtra contains could be readily imported (or enabled) within Parsedown. There are also significant improvements that have already been made to Parsedown's HTML handling, which (as far as I'm aware) should bring it up to being CommonMark compliant in this regard (see changes). These aren't yet released, but will definitely make it into the next version. With all that considered, I'd envision it being possible (at the most drastic) to move ParsedownExtra's additions into the Parsedown repo as a set of modular features (that'll be by default off). If this happened I'd expect to just dump the As a TL;DR: this is unlikely to occur in 2.0 since we'll have the opportunity to drop a dependency within ParsedownExtra, if we don't drop the dependency it might still occur but only if the |
To fix the problen you can process twig fist: https://learn.getgrav.org/15/content/headers#process-twig-first |
When parsing HTML inside my Markdown string, I've been coming across some issues. Most noticeably any
href
attributes of those HTML bits.Is rendered as
The text was updated successfully, but these errors were encountered: