Notes tagged “plugins”

Pushed v0.12.1 of Share on Mastodon yesterday. It can now be “tricked” into cross-posting video and audio (from WordPress’ media library to Mastodon) as well. Quick example: https://gist.github.com/janboddez/5c6a69ca603d42b53904f7af6b2ad030 Disclaimer: File type and size limitations apply.

I didn’t wanna deprecate IndieBlocks’ Context block nor introduce a bunch of breaking changes. So I simply added a couple new blocks (https://github.com/janboddez/indieblocks/tree/new-blocks/blocks). There’s two big differences:

1. The new blocks support page title and author information (whereas a Context block will only ever show a bare URL), in a so-called h-cite microformat.
2. They use, or support, Gutenberg’s InnerBlocks. This allows us to ditch sometimes unpredictable—as in, users don’t even know they’re there—block patterns.

Moved some common code into a global object thingy: https://github.com/janboddez/indieblocks/blob/new-blocks/assets/common.js. No clue if this is how it’s done, but it seems to work.

Yay! Another Gutenberg issue that’s existed for years. https://github.com/WordPress/gutenberg/issues/11681 Context: I want to lock down IndieBlocks’ like, but allow (any) InnerBlocks inside the new “like” block. This would allow me to add the necessary .h-cite and .e-content classes in just the right spots, while allowing users to add as many paragraphs, blockquotes, images, and whatnot without mucking up the post’s microformats.

Spent the evening experimenting with Gutenberg’s PluginPrePublishPanel. Thought it’d be nice if I could move Share on Mastodon’s “meta box” there. Think Jetpack does something similar.

Now I’m not so sure anymore. On the one hand, it may help prevent sharing when updating old posts. On the other, it’s almost too easy to simply disable the panel, so I’d probably still need a regular PluginDocumentSettingPanel.

Also, the way I currently process the old-style meta box interferes with Gutenberg’s setMeta(). No biggie, we can turn that off. Except … there’s still that “Custom Fields” panel (which I have open often): https://github.com/WordPress/gutenberg/issues/23078.

Conclusion, at least for now: I’m sticking with a regular meta box. (Which within Gutenberg looks somewhat out of place, but not horribly so.)

Added some major improvements to Share on Pixelfed just now. Planning to release before the end of the week.

Although I’ll likely not use Syndication Links myself, I added a bit of code to Share on Mastodon that adds the Mastodon URL to SL’s list of links. Still figuring out how to best create a “syndication links” block. Like, I obviously want to also include Pixelfed URLs. So do I add it to the Mastodon plugin, or the Pixelfed one? Both? A separate plugin? Aargh.

If your WordPress install and Mastodon server run on the same server, wp_http_validate_url() and thereby Share on Mastodon’s settings page may reject your instance URL. (WordPress, somehow, rejects “local” URLs.) The API calls themselves will probably work just fine, though. (wp_remote_post() and its cousins normally do not explicitly “validate” URLs.) This behavior’s “fixed” by explicitly allowing these URLs by means of the http_request_host_is_external filter. https://github.com/janboddez/share-on-mastodon/issues/46#issuecomment-1408315635

Added to Share on Mastodon’s “latest nightly,” so to speak: (1) the ability to upload not just featured and attached images, but also images in the post; (2) more robust alt text; (3) (server) error messages; and (4) (optional) admin notices.

Submitted https://github.com/janboddez/feed-reader for inclusion in the WP.org plugin directory. See what that brings. Thing I’m most “worried” about is that somehow the “image proxy” is frowned upon, or the way I set up the various “admin routes.” Or a glaring security issue. I mean, I’m fairly sure I sanitize all imported HTML and ensure that anything that’s ever touched does in fact belong to the logged-in user. (Heck, I make sure to fetch records—all SELECTs should be scoped by user_id—before attempting to update them for this very reason.) But, you never know …

A bit of an amateur developer and “homo economicus” myself, I find this way more interesting than I probably should.

In a comment on a popular Hacker News post, [Van Kooten] dropped the hint that he is willing to sell the nearly ten-year-old plugin[.]

Created a website for IndieBlocks. Hoping to eventually add proper documentation (the end-user kind, with screenshots and stuff), and code snippets and so on.

Now, to actually bring the (released version of the) plugin in line with the Getting Started guide. 😬

Ha, Chris Coyier linking to Terence Eden’s article (on extending one of my tiny WordPress plugins) linking back to my site is kinda cool!

(There’s yet another filter hook, by the way; lets you add a CW, adjust post visibility, and more.)

Bookmarked https://wordpress.org/plugins/shortnotes/.

Updated my “‘IndieWeb’ Custom Post Types” plugin a bit. Integrated a couple things I’d implemented as several must-use plugins at first; it all became a bit much. (Good thing nobody else actually uses it; their feeds would break.)

Seems Frank and I aren’t the only ones thinking about, and tinkering with, OPML and WordPress. (I also wasn’t aware of the OPML importer—I did know about the Link Manager, though—until a couple months ago, when I’d just built the tiny plugin that keeps my WordPress links in sync with my feed reader’s OPML endpoint.)