I assume you have nix installed as a package manager at least if not the whole NixOS thing and a working home manager setup.

Most of the setup below was obvious, but the password stored externally to your configuration wasn’t quite defined in the section on setting up external sync services. Using feedbin-passwordfile you can set the location of the file you store the password in. Then that file only contains the password on the first line as described in the Newsboat password API docs.

Unlike some other applications, Newsboat will not work if you use single quotes around the extraConfig options so you have to escape " to stop the parsing error.

  programs.newsboat = {
    enable = true;
    autoReload = true;
    reloadTime = 10;
    extraConfig = "
urls-source \"feedbin\"
feedbin-login \"curtis@curtismchale.ca\"
feedbin-passwordfile \"~/.newsboat/feedbin-password\"
    ";
  };

As I set up a new Laravel project with SQLite I’ve found many references to enabling Write Ahead Logging being a large performance boost. All of the blog posts I’ve seen say to use the after parameter in your database connection like this.

'sqlite' => [
    'driver' => 'sqlite',
    'url' => env('DATABASE_URL'),
    'database' => env('DB_DATABASE', database_path('database.sqlite')),
    'prefix' => '',
    'foreign_key_constraints' => env('DB_FOREIGN_KEYS', true),
    'after' => function ($connection) {
        $connection->statement('PRAGMA journal_mode=WAL;');
    },
],

But when you look at a modern Laravel database connection you’ll see that there is a defined parameter for journal_mode but no documentation on how to set WAL using this parameter. Thanks to wew for pointing me to the proper Issue showing me how to add WAL using the journal_mode parameter. Now my database connection looks like this.

'sqlite' => [
	'driver' => 'sqlite',
	'url' => env('DB_URL'),
	'database' => env('DB_DATABASE', database_path('database.sqlite')),
	'prefix' => '',
	'foreign_key_constraints' => env('DB_FOREIGN_KEYS', true),
	'busy_timeout' => 5000,
	'journal_mode' => 'WAL',
	'synchronous' => 'NORMAL',
],

I’m new to Laravel and while I had a working project via docker compose on my laptop 2 weeks ago, I’m on a new machine and needed to reinstall the project I had already been working on.

So far I’ve only built out the templates. I’m not interacting with the database outside whatever the default setup is. I expected to clone the project, setup .env files and run docker compose up to get my project going.

What actually happened was a big error screen about not being able to access storage/framework/views/<longstring>.php. Searching online I got lots of information saying that I had a file permission issue with Docker that doesn’t exist on macOS or Windows because of how they do virtualisation which sent me down a path of messing with chmod and groups on my Fedora 40 machine.

The real fix was php artisan migrate which initialised the sqlite database. Then my Laravel project ran on via docker compose without issue.

I just read this article on HTMX being a big deal for WordPress and I just don’t see it. To vastly simplify the article, give the code below and using the HTMX JavaScript library:

<a href="https://mysite.com/books" hx-target="#books">
	View Books
</a>

<div id="books"></div>

This tells HTMX to fetch the content at the /books location and populate it in the #books ID. Somehow this is better than making an AJAX call to do the exact same thing.

I just don’t see it. The author goes on to call WordPress a “monolithic PHP server” as if it’s a bad thing. To me it seems like people like hating on PHP and HTMX is simply a way to “make it modern” instead of using a traditional AJAX call.

I can’t say I see any benefit to HTMX at all. The good part is I don’t need to invest time into learning it then.

Bold or italics in text is often used by sighted users as described in style guides to represent book titles or other citations. How does this impact users with disabilities and users that access your site with a screen reader?

What not to use

Both <b> and <i> tags are considered WCAG compliance errors. Don’t use them.

Using a style element style="font-weight:bold" is not accessible. It only changes the appearance of the text and does nothing to convey meaning to any screen reader user. If this is a purely visual decoration this should be in your stylesheet not inline in your content.

Headings are often bold, but they should not be use simply to bold text. They are used by many users to navigate the content of a page and provide structure to your content.

Screen Readers and Bold Text

While a sighted user can see text marked with <em> or <strong> tags most non-sighted screen reader users won’t have the same notation available since screen readers don’t acknowledge <em> or <strong> unless they use a specific one and turn on the setting. Most users don’t change the defaults on anything though so this is unlikely to be a use case that could be viably considered.

What to do instead of bold?

Gov.uk has a great look at this with their Warning text. If you click through to the HTML version you’ll see a visually hidden piece of text that says Warning.

<div class="govuk-warning-text">
  <span class="govuk-warning-text__icon" aria-hidden="true">!</span>
  <strong class="govuk-warning-text__text">
    <span class="govuk-visually-hidden">Warning</span>
    You can be fined up to £5,000 if you do not register.
  </strong>
</div>

Using this Warning text means that users of screen readers get the semantic meaning of the text while visual users do not see the extra warning and instead see the styled text with a graphical element denoting that the piece of text is something to take extra note of. This is the same type of notation that is recommended by Deque University

In general text your text-level semantics should be treated as a progressive enhancement instead of required to make what you’re writing understandable. If you need a bold element to make your content have the emphasis you feel it needs that’s likely a sign of bad writing. Your text should put the emphasis on the right point without the need for any extra bold markup

Is the <em> or <strong> tag the best element to describe what you’re trying to emphasize?

<cite> is intended for short citations such as book titles.

<var> is designated to represent variables or computer code and mathematical equations.

<code> is for longer blocks of code or for the code references you note here

<kbd> is designated to specify key presses to be typed be a user.

nix-shell is an excellent package manager for any macOS in large part because it doesn’t install things globally so you don’t end up with version conflicts. While you can always go to the web to search for nix packages, you can also do this from the command line if you enable the experimental features of nix.

To do this on macOS open /etc/nix/nix.conf in your editor. I use NeoVim so my command is sudo nvim /etc/nix/nix.conf. Then add the following line and save.

experimental-features = nix-commad flakes

Now you can use nix search nixpkgs nodejs to search for all the available nodejs packages in the nix repository.

Like an idiot while I was going to do a “quick” bit of work to get ahead for next week on Friday. First I decided it was time to update Homebrew before I really got into diagnosing a problem for a client. Of course mayhem ensued with the wpcli commands no longer working with LocalWP after I ran brew update && brew upgrade.

There were two main errors to search. First the icu4u library wasn’t loaded. This library is used for unicode characters and is a requirement of PHP, MySQL and a number of other things that Homebrew was managing. The specific error is below.

Library not loaded: /opt/homebrew/opt/icu4c/lib/libicuio.73.dylib

Further down in the same error block there was a note about PHP 8.0 not being installed.

Error: php@8.0 has been disabled because it is a versioned formula!

After searching and finding these general directions to remove and reinstall LocalWP, I was still out of luck. Worse, I no longer had any development sites installed locally as I removed them all during the uninstall process.

Fixing with Homebrew

Ultimately after a bunch of fruitless searching I came across this article saying that PHP 8.0 was no longer supported in Homebrew. To continue to have it installed I needed to get it from a different repository with the following commands.

  • Add the new repository to Homebrew – brew tap shivammathur/php
  • install php 8.0 – brew install shivammathur/php/php8.0

Now my wpcli commands work as expected and I no longer see the errors from icu4c. The big problem with this, and anything installed with Homebrew, is that we’re messing with my main PHP version in my shell. I’m always running PHP 8.0 now, even on projects that may need earlier or later versions of PHP.

Fixing it with nix-shell

Of course you’ll need to install nix-shell first with these instructions.

A far more portable and repeatable way to fix my issue is to use nix-shell. Instead of messing with the main versions of software running on my machine, I’m only messing with the current instance of the terminal that I’m working in.

The easy way to test this is to run the following command which temporarily installs php8.1 and wpcli in my terminal.

nix-shell -p php81 wp-cli

You’ll still get an error connecting to the database because the shell doesn’t understand how to make the connection to LocalWP but that can be fixed by going to the Database tab in LocalWP and copying the socket value into the DB_HOST value. It should look something like this:

define( 'DB_HOST', 'localhost:/Users/curtismchale/Library/Application Support/Local/run/CiNKEaTuy/mysql/mysqld.sock' );

Now when I run a wp-cli command I have a connection which means the next step is to create a shell.nix file I can place in the root directory of my project which has the values I need setup already so I don’t have to manually run them each time. This is what my shell.nix file looks like.

let
  nixpkgs = fetchTarball "https://github.com/NixOS/nixpkgs/tarball/nixos-23.11";
  pkgs = import nixpkgs { config = {}; overlays = []; };
in

pkgs.mkShellNoCC {
  packages = with pkgs; [
    wp-cli
	php81
  ];
}

Then when I open up my terminal I run nix-shell and the current shell is setup with php81 and wp-cli every time. I can move the same shell.nix file to a new site, or a new computer and run nix-shell and I’ll get the same environment in my shell every time.

I use MailPoet on my personal site to run my email lists and that means I sometimes have it active when I’m developing locally. When I have any site set up to develop locally I use the WP_ENVIRONMENT_TYPE constant to tell WordPress that I’m on a local site, but unfortunately MailPoet doesn’t respect this.

I found out that MailPoet is monitoring my emails (fine) and found that I had some URL’s that were unreachable at curtismchale.test because they’re on my local computer and can’t be reached by anyone but me. Thus my account was blocked from sending and marked as spam. I got a fairly pleasant but strongly worded email about sending spam and my account is now under review until I confirm that I’ve removed the curtismchale.test domain.

So instead of using built in features of WordPress to make my life easy MailPoet wants me to always make sure I disable the plugin locally so I don’t send emails. That sounds good, but I’ve found bugs in MailPoet during local development that I would not have found in a live environment. Bugs I was able to fix or work around because I was developing locally.

What MailPoet should do is what WooCommerce Subscriptions does, notice I’m on a local environment and then put up a nag about being disabled because I’m probably local and if I want it to process payments or emails anyway I have to click a button.

I never have to manually worry about WooCommerce Subscriptions trying to charge my users twice because they built a plugin that anticipates developer needs.

I’ll forget to turn MailPoet off some other time when I’m doing development and I’ll get another email about it. Maybe next time they’ll shut my account down…but that could be fixed if they added the local check.

Yes I did mention that to the support agent, but I likely won’t wait for them to add the feature. I’ll likely build a plugin that lets you choose plugins to turn off locally that will automatically turn them off if it detects WP_ENVIRONMENT_TYPE set to local.

His overall answer is no, WordPress is JavaScript focused. While I think there are a few interesting sessions that Reuben highlighted I feel disappointed to still see WP going down the React route as it is so slow.

As I wrote a few days ago, we should send HTML to users then use some JavaScript to make the interactions a bit nicer. Your whole site should work without JavaScript involved in any fashion.

All this JS crap continues to feel to me like we’re slowly heading back to the Flash days where you had to wait for loading screens.

Out of the box Varying Vagrant Vagrants lets you define a PHP version to use for each site you’re adding to the configuration file. What this doesn’t do is change the PHP version that WP CLI uses when you use vagrant ssh to log into the sites you’ve just created. Unless you take an extra step WP CLI will continue to use the default PHP version for VVV.

Installing Other PHP Versions

In your ~/vvv-local/config/config.php file you’ll see a section that looks like this.

# Extensions https://varyingvagrantvagrants.org/docs/en-US/utilities/
# are system level items that aren't websites, that install tools or packages
# the core extensions install tools such as phpmyadmin or new PHP versions
#
# these used to be called utilities but people kept requesting
# extensions not realising so it was renamed
extensions:
  core: # The core VVV extensions
    - tls-ca # HTTPS SSL/TLS certificates
    - phpmyadmin # Web based database client
    #- memcached-admin # Object cache management
    #- opcache-status # opcache management
    #- webgrind # PHP Debugging
    #- mongodb # needed for Tideways/XHGui
    #- tideways # PHP profiling tool, also installs xhgui check https://varyingvagrantvagrants.org/docs/en-US/references/tideways-xhgui/
    #- nvm # Node Version Manager
    #- php56
    #- php70
    #- php71
    #- php72
    #- php73
    #- php74
    - php80
    - php81
    - php82

Note at the bottom of the section of code I’ve removed the comments on PHP 8.0, 8.1, and 8.2. By doing this I’ve asked VVV to install those versions of PHP when it provisions.

Setting PHP Version for WP CLI

Now we need to log into VVV with vagrant ssh. To see which versions of PHP you have available navigate to /usr/bin. Then I usually type php and hit the tab key twice to try and autocomplete the command. Since there are many things starting with php terminal shows me a bunch of options.

Now I need to set the version of PHP I want to use with sudo update-alternatives --set php /usr/bin/php8.0 if I want to use 8.0. This sets the default php call to the version of PHP you want to use for a site.

Now in the documentation for changing PHP versions in VVV there is a troubleshooting section at the bottom that talks about changing the value in vvv.nginx.conf file, but as with much documenation…it doesn’t tell you where that file is and I can’t find it. Ideally I’d change the default PHP version to 8.2 as it’s the most current version, but after looking through the docs a few times…there aren’t clear instructions on it.

If I do figure this out, I’ll update the documentation so that everyone can benefit from clear obvious documentation.