Hey @manton, is there a correct way to attach a category when creating a post via the micropub API? This doesn't seem to work. Perhaps I need to use 'category[]' and/or 'music'?
-
A solid use case for the introduction of a cross post API for @manton's parser would be that last one. You could configure the output to only have Bonnie's Twitter handle in the twitter post, using her name (or appropriate handle) for the actual blog and/or cross post targets.
A future feature for you @manton: global regex find and replace for the content Markdown files so I can remove the
crossparameters from mycardshortcode invocations for all the pages that have already been cross posted (thereby embedding the HTML directly in the Hugo output rather than relying on Javascript to transform the element upon page load (which it does to ensure a regular link is cross posted (from which the target platform can generate its own preview card))).Were I rolling my own cross-poster, @manton, it would also handle posting replies to a previous post for API's that supported it. In this way, I could tack on siloed additional thoughts instead of only sticking those on Twitter.
Bee tee dubs, @manton, were you to add a view to Micro.blog's Posts interface constructed with mass selection in mind (perhaps a list where the posts are displayed in a similar manner to the 70 characterish lead text generated for the timeline), I would totally be able to retroactively apply new tags to improve the organization and accessibility of my site tenfold. As it stands, I rarely have the patience to wait for the list to load when I need to make an edit and the list includes a post with 5K words and 20 or so media assets. No way am I gonna sort through 2K posts to apply new tags.
Moving forward, the signed art within posts oughta be tappable for the purpose of loading a lightbox at full resolution. Gave myself a Hugo shortcode that fetches the high resolution image off of GitHub as a resource to create thumbnail and full resolution copies of the image via the image processing API.
What do you suppose these are about @manton? They are the harmless errors I have mentioned that are generated by my conversation plugin, now exposed by the improvements to logging.
Hey @manton, if you exposed whatever search routine you have working here in the Micro.blog API so that Javascript calls could receive JSON query results, a wicked accurate site search could be created in place of crawler dependent implementations.
.@manton Does Micro.blog's Micropub API support setting categorie(s) in the message headers? Seems to be the last thing to figure out before creating myself a fresh posting shortcut.
Update: nevermind, found the Micropub standard, assuming Micro.blog's implementation conforms.
Yet another update: It does.
The f$&k-around-with list for the bookshelves plugin.
I mean … I bundled all my plugins into my theme and I suppose I could parameterize everything theme-related and register it, but I'm guessing I wouldn't be able to version my personal configuration files via GitHub repository any longer and apply them on top of the theme … so I'm pretty sure it wouldn't be worth the effort. The problem here really seems to be that everything is a Hugo theme by nature, the distinction between components is being arbitrarily layered on top. There is no reason, for instance, that a single Hugo generated Micro.blog site cannot apply multiple theme components (which in fact they do, we call them plugins). There is no reason the order of application could not be configurable. The illusion of structure works to simplify some aspects (like plugin configuration preservation) … this is far outweighed, however, by the limitations it imposes (like what those plugins can actually do or just how configurable they actually are). The answer to this continues to be the rebranding of the custom theme into what it oughta be, the root site configuration. It preloads with the blank theme. Users can add anything they can now to a custom theme … and these files should override installed plugins/themes. File naming should be deliberate as a general rule amongst plugin and theme developers so as not to incur naming collisions. In this way you can build your site up piecemeal while maintaing the last word as to what the final parameter values (or the templates themselves) should be. And, yes. This Micro.blog site configuration should be loadable from a repository so that everyone can enjoy version control over changes to their own site. cc @manton @sod @pimoore @whoeverelse
plugin-gallery (a README Experience)
A plugin for Micro.blog that is effectively a glorified wrapper for an invocation of plugin-lightbox's
gallerypartial, introduced by optional title and description elements and promoted to its own standalone page. The code for this plugin lives hereJust 'cause I felt like f$&king around this morning, @jsonbecker, the problem appears to lie in the utter inability to create a menu entry via the native Micro.blog page interface for a page whose content was not generated via that same interface (cc @manton). The old drop-the-link-in-the-content trick no longer creates the entry and redirects alone do not seem to create an entry.
As for mixing menu items created via the interface…
with menu items created outside of the native Micro.blog page interface…
the menu items, themselves, are merged flawlessly:
plugin-banner (a README Experience)
A Micro.blog plugin for dropping page-specific banners into your theme. Its code lives here
Okay … whatever. So I guess the Micro.blog READMEs have their own page now.
plugin-plausible (a README Experience)
A plugin for Micro.blog for adding Plausible Analytics. Its code lives here.
plugin-social-media-links (a README Experience)
A Micro.blog plugin for injecting your social media account links into the page
<head>with a partial suitable for profile display. It's code lives here.plugin-table-of-contents (a README Experience)
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.
