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.
Bookmarked https://fullsiteediting.com/lessons/creating-block-templates-for-custom-post-types/.
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.
More FSE fun! Once a block theme is active, the “old” Customizer is notoriously hard to find.
Got to experience this first-hand because the default Twenty Twenty-Two theme does not style “Classic Block” blockquotes the way it styles “Quote Block” blockquotes, and I needed to add a bit of CSS somewhere to get that fixed.
More FSE fun! (I’m doing this experimenting on a different blog of mine, mind you.)
My theme (Twenty Twenty-Two) uses the Post Date block in just its two “single” templates. I’m adding support for microformats, however, and thus want date blocks on all home, archive, and search pages—have that dt-published class on all my posts, right?
So, the default date format’s F j, Y. Fine for English, but this blog’s in Dutch. (And while the date format’s correct (i.e., j F Y) in the overall blog settings, the Post Date block does not pick this up … Which means hand-editing some six template files it is.
Of course, since I’m overriding the default Post Date block anyway, I could totally make this smarter, but then I might spoil things for anyone else that would like to experiment off of my child theme.
Bookmarked https://themeshaper.com/2014/11/20/mastering-the-post_class-function/.
Quick reminder: WordPress has had (limited) microformats support since just about forever. The new “block” (FSE) themes, like Twenty Twenty-Two, not so much. This is a regression.
WordPress respects the hAtom microformat. Therefore every post has an
.hentryclass added to it to respect the specification.
Somewhat inspired by https://www.zylstra.org/blog/2022/09/wordpressindieweb-as-the-os-of-the-open-social-web/, I did some experimenting with WordPress’s new Full Site Editor. The result is this, still very hacky, Twenty Twenty-Two child theme. https://github.com/janboddez/tt2-mf2
Bookmarked https://tonz.eu/nlwordcamp/.
Hoping to update my “IndieWeb plugin” with basic block support. Fixing core would be even better.
Either way, themes will need to update, too.
Always trying new things, so I installed the “WPGraphQL JWT Authentication” plugin for WordPress, and it somehow seems to strip Location headers off WordPress’s JSON API responses. Found out because my slightly convoluted IndieAuth setup stopped working.
Good. Huge fan, still, (of WordPress as a content management system, not necessarily its “Full Site Editor”) but the last thing we need is a near-monopoly, or growth for the sake of it.
For the first time in WordPress’ nearly 19-year history, the software’s usage stats are showing signs of declining market share.
Bookmarked https://wordpress.org/plugins/shortnotes/.
Bookmarked https://github.com/euchenhofer/wordpress-webmention/commit/beb2d961f0074fc8b4a6fcd8babf533a4cd5db61.
I’ve previously complained about not being able to easily add a class to inline links in Gutenberg. This here code takes a bit of a different approach, and uses span and data elements instead. (Still, I’d love to be able to just use a elements, in a robust manner.)
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.)
A lot of my WordPress sites are based off a select few “base” themes, which I’d then change the fonts, colors, and spacing of (in a child theme, obviously). Being able to do so in theme.json will probably make that sort of thing quite a bit easier.
My one issue with ClassicPress is that it’s based on WordPress 4.9. (WordPress itself is now at version 5.9 and a fair number of plugins have moved on to—very few, ’cause not that much has changed, but still—core functions introduced in one of the more recent versions. All while, perhaps surprisingly, the Classic Editor plugin just works.)