<audio controls="1" controlslist="nodownload nofullscreen noremoteplayback" alt="The Sound File"><source src="/user/pages/m4as/the-sound-file.m4a">Your browser does not support the audio tag.</audio>
but when I look at the rendereed HTML in Chrome Dev Tools, I get:
<audio controls="1" controlslist="nodownload nofullscreen noremoteplayback" alt="The Sound File"> "<source src="/user/pages/m4as/the-sound-file.m4a">" Your browser does not support the audio tag.</audio>
Note, the extra quotes outside of the source tag… it’s like whatever is converting the < and > to markup is also adding quotes.
I was thinking the same thing… that somehow escaping the < and > would help, but I haven’t found a way to do that using markdown so far.
But, since these quotes are being added outside of the source tag, I don’t know if that’s anything I can change (with markdown anyways) so I’m looking at the AudioMedium.php (\Grav\Common\Page\Medium\AudioMedium) and I’m wondering if there’s anything there I can change…
Actually, Grav does escape characters through markdown: escape_markup in system.yaml. By default, this includes > and <. I had a case of this a while back (see issue), but it relates to ParseDownTrait rather than AudioMedium.php. To my recollection, I have not hit upon the same problem in version >=1.3.*.
@tlflow Could you share your system.yaml configuration? And is the Markdown rendered in the template by just calling {{ page.content() }}, or filtered in some way? Your initial Markdown is entirely valid as far as I can tell, the issue is rather - as you note - in how it is rendered.
@pwhodges Could you try copying the Markdown-page or Twig-template which references the audio to a clean installation of Grav, and see how it renders there?
I installed a clean copy of Grav+Admin with no added themes.
First I copied the page concerned, and it looked alright… but then I remembered I’d replaced the markup with straight html.
I then (in the new install) added the markup using the admin editor, by clicking the (+) next to the audio file. This generated a link object instead of a media object. When I added a ! at the start, it then rendered correctly.
I returned to my original updated installation and clicked (+) to remake the media object. Again, the ! was missing, but when I added it the page rendered incorrectly.
Finally, I went back to the new installation, copied the page from the old one, and saw that it rendered correctly.
OK - so that seems to show that (a) there is an error in adding a media item using the editor in the new update, and (b) there is an error in the updating procedure in the dashboard which causes an updated system to render differently from a clean system.
Additional information: I am using the Editorial theme (v1.2, deliberately not the current), but changing back to antimatter did not affect the outcome. If there are any other things you want to know, just ask (I’m in the UK, so I won’t be up long right now).
I notice there’s a slight difference in the error between my case and tlflow’s. In both cases there is an extra ‘"’ before ‘<source’, but in his case the matching second ‘"’ comes immediately after the matching ‘>’ whereas in my case it comes after the full stop of ‘tag.’ at the end of the following sentence.
@pwhodges Thank you for the thorough run-through, you should create an issue on the admin repo if non exists yet, as this relates to the Admin-plugin’s handling of the Markdown.
Glad to hear that this is fixed in 1.4.2, also for @tlflow, though it’s important that correctly adding the media via the editor is fixed so this basic task works well.