Skip to content

sad twentytwentyfive

Quoted GitHub – WordPress/twentytwentyfive by WordPress (GitHub)

Twenty Twenty-Five is built as a block theme. The theme aims to ship with as little CSS as possible: our goal is for all theme styles to be configured through theme.json and editable through Global Styles.

This makes me sad.

In a different system, a configuration file like theme.json would be considered a design token where a design system will automatically generate a JSON file full of tokens to be used in a component library or website. The potential for design tokens are quite high, but sadly they’re less practical without tools that are configured to both generate the design token file or system and give easy access for developers to use them. Right now, it’s still piecemeal and there’s not a great workflow in many systems.

Modern WordPress development is abstracting a subset of CSS to a JSON file, for the ease of builders and publishers. The developers who build Block Themes are kind of being forced against the grain of the web in the development phase. Developers consumed by a Javascript-centric system, this might make a lot more sense. But, for those of us who want to build using the technology that browsers provide, this is very unappealing and backwards.

This is just another reason I can’t see how much longer WordPress will be serious going forward. Maybe the update to React 19 in Gutenberg will change things, considering that it makes Web Components a first class integration, also considering the possibility of using React Server Components. But, I haven’t seen anything that gives me an indication either of these are being really thought out.

This quote was from the TwentyTwentyFive Github Repo.

forage, my last wordpress theme

forage

Introducing Forage, my new hybrid starter theme joining Roots Sage and FootMATE. This is a project of love, giving me an opportunity to learn new technologies and simplify the WordPress theme I was using. While this might not technically be the last theme I apply to my personal site, WordPress is moving into a new direction of lots of Javascript to drive a WordPress block theme.

Why Forage?

I think the mushroom kingdom that we live among is quite interesting, and the act of foraging mushrooms feels like what I do when I’m writing code: I’m always looking for something to consume and use.

Features

Forage is a starter theme. This means that when you install it, no styling or interactive behavior is added to the front-end. This gives you complete flexibility to create the theme you want with minimal opinionated code.

  • Laravel Blade as a templating engine
  • Vite for compiling assets, concatenating, and minifying files
  • Biome for linting and formatting both CSS and JS
  • Modern CSS & JavaScript – No preprocessors, libraries, or frameworks
  • DocHooks provide new functionality of class method DocBlock as hooks into WordPress API
  • IndieWeb out of the box

Laravel Blade

Sage was my real introduction to Laravel, back in the days when PHP just landed in the version 7 era, so I was mostly used to older PHP 5.2-5.4. While I tend toward wanting pure forms of HTML, CSS, and JS, I found Laravel Blade to be an interesting abstraction of PHP. In the last few years, PHP has come of age in so many great ways. PHP 7 and PHP 8, and all point releases, added superpowers for functional programming and types, among many other features. Modern PHP and TypeScript, less so even modern Javascript, have a lot in common today. In many ways, it’s impressive where PHP is today.

Laravel Blade is a modern approach to templating PHP. In a similar way that TypeScript is also Javascript, all blade files are PHP files as well which makes it convenient to get started. The main benefits of using a blade file is the cleaner looking syntax and custom components. Not  Here’s a great overview of all the strengths of Blade.

Vite

I first used Vite via Astro, and as a build tool, it felt so easy and simple. I’ve used many other build tools over the years, from grunt and gulp to webpack. I tried others here and there, but nothing stuck. Vite, however, makes a lot of sense for WordPress classic theme development.

The instance of Vite used for this theme is so lightly integrated that you wonder how it’s really doing all that magic so easily. The biggest difference? I don’t need to have two environments to see live reloads anymore. If I’m using https://example.local/ to work on WordPress locally on my computer, Vite will use the same environment for live reloading. No need to switch to a different URL like https://localhost:3000! Truly, I’ve been annoyed by this for more than a decade about Webpack! No more!

Biome

This project feels like a game changer for linting. We’ve seen several come and go, with the most popular ones being ESLint, Prettify, and Stylelint in 2024. However, Biome is positioning itself to be one tool to lint it all.

The background is interesting and having won a contest set up by the Prettier folks, Biome has a strong position going forward. I expect some breaking features as it continues to mature, but it’s also stable enough for a large majority of linting rules that I already don’t miss ESLint. As of June 2024, the CSS linting is in its first public beta release, so it’ll be some time before that’s mature enough to replace Stylelint, but I fully intend to migrate over when it’s stable.

Vite and Biome Node Packages

The most exciting thing about both Vite and Biome is reduced complexity. Just by replacing Webpack and ESLint with Vite and Biome, respectively, /node_modules/ was reduced by more than 50%. In fact, I think even more packages were removed from the project overall. This is a big win.

Once CSS linting is stable, this is what devDependencies looks like in package.json:

  "devDependencies": {
    "@biomejs/biome": "^1.8.0",
    "glob": "^10.4.1",
    "vite": "^5.2.12"
  }

That’s refreshing!

Modern CSS & JavaScript

I have purposely included no libraries, frameworks, or packages to abstract CSS or Javascript. This might be considered silly or naive, but if you review both CSS and JS in 2024, the languages are powerful enough that the need for additional state management or other helpers and shortcuts is far less than before. I expect sometime in 2025 that so much will be supported across all browsers that we’re going to see some significant paradigm shifts in the need to use large frameworks or libraries.

In fact, for my own site, I’ve removed Sass completely. Because nesting is widely supported in modern browsers, all I did was convert Sass variables to native CSS Custom Properties and everything just worked. Having reviewed the site in non-supporting browsers that don’t have modern CSS syntax features, progressive enhancement is the winner because all content and functionality is still available even if it doesn’t look as pretty.

Regardless, it’s quite easy to just yarn add svelte or any other library if you need it.

DocHooks

From the FootMATE creator, DocHooks are an interesting syntactic sugar for functions and methods to the WordPress APIs using DocBlocks.

    /**
     * Loads default theme supports
     * @action after_setup_theme
     */
    public function addThemeSupport()
    {
        /* add logic here */
    }

The part that says @action after_setup_theme is the same as writing add_action( 'after_setup_theme', 'addThemeSupport, 10, 3 );. It’s a big cleaner and easier to parse the functions this way.

Currently, DocHooks only support adding to the API. If you need to remove, you still have to write remove_action('after_setup_theme', 'addThemeSupport');

IndieWeb

I’ve added as much Microformats2 syntax to the markup as I could so that you add a few plugins and it’ll be indieweb compatible almost immediately after setting up the pieces. We should own as much of our own content as we can.

Background

The Roots Sage project provided an excellent philosophy and approaches for a progressively developed WordPress theme, but after version 9, Sage had too many interconnected pieces, new dependencies, and legacy to keep up with. Additionally, having focused on so many other  returning to an old version of Sage left much to be desired, as well as plenty of broken services or packages.

I found FootMATE in spring of 2024 looking for an alternative. Strangely, it follows enough of a paradigm similar to Sage that it feels like a younger cousin. Also, the author decided to integrate Vite instead of Webpack, and that’s a huge win for productivity and DX.

The combination of the two themes satisfies my desire for good file architecture and modern tooling without much bloat or dependencies. It just works.

WordPress’ direction towards full-site editing and Gutenberg leaves much to be desired for developers working on WordPress. This theme, while starting from a basis of the classic theme structure, has a lot of flexibility between the two worlds of classic and modern WordPress theme development.

The Future

I’m going to continue development on this theme indefinitely, as both FootMATE and Sage deliver new updates that make sense for this theme. Additionally, I already have a number of Github issues that I hope to resolve or bring into the theme.

Ultimately, I’ll probably slow down on development for this theme soon and maintain things as time goes on. Who knows, I might support this for several years to come. I don’t have all the experience or expertise for some of the integrations I am questioning or interested in, so community help will be desired where possible. That said, I’ll keep an open mind about how to continue on with this starter theme.

I’m eager to hear any feedback or comments on the direction this theme is going and how to make it better. It solves my personal needs here on asuh.com but it’ll be interesting to see what appeal it has outside of what I needed.

Thanks for your support and eyeballs on this post!

wordpress 5.3 buttons are weird

I updated WordPress to version 5.3, saw the changes to the button styles, and then came upon this.

buttons within WordPress 5.3

I like the updated button styles, which in isolation, are transparent background colors with text and borders that are colored. This style works sometimes and is a good contrast from the button styles with solid background colors.

I don’t like that the hover or focus states of these new button styles barely changes. I also don’t like how closely the buttons mirror the form elements. There’s inconsistency in button styles throughout the whole system now with some that use solid background colors and others using transparent background colors.

I’m disappointed in this from a UX perspective. The overall state of WordPress accessibility might have improved in 5.3 but this feels like a regression.

EDIT: It looks like many others share this opinion, in different ways.
https://make.wordpress.org/core/2019/10/18/noteworthy-admin-css-changes-in-wordpress-5-3/

How does WordPress not have a feature or even a plugin to allow comments sorting?

WordPress 2.5 against MovableType 4.1

Wordpress logoWhen I decided to try a weblog so many years ago, I had no idea where to start or what to do. I started out with a couple of years on a no name system before falling in love with Movable Type in 2004.

Movable Type became my CMS and was solid. It appeared to be superior in development and features compared to its rivals. They later changed their business plan and charged for their blogging system. I think the community was offended and I noticed less support and praise. Suddenly, out of nowhere, comes open source platform WordPress.

WordPress had a quite a buzz. When I first tried it out in versions 1.5, I was impressed. However, with all the upgrade and plug-in problems, I decided it wasn’t worth it for me to switch from Movable Type. I was happy with what I had, knowing I had a growing problem.

To end a long story with a short ending, I integrated Movable Type’s lackluster commenting system with the power behind phpBB. This served me wonderfully until my web host decided to screw me over a few years ago and shut down. Setting Movable Type back up and reintegrating it was a nightmare; it was an ongoing mess.

Fast forward: Movable Type 4.1 released itself as open source, WordPress 2.5 was released. As I’m a huge fan of Happy Cog and their products, I knew 2.5 would be an amazing update to WordPress’ admin system. Indeed, it was enough. MT 4.1 was an amazing update, but its anemic community and lack of interest was enough to drive me away. Not permanently, however.

Jump over for some additional commentary.

(more…)

screw blog software

I’ve made the switch to WordPress. I’ll talk about it in the next couple of days. All I can say is it’s infinitely easier than MovableType. No more major stress over my website! I am losing a bunch of comments that live in my phpBB forum, and I’m not even about to try and figure out how to transfer them. Anyone up for it? There’s money involved!

I’m sure there’s some broken mess all over the place, and I am not sure whether or not I’ll keep this new layout, but I’ll slowly figure it all out. I had a layout in development that I might refer to and integrate into this, but it depends on how much time I want to commit amongst the billion other things I have going on