Spent the weekend producing HTLM from Lisp– feels like the 90s.

I was able to get the h-card into the home page & the footers of blog posts & general pages simply customizing variables.

Getting the h-entry into blog posts was more challenging & led me down into the depths of Org exporting.

Unless the backend (`html', in our case) offers a specific hook for the text you want to insert, you're going to need to replace the `template' attribute of the backend– that's the piece that lays out the form the exported document will take. In our case, that's `org-html-template'. Fortunately, this is pretty easy to do:

OK, so now we've got a back-end that includes h-cards, how do we get our project to use it? You can't directly say "use this backend", instead you customize `org-publish-project-alist':

One special property controls which back-end function to use for publishing files in the project. This can be used to extend the set of file types publishable by ‘org-publish’, as well as the set of output formats.

‘:publishing-function’

Function to publish file. Each back-end may define its own (i.e. ‘org-latex-publish-to-pdf’, ‘org-html-publish-to-html’). May be a list of functions, in which case each function in the list is invoked in turn.

OK, I started with `org-html-publish-to-html' (the default), which I still want to use for the site map ('index.org'):

I did a little reading of code:

1. `org-publish-org-to' handles the work of loading the file into a

buffer (if it's not open already) and then calls `org-export-to-file'

1. `org-export-to-file' handles writing the output file, delegating

to `org-export-as' to do the actual conversion from org-mode to the desired output format:

1. `org-export-as' is the workhouse; it's complex and I don't

understand everything it's doing, but it offers a few hooks, gathers a lot of information about the org-mode file, allows you to filter the parsed org-mode, and finally invokes the template.

• structure of the HTML template, e.g.

• the "comms channel"

  ;; org-publish-org-to
  ;;   creates *new* plist
  ;;   calls org-export-to-file
  ;;     again creates a new list
  ;;     calls org-export-as
  ;;       *here* is where `info' is created
  ;;       calls `org-export-before-processing-hook'
  ;;       calls `org-export-before-parsing-hook'
  ;;       updates `info'
  ;;       installs users's & developer's filters into `info'
  ;;       parse the buffer
  ;;       transcode the parse TREE-- I GUESS this is where my filters get invoked (defo where template is invoked)
  ;;     writes the file
  ;;     optionally post-processes file
  

• "In general, Bridgy prefers to use p-summary if available, then the full e-content, and finally p-name, in that order. The one exception is original tweets (not @-replies) on Twitter and Mastodon: for those, it prefers p-name before e-content"

Supporting various Indieweb features such as Webmentions requires maintaining state regarding site publication. IOW, every time one publishes the site (whether to prod, staging, or somewhere else) one now needs to scribble-down certain information for subsequent use.

• pretty much have to move to a publish + update approach
  • I don't think brid.gy will posse unless the post is "live"
  • So it looks like posse-post-discovery - IndieWeb was specifically added for Brid.gy– brid.gy will have the URL of the syndicated post and needs to map it back to the original
  • OTOH, I suspect brid.gy will queue-up backfeed for me while I get that out(?)
    • Yes:
      • Q: Bridgy isn't seeing one of my comments or likes or reshares!
      • A: Are you using a syndication link? If so, Bridgy may have fetched your post before you added the link. When that happens, Bridgy waits up to two hours before it refetches your post and reloads syndication links. Try clicking the Crawl now button on your user page.