Footnotes Markdown Extra

Grav v. 1.4

<details>
<summary>Part of system.yaml</summary>

process:
markdown: true
twig: true
twig_first: true
never_cache_twig: false
events:
page: true
twig: true
markdown:
extra: true
auto_line_breaks: false
auto_url_links: false
escape_markup: false
special_chars:
'>': gt
'<': lt
twig:
cache: true
debug: true
auto_reload: true
autoescape: false
undefined_functions: true
undefined_filters: true
umask_fix: false

</details>

<details>
<summary>Plugins (Latest versions)</summary>

admin
admin-addon-media-rename
admin-addon-media-sort
admin-addon-user-manager
advanced-pagecache
anchors
auto-date
bigfoot-js
data-manager
editor-buttons
email
embed
error
external_links
feed
form
ganalytics
login
markdown-color
markdown-fontawesome
markdown-notices
pagination
problems
quick-tray-links
relatedpages
resize-images
shortcode-core
shortcode-owl-carousel
shortcode-ui
tagcloud
taxonomylist
tntsearch
twigfeeds
users-page-ownership

</details>

I have footnotes which are not converting their contents into properly formatted html. All of their contents appear to be rendering raw. (I am seeing <p> tags and URLs don't convert to hyperlinks but remain as text.) Any thoughts on what configs might be leading to this? I have attempted various changes with no effect.

If you need more information, let me know.

As an aside, the Bigfoot JS will work on the initial load of a page, but reloading the page disables Bigfoot JS. If you have any ideas for this one, they would also be appreciated.

The first one happens because there is an issue with the updated parsedown-extra that Grav uses. It is not a problem with Grav itself, just an upstream one, so we are waiting for a fix. You can follow the issue on GitHub.

As a temporary workaround, you can revert to the previous version of parsedown and parsedown-extra (but I would like someone more knowledgeable than me to confirm that it is safe to do so).

As for the Bigfoot JS, I believe you have to add

process:
    twig: true

in the frontmatter of the page that you want it to show up or enable the same setting globally in /user/config/system.yaml.

@Soulrain:
As a temporary workaround, you can revert to the previous version of parsedown and parsedown-extra (...)

Indeed, it seems to be a solution, but a revert to previous versions appears difficult to configure correctly.

😕

When I have tried to retrograde (using composer) the version numbers for these dependencies update function was impossible (due to composer.lock) and install function was blocked (by the requirement to have a token for accessing to one of the dependancy, which is hosted in a private repository, if I understood correctly). As I was oddly unable to correctly paste this token in my console, I finally failed to revert these dependancies to older versions.

😬

@Soulrain:
(...) so we are waiting for a fix (...)

So, at this time, it seems to be the less time wasting solution...

After a little cogitation, I decided to directly ask if reverting to previous versions could be potentially considered (only as a temporary solution, of course).

If it's just twig, have you tried adding a filter to it? ed, add it like:

{{ bla.something | raw }}

where '| raw' is the filter

@gizmecano

It may not be the right way to do this but I just copied Parsedown.php and ParsedownExtra.php from a backup and have yet to see something break.

I think it's just the regular syntax for footnotes in markdown extra that displays escaped HTML and there is no twig involved.

Based on @rhuk's thinking with Github, it seems that a different solution will have to be determined for the long term when it comes to footnotes.

I must say that, unfortunately, I understand the same thing as you.

I am considering the same possibility, or more drastically, to entirely revert to a previous version of Grav (where this problem had not yet appeared).
😕

I have finally succeed to revert to a situation where footnotes are no longer broken, by downgrading to version 1.6.4 of parsedown, as suggested by @rhuk (see here for details).