A plugin for Micro.blog for generating a slide-over table of contents. Its code lives here.
.@pimoore To answer your question (now that I've settled down), you were correct. Click the New Plugin button, name it whatever you like, paste in the repository URL and go. All the plugins can actually be controlled via custom theme files (with the exception of being able to remove the menu entry from files in the
contentdirectory and the favicon file output formats).The following READMEs are up-to-date (aside from the assumption of editable files):
I'll probably end up updating the documentation for the table of contents plugin (used by all the posts I just listed), which basically just requires a suitably named container to host the button.
Update: in fact I just did…
There are a few more that don't have updated documentation … but that are primarily partials invoked from a theme that (like all of them) can be seen in action on my site like the custom page banners, the webring navigation at the bottom, the social media
links and profile directory, google tag manager, plausible analytics with ignore visit toggle, and favicons (which doesn't have a partial but requires configuration modification to enable two additional output formats).Holler if you want help tinkering with anything.
Looks like I overtaxed the system, got five or so posts hanging in limbo.
plugin-conversation (a README Experience)
A plugin for Micro.blog with a partial for including replies and webmentions for post pages. The plugin also supports blacklisting individual responses to prevent their appearance. Its code lives here
plugin-programmable-search-engine (a README Experience)
A plugin for Micro.blog for adding a site search interface using Google’s programmable search engine API. It’s code lives here
How many of y'all are still under the delusion that we couldn't build Sass from templates to generate and link CSS under Hugo 0.54? Okay, now how many of y'all are publishing themes and plugins? Wait … how many weren't under that delusion?
Kinda peeved nobody bothered to tell me about how @manton's changes to plugin edits bork my entire paradigm (requiring me to explain to everyone how to create files in other directories … I had a plugin with just the files for y'all to edit … it was idiot-proof … and Manton looked at the description (which was too long thus preventing registration) and failed to mention it would be a useless heap of sh$te).
Create your own clones of my configuration file plugin … and I'll help y'all individually as I always have.
Otherwise, I think I'm done writing and revising documentation until such a time as there is a f$&king point to it. I'm happy enough coding up cool sh$t just for myself … and I'd rather get back to writing and art anyway. Refactoring the sh$t was a chore. Updating the documentation like pulling teeth. Hell … I wrote that table of contents plugin, gesture-enabled and everything, just to help y'all navigate that sh$t.
Holler when all your parameter values aren't stored as a massive heap of unmarshaling-required, all-at-the-top-level, long-as-f$&k-names-required-to-be-responsible-about-naming-collisions, impossible-as-f$&k-to-troubleshoot-whether-the-whole-GD-issue-is-related-to-end-user-invalidly-stringified-f$&king-JSON.
I'm out. Moving on
☾𐂂
plugin-lightbox (a README Experience)
A plugin for Micro.blog for presenting a slide carousel containing images and/or videos. Its code lives here.
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).
plugin-category-cloud (a README Experience)
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 (a README Experience)
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
datadirectory. 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.errclass 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.htmlto 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.
plugin-bookshelves (a README Experience)
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.htmlleftover 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.jsonfor 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?
