Footnotes not working in Pico 2

[stefanocpp]

Hello and happy 2019 to all!

I used new year's vacations to upgrade my blog from Pico 1 to Pico 2 via pre-bundled package and everything worked fine. The only things I can't make work are footnotes, both in the remote Apache server and in my local one I use for testing. The same .md file that gets parsed correctly under v1, under v2 outputs what looks like raw html

1. <p>custom footnote text &#160;<a href="#fnref1:1" rev="footnote" class="footnote-backref">&#8617;</a></p>

I checked, the new config.yml file tells Pico to use Markdown Extra; if it didn't, footnotes wouldn't appear at all and markers in the text would look like this ^1 rather than this^{^1}. I also copied over the vendor folder once again to make sure nothing was corrupted.

Checking the html from the browser, the <hr /> element is present and shows up correctly. Html for the above referenced note reads:

<li id="fn:1">
&lt;p&gt;custom footnote text &amp;#160;&lt;a href="#fnref1:1" rev="footnote" class="footnote-backref"&gt;&amp;#8617;&lt;/a&gt;&lt;/p&gt;
</li>

Am I missing something, what am I doing wrong?

Thank you very much

[PhrozenByte]

Pico uses Parsedown as Markdown parser (resp. Parsedown Extra, Parsedown's extension for Markdown Extra), so to put a long story short: Regarding Markdown, Pico does, what Parsedown does.

Unfortunately there's a known issue with footnotes in Parsedown Extra since Parsedown 1.7, see https://github.com/erusev/parsedown-extra/issues/118. Development of Parsedown Extra isn't very active, but there's a beta release of Parsedown Extra (v0.8.0-beta.1) that seems to fix the issue. Since it doesn't seem that there's going to be a stable release soon, I've just released a beta release of Pico (v2.0.5-beta.1 (not released yet, see below)) that uses Parsedown Extra 0.8 and Parsedown 1.8 (as said, both currently in beta).

Some extra testing is required before deploying this as a stable bugfix release of Pico 2.0. Please keep in mind that this is a rather outstanding move; stability is very important to Pico, depending on a beta release of a library is bad. However, the fact that this is a long-living issue in Parsedown Extra (and that apparently not much is happening) is bad, too. Thus extra testing is required. Please test v2.0.5-beta.1 (not released yet, see below) whether it fixes your issue and doesn't break your other Markdown files.

@all: There were pretty massive changes in Parsedown 1.8, there might be issues with existing Markdown files in the wild, so: Additional testing is highly appreciated! Not just related to footnotes, but all your Markdown files in general.

---

Note about v2.0.5-beta.1: v2.0.5-beta.1 has not been released yet because Travis CI seems to have a major outage: jobs start with major delays only, making it virtually impossible to deploy a release (the latest build is running for over an hour now...). Will release v2.0.5-beta.1 tomorrow.

[PhrozenByte]

v2.0.5-beta.1 is out now.

@ALL: There were pretty massive changes in Parsedown 1.8, there might be issues with existing Markdown files in the wild, so: Additional testing is highly appreciated! Not just related to footnotes, but all your Markdown files in general.

[stefanocpp]

First of all, thanks for releasing a new beta following my issue!

I tried v2.0.5-beta.1 on my existing md files and this is what turned out:

• footnotes work!

• headings kind of work, but the bug is minor since the closing hashes aren't necessary. Anyway, closing # show up in parsed html, but only if followed by some character - including white spaces. So, for example, these get rendered correctly ## heading 2 and heading 2 # while these ## heading 2 ## and ## heading 2 #s get rendered as heading 2 ## and heading 2 #s now, putting letters after the closing hash is pointless, but I used to put space space return after closing hashes when I began writing with markdown. Nowadays, I don't use closing hashes anymore, but still use space space return even after headings as a habit. This output is obtained even if breaks in the markup are set to be reflected in the parsed output too. Again, this bug is very minor, but it exists nonetheless. Setext-style headers with = and - work just fine even with space space return

• images show up

• inline html works

I tried to read some of the comments on ongoing work on parsedown, but I think I understood 30% of what was being said. So, if I can be of any further help, please let me know since I can't get any further than this for now in understanding what might be some weak points to test.

[roboticforest]

Greetings. I joined GitHub so I could post this.

I noticed two problems with the generated footnotes. The first and most obvious is that they aren't rendering correctly. The second is that the anchor links aren't working properly.

After reading through everything in this thread I upgraded Parsedown to the 0.8 beta and that fixed all of the footnote rendering issues for me just as it did for you guys, but the anchors still don't work. Taking a look at the generated HTML directly everything looks fine with the <a> tags being formatted correctly, but when I hover my mouse over the link I noticed the web addresses were too short. I'm wondering if this could be caused by how Pico generates pages? I don't know.

For example: I have Pico currently installed under html/cms-staging/ while I build my site, and am working on a file that generates the address mywebsite.com/html/cms-staging/dev-journals/app-journal/page-name in my browser address bar when being viewed.

Footnotes generate HTML id attributes like #fn:1 and when you hover your mouse over the link you'd expect it to be mywebsite.com/html/cms-staging/dev-journals/app-journal/page-name#fn:1, but instead you just get the base url, plus a slash, plus the anchor id, resulting in mywebsite.com/html/cms-staging/#fn:1 which isn't a valid address (Well, actually it's the home page, but there's no #fn:1 anchor there, nor is that the expected destination URL for a same-page anchor.) The footnote return links that are also doing the same.

Your thoughts?

[PhrozenByte]

Sounds like your theme creates a <base href="" /> element in your website's <head>. Remove this element and make sure to use absolute URIs instead.

[roboticforest]

That fixed it! Thank you!