{"id":92,"date":"2023-11-27T17:11:00","date_gmt":"2023-11-27T22:11:00","guid":{"rendered":"https:\/\/radio.teledyn.com\/blog\/?p=92"},"modified":"2023-12-06T01:05:24","modified_gmt":"2023-12-06T06:05:24","slug":"hello-buffer","status":"publish","type":"post","link":"https:\/\/radio.teledyn.com\/blog\/2023\/11\/27\/hello-buffer\/","title":{"rendered":"Hello, Buffer"},"content":{"rendered":"
\n

\nwe do these things not because they are easy, but because we thought<\/em> they would be easy.\n<\/p>\n<\/blockquote>\n

\nIt seemed like a very simple idea. Org-mode already provided HTML rendering that worked quite well for static pages, and while the kits for WordPress posting use the dreaded xmlrpc api, with my server on the same LAN as the author, both behind a firewall, it seemed reasonably<\/em> safe to give it a go. This would let me bring anything within reach of Emacs into my published works, and with all the lovely options of Org-Mode, while also<\/em> enabling the wonderfulness of Fediverse presence, structured data and other perks of WordPress plugins.\n<\/p>\n

\nThat led me to Org2Blog<\/code> as a candidate, promising your first post in 5 minutes, and while it took 15, the result was impressive.\n<\/p>\n

\n

\"Green\n<\/p>\n

Figure 1: <\/span>do not stare into the void<\/p>\n<\/div>\n

\n

So I tried a more complex example\u2026<\/em><\/h2>\n
\n

\n
\nEverything was beautiful. Not as beautiful as I would have liked1<\/a><\/sup> but acceptable<\/em> in every respect except one: Footnotes were garbage. That tiny<\/em> issue has resulted in a week of no progress, a lot of swearing, bad docs, blind alleys, obsolete advice, and still no closer.\n<\/p>\n

\nI’ve dropped that post, starting again because I neglected to save the buffer and there is no re-fetch and edit<\/em> option. I now<\/em> know the publishing does not upload CSS, only the article body is uploaded, and the footnote mangle, which did not happen outside<\/em> of Org2blog-WP, remains inexplicable, and persistent<\/em>.\n<\/p>\n

\nThe Chrome browser View Source<\/em> HTML makes no sense:\n<\/p>\n

\n
<div<\/span> id<\/span>=\"footnotes\"<\/span>>\n  <h2<\/span> class<\/span>=\"footnotes\"<\/span>>Footnotes: <\/span><\/h2<\/span>>\n  <div<\/span> id<\/span>=\"text-footnotes\"<\/span>>\n    <div<\/span> class<\/span>=\"footdef\"<\/span>>\n      <sup<\/span>>\n        <a<\/span> id<\/span>=\"fn.1\"<\/span> class<\/span>=\"footnum\"<\/span> href<\/span>=\"#fnr.1\"<\/span> role<\/span>=\"doc-backlink\"<\/span>>1<\/a<\/span>>\n      <\/sup<\/span>>  <\/p<\/span>> <!-- <\/span>THE PHANTOM P :gm<\/span> --><\/span>\n      <div<\/span> class<\/span>=\"footpara\"<\/span> role<\/span>=\"doc-footnote\"<\/span>>\n        <p<\/span> class<\/span>=\"footpara\"<\/span>> this would be the footnote text. <\/p<\/span>>\n      <\/div<\/span>>\n    <\/div<\/span>>\n  <\/div<\/span>>\n<\/div<\/span>>\n<\/pre>\n<\/div>\n
\nIf I Inspect<\/em> the footnote, I find a <p><\/p><\/code> inserted on a line by itself after the <sub><\/code> tag.\n<\/p>\n
\nTwo things: one is that stray closing P tag in Chrome View Source, the other is the footnote text in a P container that does not include the fn.1<\/code> anchor. It is my guess<\/em> that stray tag is auto-completed by Chrome resulting in the Very Large Gap.\n<\/p>\n
\nThe stray tag does not appear in the WordPress editor receiving the generated post:\n<\/p>\n
\n
<div<\/span> id<\/span>=\"footnotes\"<\/span>>\n  <h2<\/span> class<\/span>=\"footnotes\"<\/span>>Footnotes:<\/span><\/h2<\/span>>\n  <div<\/span> id<\/span>=\"text-footnotes\"<\/span>>\n    <div<\/span> class<\/span>=\"footdef\"<\/span>>\n      <sup<\/span>>\n        <a<\/span> id<\/span>=\"fn.1\"<\/span> class<\/span>=\"footnum\"<\/span> role<\/span>=\"doc-backlink\"<\/span> href<\/span>=\"#fnr.1\"<\/span>>1<\/a<\/span>>\n      <\/sup<\/span>>\n      <div<\/span> class<\/span>=\"footpara\"<\/span> role<\/span>=\"doc-footnote\"<\/span>>\n        <p<\/span> class<\/span>=\"footpara\"<\/span>>the usual footnote sort of stuff.<\/p<\/span>>\n      <\/div<\/span>>\n    <\/div<\/span>>\n  <\/div<\/span>>\n<\/div<\/span>>\n<\/pre>\n<\/div>\n
\nAnd yet, if I switch the editor to View mode, the phantom gap paragraph is rendered!\n<\/p>\n
\nChrome may be attempting to fix<\/em> mis-matched tags, which doesn’t explain why the phantom is inserted where it is, only trying to excuse its presence. But why would it only appear when rendered by WordPress? A plugin conflict?<\/em>\n<\/p>\n
\n
\nThere is a general rule, probably buried in the W3 specs<\/a>, where the P<\/code> tag cannot contain a DIV<\/code>, and using curl to extract the source direct into my editor, well, it’s curious<\/em> because there are no violations of this particular<\/em> rule, but there is that phantom <\/p><\/code> appended after the <\/sup><\/code> which is not in the HTML displayed by WordPress. And there is another as well, tucked in after the <\/label><\/code> tag on an org-src-container<\/code> just before the <pre><\/code> begins. Emacs gives up code-formatting at this point and complains of an unbalanced DIV<\/code>.\n<\/p>\n<\/div>\n
\nIt seems WP adding<\/em> extraneous P tags is common, and while it says nothing about extra closing<\/em> P tags, this offers a theme patch<\/a> to drop all auto-P injections, and, great googley moogleys<\/em> it works!\n<\/p>\n
\n
\/\/ <\/span>Prevent WP from adding <p> tags on all post types<\/span>\nfunction<\/span> disable_wp_auto_p<\/span>( $content<\/span> ) {\n  remove_filter( 'the_content'<\/span>, 'wpautop'<\/span> );\n  remove_filter( 'the_excerpt'<\/span>, 'wpautop'<\/span> );\n  return<\/span> $content<\/span>;\n}\nadd_filter( 'the_content'<\/span>, 'disable_wp_auto_p'<\/span>, 0 );\n<\/pre>\n<\/div>\n
\nWhich makes my Footnotes quite happy, which makes me happy too. I can move on, I just need to recall what it was I was doing 10 days ago when I hit this.\n<\/p>\n<\/div>\n
\n
Ok, but what about \\(\\LaTeX\\)? <\/h3>\n
\n
\nIt requires the MathJax plugin. If wp-latex<\/code> was built in, it wasn’t active.\n<\/p>\n