Tag: PHP (Page 2 of 11)

Sodium Compat: PHP Sodium Functionality via Composer

June 8, 2023 / Tom

If you’ve worked with PHP with any length of time and needed to use some type of built-in encryption, you’ve likely seen something about the Sodium library in the manual.

Sodium is a modern, easy-to-use software library for encryption, decryption, signatures, password hashing and more. Its goal is to provide all of the core operations needed to build higher-level cryptographic tools.

Unfortunately, the module that contains this library isn’t always installed with the PHP binary. It then has to be either re-compiled or enabled by a package manager. If you don’t have the ability, time, or access to do any of those, then there’s a solid alternative for the native library that can be installed via Composer: Sodium Compat.

Bankruptcy on Block Editor Blocks (But It’s Not What You Think)

April 21, 2023 / Tom

In August 2022, I started a series on Learning to Build Block Editor Blocks and I continued it for several months. The last thing I wrote in the series was the following:

So as I continue with the series, we’re first going to look at what’s required to implement a custom block that includes:

a heading,

a paragraph,

and an input field to help guide the ultimate output.

We’ll continue to use the customization options we’ve outlined in this post and show how we can apply them to what the user provides and how to ignore them for what we, as the developer, provide.

After that, we’ll look at adding an input to the frontend of the site as well as incorporating a SlotFill.

And though I had intentions to follow through starting at the beginning of the new year, I obviously never followed through with the series. In all of the years that I’ve been writing, sharing code, and generally participating in all things PHP, WordPress, and development, I don’t think I’ve ever simply declared bankruptcy on an actual series or even just on the consistency of blogging in general.

But that’s what I’m doing in this post.

Quick Fix: Module ‘imagick’ already loaded

April 7, 2023 / Tom

When working with multiple version of PHP installed via Homebrew, there’s a chance you’ll encounter error messages like this:

PHP Warning: Module 'imagick' already loaded in Unknown on line 0
PHP Warning: Version warning: Imagick was compiled against Image Magick version 1809 but version 1808 is loaded. Imagick will run but may behave surprisingly in Unknown on line 0

Granted, the version number may be different but the rest of the message will be the same. When I’ve experienced this, it’s when I’ve a set up like this:

I have multiple versions of PHP installed (anything from the earliest build in 7 up to the latest version in 8),
I swap among versions in my ~/.zshrc file depending on the project,
When I attempt to run code that’s on an older version of PHP after installing and using the newer or latest version of PHP, I see the above error.

To fix this, there are two things you can do:

Locate the version of the php.ini file for the version of PHP you’re currently using,
Update the php.ini file for the version to disable the version check on Imagick.

Using GrumPHP, Composer 2 and PHP 7.2

April 29, 2022 / Tom

I’m very much a fan of GrumPHP which I’ve written extensively about in previously posts.

And as my last past alluded, I’ve been adapting a piece of software so it maximizes its availability across all platforms using PHP regardless of now new or how old the platform is (at least between PHP 7.2 and PHP 8).

Here’s the thing, though: If you’re working with an older version of PHP then you’re going to need an older version of GrumPHP and if you’re going to use an older version, you may need an older version of Composer.

Except maybe not!

Installing Old Versions of PHP With Homebrew

April 28, 2022 / Tom

I love the speed at which PHP is moving these days and how fast the new versions are, too 🙂 but that doesn’t mean the software on which we’re going is going to consistently be able to keep up with the fast release cycles.

And that’s okay. It is part of software development and it has been since before most of us were writing our first lines of code (let alone before we were even alive). Obviously, this means that those of us who work with PHP are likely going to need to work with different versions.

Sometimes we’ll be working with the latest, sometimes we’ll working with a version or a few versions older, and sometimes we may need to work with something that’s deprecated.

And this is usually the part where certain engineers start saying we should upgrade all the things and stay with the newest version of languages and frameworks. But that’s not how it works.

What does this have to do with PHP, though?

Assume for a moment that you’re working on a project that was written with 8.0 but you start rolling it out to a suite of products. Some are running on a server with 7.4, some are running 7.3, and some are running 7.2.

Is it easier to handle all of the other software already running on their servers or refactoring your code?

A bit of a rhetorical question.