Footnotes Markdown Extra

Support Content & Markdown
1

Grav v. 1.4

Part of system.yaml

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

Plugins (Latest versions)

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

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.

2

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.

3

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

:confused:

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.

:grimacing:

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

4

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).

5

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

6

@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.

7

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

8

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.

9

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

10

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).
:confused:

11

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).