Hello!
One of our copy editors flagged the use of straight quotes appearing in the footnotes of a text we are producing in Pressbooks. It looks like it was a deliberate choice to exclude footnote text from the Wordpress function that adds smart/curly quotes. Editorial staff at the press didn’t know of any editorial reason to use straight quotes and said that all major style guides call for curly quotes, so I wanted to ask if there was some other technical reason to exclude footnotes from wptexturize() or if there was an editorial reason we had not considered.
Thanks!
Alex Dryden
Hi Alex,
I’m not sure why this was done or what the reason would have been. Git blame tells me that this was introduced in 2018, before my time at Pressbooks. I’ll try to ask one of the developers involved in the commit to see if they recall the motivation.
I do not recall this being a deliberate decision to have straight quotes. Can’t think of a reason for excluding footnotes.
Hi @alexdryden This code looks like it was there at the time of the initial commit to GitHub(!). I just talked with a previous lead developer. He doesn’t remember why this would have been done but guesses it might have been because footnotes sometimes contain things like links that have markup along the lines of <a href="foo"></a>. This would be part of the ‘content’ of the footnote. If WordPress were to convert this straight quotes to smart/curly quotes, the HTML attributes would break and no longer be valid HTML. That’s our best guess as to why this was done. We can try perhaps to remove that filter and see what happens to our automated test suite, or do experimental testing to see what happens to footnotes that contain HTML with straight quote attributes?
Hi @SteelWagstaff, removing that filter and running the automated tests would be great. I have removed it in a sandbox environment and done some ad hoc testing where formatting and hyperlinks appear as expected.
@steel that rings big loud bells.
1 Like
@alexdryden any issues (if they exist) likely won’t be in the webbook but would be in the PDF exports (which get made from the XHTML export via PrinceXML/DocRaptor). PrinceXML has a slightly complicated process by which the footnotes are generated and moved to the correct position in the page. Have you looked at your PDF exports to see if those work as expected? That’s where we’d need to check for strange/breaking stuff. As with many things we’ve seen over the years, the webbooks are the ‘easy’ part – the devil in the details is trying to produce consistency and good results across the various export formats. Life is easier now that we’re not also trying to understand and comply with MOBI and InDesign exports, but EPUB and PDF generation and ensuring feature parity and consistency across each occupies much more time and attention that you’d think 
Hi @SteelWagstaff - Great point. We use a slightly different routine for PDF generation from PB, but I just did some testing with the Prince generated PDF exports using the default parameters and everything looks as expected. Placement was not affected and, in the digital PDF, links still work.
For EPUB, footnote still looked the same and links still worked when viewing in the default mac Books app.
You may want to do more testing before pushing the change, but, after doing a bit more digging into wptexturize(), I’m satisfied. It looks like there were some issues with wptexturize() interfering with some html blocks within shortcode blocks many years ago, and it seems that Hugh’s recollection supports that as being related to why it was excluded. Thanks for your help and thanks @hughmcguire as well!
Best,
Alex