Notes tagged “wordpress”

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.)

When I exclusively used WordPress’s classic editor and Jetpack’s Markdown module (or Easy Markdown), syndicating Markdown to, e.g., Mastodon, was easy. (Both plugins store unparsed Markdown in post_content_filtered, so I’d cross-post that.)

Now that I spend more and more time in the block editor, I have this issue where blockquotes, once syndicated, are no longer recognizable as (block)quotes—I strip away HTML before POSSEing, and there’s no > or nothing in the original post.

Might eventually solve this by converting (all) HTML to Markdown first.

The new IndieBlocks settings screen(s). 😬

I’ve only recently developed my first Gutenberg blocks, and am now experimenting with “somewhat dynamic” blocks. My blocks revolve around microformats, after all, and I do not want existing posts reflecting block changes. I want these microformats “baked in,” even after my plugin’s deactivated.

Since we build dynamic blocks at 10up we now also don’t have the issue of not being able to update markup in patterns anymore. Because we can update the markup of our dynamic block which gets reflected everywhere.

Update: Just now reading https://developer.wordpress.org/block-editor/how-to-guides/block-tutorial/creating-dynamic-blocks/.

You can also save an HTML representation of the block, [which] will be rendered if your block is deactivated or your render callback is removed.

Best of both worlds? (My current approach, and a fairly standard one, involves a REST API call to get any “dynamic” data, while rendering is still done entirely in the block editor.)

Just switched my other blog to Brian Garnder’s Powder theme, and guess what? All microformats still in place! Only thing I had to do was hop in there and enable the post date block to always link to single articles. (Because note titles are hidden, so are the permalinks inside the heading elements.) Had to do that 3 or 4 times, but I can live with that. Another minor gripe: the “Tags:” and “Categories:” prefixes that are shown even when there are no tags and categories.

Yes! My IndieBlocks plugin is now up on WP.org. Current version offers a single “Context” block, and, optionally, (1) some custom post types, and (2) the ability to add microformats2 to block-based (!) themes. More is on the way. https://wordpress.org/plugins/indieblocks/

Tested it on a nearly empty site with the Blockbase theme, and things like an h-entry’s post type and very basic h-card information is being picked up fine.

Testing my “all-in-one” “IndieWeb” plugin for WordPress with the new 6.1 beta and Twenty Twenty-Three. Seems to work OK, but I’m wondering why my “site doesn’t support the core/post-author-name block.” Like, I knew about the post author block … Of course, you’ve got to install Gutenberg! Makes perfect sense for the new default theme to not work without a plugin.

Thing with WordPress nowadays is that we’ve now got blocks, reusable blocks, custom blocks, and block patterns, but also block styles, block variations, block templates, (theme) templates, and template parts. And they’re different things. (Also, [custom] text formats, block transforms, theme.json and block.json, server-side rendering, hybrid themes, and more.) And I haven’t even looked at React/JSX, yet.

Been playing with WordPress’s Full-Site Editor some more, especially the core “theme” (or “post”) blocks that are rendered server-side. Has allowed me to add not just microformats, but additional “social icons” (like Mastodon’s), too.

That explains! (I’ve been experiencing some issues with child themes, and was looking for a way to instead use the Site Editor only.)

[D]evelopers and users are expecting to be able to create this type of template in the new Site Editor. This is a reasonable expectation. Unfortunately, the feature is not complete yet and not included in WordPress 6.0.