​

I've adopted Ajaxify Comments

I'm the proud new plugin author of Ajaxify Comments. Ajaxify Comments allows you to post comments without a reload. It also avoids the white-screen error messages of comments by loading the errors inline as the user submits the comment.

The original authors were looking for a new maintainer, and I happened upon the adoption notice and was a bit dismayed that the plugin was effectively unmaintained. I contacted the owners of the plugin and expressed my interest in taking over development.

The plugin was in update limbo, which meant it wasn't visible in search on WordPress.org. In essense, it was abandoned. The owners did their due diligence in vetting me and concluded that Ajaxify Comments and I are the perfect fit. So this makes it a total of four (4!) comment plugins I actively develop for.

The first thing I did once given the keys to the repository was to get it out of update limbo and let the 4,000 users of the plugin know that the plugin is under new ownership (via a pinned post). I've also spun up the compulsory landing page and am finishing up the documentation site. I also have a demo of the 2.0 Beta 1 you can spin up to see the admin refresh taking place.

I'll lay out my plans for the future of Ajaxify Comments once 2.0 is out.

Question: Should blocks come with shortcode equivalents?

Shortcodes have their place, but what about in block plugins? According to the available stats I could find, block editor adoption is not as great as it appears to be. If you count .com and Jetpack users, we're looking at about 10% adoption.

This means I don't think we can get rid of shortcodes just yet. So should your block plugin have shortcode support? I'm leaning yes.

Plugin Update: Plugin Info Card Gets a New Block

​WP Plugin Info Card is a great plugin for showing WordPress.org plugins and themes on your site. I've been slowly but surely moving over the plugin to DLX Plugins from my old plugin site MediaRon LLC.

Part of the planned next update is a block that allows you to showcase a plugin's screenshots in a new card layout.

To say this has been a complicated feature to code is an understatement. Since I do plan on having shortcode support, I need a way to queue images being pulled in from .org. I can also use this queueing system to keep the existing .org images up to date locally.

Here's a video of the block in action: wppic-screenshots.mp4​

Tutorial: Block.json API Version 3 is out

Block.json Version 3 is just a minor change for block developers, but has lasting effects on how content will be rendered in the block editor.

The goal is to load the block content in an iframe so that it is independent of the admin styles and JavaScript. Theme authors may have to change the hooks used when loading block scripts.

Tutorial: Loading Scripts and Styles with Block.json

When I published my Block.json Version 3 tutorial, some pointed out that if you are loading scripts and styles via block.json, then you are fine.

Yes, and no. I discovered that if you have multiple blocks in a single plugin, it's best to use handles instead of file paths to avoid loading duplicate assets.

This tutorial walks you through how to use both files and handles.

A quick health update for those who have been keeping up. I haven't had any more issues breathing. My heart rate is still through the roof, but that's because it's working harder than usual to keep up the flow of things. I still don't have enough capacity for singing Karaoke, but I'm slowing working back into it.

That's all for now. Thank you so much for reading and being a subscriber.

​​​

2100 Raintree Rd, Edmond, OK 73013
​Unsubscribe · Preferences​