Author: helen

  • Exploring custom blocks from a PHP-centric developer UX point of view

    I’ve spent the last 8 months telling anybody I talk to about custom WordPress block development that they were way less scary and much easier than I thought they were going to be as somebody with minimal React experience, and that achieving a 1:1 editor experience where you manipulate directly in the content area instead of metaboxes or panels really comes alive when you reuse the same markup and CSS from the front-end and leverage the React components the block editor ships with. Because of that, I think a big game-changer for adoption and shifting thinking would be to find a way to unify templating between the front-end and the editor, essentially swapping the places where you output content with the corresponding editor component.

    So what had happened was… I was once again going on and on about this to Mark Jaquith, who blessedly seems to enjoy walls of text from me about programming puzzles, and it turns out he’s been thinking about the same thing as he gets into block development. A weekend later, and:

  • 💐

    a close up of a flower
    a close up of a flower
  • 💉

    a person wearing a hat talking on a cell phone

  • Making my custom keyboard even more custom

    Naked60BMP collage

    The first time I saw the Naked60BMP it was sold out, but I knew it had to be mine. The layout I like and the ability to make it Bluetooth, in something so unique and portable? Sold. So when it finally came back in stock, I immediately grabbed a red one, because that was the only one that came with the artwork on a white background. Not necessarily my favorite cover color or material, but I figured I could source some interesting PU type of material and make it look like a makeup compact that’s actually a surprise keyboard.

  • Updating a WordPress plugin with a publish metabox field for the block editor

    Many years ago (October 2015, to be exact) I wrote a small plugin that allows you to add a note when updating a post, intended as a way to describe what was changed in that revision. For the developer set, it’s kind of like commit messages for your WordPress post/content updates. It was created to fill a need on various sites, such as the handbooks, but it seemed generally useful so I released it as a public plugin. After one more update in August 2016, it just sat there, usable and useful but without any attention. Until this week.

    I stream my open source work semi-regularly, and decided that working through how to adapt an old plugin to the block editor (2 years late) would make for a useful exercise. So I did that, for almost 4 hours! But that’s not how long it takes to do this – the base work of this really took about 45 minutes, with the rest of the time spent chatting and chasing a bug related to revisions. So, for this post I’m going to explain the process of achieving the final code, first demonstrating what most people will need, then what I actually did because of some specific UX needs, and then dissect the revision bug and things I tried that didn’t work out.