Okay, Micro.blog plugin consumers … y'all think my plugins should default to having fingerprint on or off? The only reason to default to having it off would be convern over cache-busting (I would assume only full rebuilds or plugin modifications cause the link to change). @sod
BTW … if UR reading these READMEs … and U C the table of contents button … that's my table of contents plugin. If U don't C the button, give the swipe activation a whirl by swiping from the left edge (just not so far left that your browser wants to go back to the previous page).
A plugin for Micro.blog that creates a page displaying links to your categories layed out as a category cloud. Its code lives here.
.@manton I created a plugin that aids folks in persisting data for my plugins, but it doesn't want to register. Thoughts? plugin-configuration-files
All the Micro.blog plugins I currently use are now registered and available. Only Cards and Bookshelves have updated READMEs. I also forgot to note that Conversation logs errors. As far as I can tell, these are entirely harmless. If I ever get to see the logged errors, I could probably avoid them being logged.
plugin-cards is a Micro.blog plugin for generating link preview cards on various platforms (including your blog) as well as generating structured data for search engine consumption. Its code lives here.
The rough draft up on the test blog of the walkthrough (that has turned into the updated README) for plugin-cards. Probably dot the 'I's and cross the 'T's tomorrow.
.@manton If you think folks might be more comfortable with YAML than TOML (when editing my data templates), you might could adjust the repository cloning logic to allow YAML files when under the data directory. The only thing I find tricky about TOML is arrays of maps. No idea what regular folks would think.
Side note: if Hugo supported comments within JSON files, I likely never would have learned TOML … but I think I like the top-level feel of it.
Sooo … since I figured out how to create my own Chroma style to use with Hugo 0.91's automagical syntax highlighting for fenced (and labeled) code, I've totally dropped plugin-prism. Other than my moondeer theme, the only other survivor is the shortcode for tricking Hugo into rendering its own code as example code rather than attempting to invoke it.
I figured I may as well generalize what was a shortcode for embedding shortcodes so that it would embed whatever TF I happened to want it to. So I did, calling this new rendition preserve.
The example output below tricks Hugo into not tagging the +++ lines that fence the front matter for a Markdown Hugo content file with the .err class and into actual printing the shortcode in the content block below the front matter.
+++
title = "Bookshelf"
description = "Book collections"
type = "bookshelf"
+++
{{< plugin-bookshelves >}}
To get this example to render in this little post looks something like:
{{< preserve "+++" >}}
title = "Bookshelf"
description = "Book collections"
type = "bookshelf"
{{< preserve "+++" >}}
{{< preserve "{{< plugin-bookshelves >}}" >}}
So what complex logic must one stick into the code for layouts/shortcodes/preserve.html to get this all to work? All you need is this :
{{ .Get 0 }}
Side note: more trickery may actually be necessary for this shortcode to work outside of a code fence. Totally didn't work when I tried to render that list bit as inline code.
A plugin for Micro.blog that creates a page displaying multiple bookshelves. Its code lives here.
If you're reading this on the Micro.blog timeline…
are y'all fairly comfortable with the idea of having your own custom theme for housing configuration files for my plugins or would it be less intimidating if a created another plugin whose sole purpose was to hold configuration files for y'all to edit?
The whole point here is persisting your configuration files. Whenever the directory holding the file (be it plugin or theme) updates, you'll need to have preserved your configuation before hand somewhere that you could copy and paste it back into the fresh directory.
My guess is that the contents of your custom theme are additive to whichever official theme you have selected, so, say, when @pimoore updates one of his themes and you have it selected as the base of your custom theme … you would get the benefit of the update without your files being touched.
A standalone plugin for configuration files would be less stable than that, updating whenever I feel it necessary to modify the contents of the configuration template files. It would, however, be more stable than editing the data templates inside their respective plugins, as these directories are likely to be updated whenever I need to adjust any of the files within the plugin.
P.S. Documentation chock full of hand holding forthcoming for all things configuration files (aka data template files … aka anything-in-my-plugin-under-the-data-directory).
Bet I just located the issue. I had an HTML comment between blocks in layouts/post/single.html leftover from when I was double checking the microformat. Those little f$&kers are notorious for silently causing all kinds of issues.
.@manton here's some strange I'll try to get to the bottom of tomorrow.
With the previous theme reinstalled, everything builds … and the harmless errors are spawned by my conversations plugin.
With the latest theme version installed, the errors are no longer logged…
and it looks like everything builds (tags from homepage head)…
but … if you check the head tags for a post page…
the previous theme version's pages are there. It will be interesting to see if this new post will be permalinked … because it seems like what most likely happened was that everything looked right until I triggered the full rebuild for the first time with v180 installed.
The state of the plugins before I go about updating READMEs (thereby discovering whether everything is actually working):
.@manton Still curious about these push failures. Do these indicate a single failed push to some device or a full on failure? Did you and @maique receive the mentions from the the posts that failed to push?
.@manton If I end up selling you on the data templates for parameters … we could add an entry to plugin.json for registering the config files for display in the installed plugins list … perhaps even having them open in their own editor from there to make it less frightening.
.@manton after sifting through posts and ripping out my unnecessary shortcode invocations, I can't seem to clear these out of the log. Some builds are clean, others are not. Could this be a per server cache issue where the servers I hit with full rebuild clear the cache?
.@manton How did the Micro.blog @ulyssesapp integration come about? The sooner they learn that they oughta export the exact same labeled code fence when publishing as they do when exporting Markdown the better (seeing as that's all you need to trigger syntax highlighting).
Updated READMEs just around the corner.
The lightbox plugin now allows for per gallery invocation grid width and row height configuration thanks to the CSS grid module (y'all webdevs have it soooo f$&kin' easy these days).
The home-rolled audio preview cards de-borked:
.@manton @pratik your custom theme is your custom theme. It exists entirely separately from the plugin. The way that Hugo merges directories means that my plugin can look for a particular data file that exists entirely outside of the plugin. This is why I use a different path (dash-cased) to avoid collisions.
I take the data file templates / default parameter value files held by the plugin … copy/paste into a single file … add adjust for file level (add [Config], [Style], and convert to [Bookshelves.Registered]) … and then save that in my single custom them (Moondeer).
You can see all my plugin configurations living in my custom theme:
Y'all are making it more complicated than it actually is.
Suppose I should de-bork my home-rolled audio preview cards.
Rabbit hole Exhibit A:
Category posts are assigned images for preview cards ∴ posts without any images oughta default to a their category's image rather than a site default image.
Posts can belong to more than one category ∴ it would be cool-as-f$&k if all a post's categories were represented in the preview card image.
Ooh … ooh … I bet I could stick the category images under the assets directory and, using the Hugo pipe image manipulation API, generate these hybrid preview card images on the f$&kin' fly…
Thinking of adding support for book comments to plugin-bookshelves when in list view so I can create a shelf for the books that shaped me coming up and in college … and that I still mention from time to time (like yesterday).
.@manton Blog selection here consistent with the rest of the interface, while not a big deal, would save the following trip when you want to rebuild a blog that isn't the blog in focus: Design → Select Blog → Account → View Logs → Rebuild Selected Blog
