Published: February 18, 2025 by PerfGrid

Pulse: Week 8, 2025

Hey! Glad you're here!

We're kicking off a new series called Pulse. The idea? To give you an inside look at everything going on, whether it's new features in our in-house control panel, infrastructure updates, or just useful tips and tricks we've picked up along the way. If we run into something interesting, we'll probably share it.

How often will we post? Honestly, we're not really sure yet, it might be weekly, monthly or whenever we have something we feel are worth sharing. Some posts will be quick updates on small changes, while others might be deep dives into topics that catch our attention.

Running a hosting company means dealing with a lot; software, infrastructure, challenges and the occasional headaches. Pulse is where we'll share it all with you.

What have we been up to this past week?

Over the past week, we've made a few infrastructure changes, as well as changes to hosting-panel.net, our in-house control panel that powers Grid Hosting.

PHP 8.4 rollout

We actually started this rollout in the end of January, but we finally completed this rollout yesterday evening the 16th of February.

In the end of January, we did a infrastructure wide deployment of PHP 8.4 to our Grid Hosting plans, the way we do this, is actually quite simple. All our infrastructure is managed by Ansible, adding a new version is a matter of adding php84 to our PHP list, and ensure the various packages we install for PHP extensions are already available for PHP 8.4. For the control panel side, it's roughly the same change, we maintain a config file we update with the list of supported versions as well as the default PHP version that new sites are deployed with.

When we have the PHP modules available that we need, deploying PHP 8.4 to Grid Hosting usually takes 20-30 minutes.

For cPanel, these updates are a bit different, it's managed through a cPanel feature called EasyApache4, after we've installed the version and packages, we have to apply some php.ini specific rules, and ensure all websites that are currently active, stays at the old version (e.g. PHP 8.3), as we change the default version on each and every server.

It's a bit more tedious, and releasing PHP 8.4 to cPanel usually takes a bit longer.

The reason why we usually wait until a few months after the official release, actually boils down to security.

All PHP versions we run, have a PHP extension called i360, it's a tight integration with Imunify360 from CloudLinux, what it does is to assist Imunify360 to block various possible security holes in real-time by effectively inspecting the code that's being executed. Imunify360 usually takes a bit for releasing this i360 package for newer PHP versions, which means we're also usually waiting for this module to be released as well.

Grid Hosting: DNS editor gets a minor improvement

This feature was requested by one of our customers that happens to manage a lot of domains, and likewise have to perform similar changes across a set of domains quite often.

Grid Hosting works by usually using the domain ID from the database as a part of the URL, such as /domains/dns/132 - this usually fine for most people; however, there may be cases where you're running a WordPress multisite installation with let's say perfgrid.dk, perfgrid.com, perfgrid.nl etc - and you have to apply a DNS change to all 3 domains. It would simply be easier to just be able to write /domains/dns/perfgrid.dk or /domains/dns/perfgrid.com - we've now made this a possibility.

While it's a small feature, it's still providing a small quality of life improvement, for those who do changes across domains.

This means, instead of this:

We can now do this:

The consequences of a new minor feature

From a programming perspective, it actually turns out to be less straight forward that one would think.

We're using Laravel for our panel, almost everything in Laravel is usually done with something called route binding, you're effectively doing an automated SQL query depending on the ID supplied in the URL.

So for example, if we have ID 132 in the URL, this will do an SQL query such as SELECT * FROM tbldomain WHERE id=132 AND userId=1;

Now, if you want to be able to use both the ID, or domain for example, you can't use route binding in the same way anymore. What you can do is to override resolveRouteBinding in your model to do your additional logic.

However, what we learned is that this have interesting consequences, since route binding, not only for example allows an ID to be supplied, but in fact you can supply a full existing model, and it will still resolve correctly.

What we actually ended up doing was simply not using resolveRouteBinding and instead doing some additional checks on the DNS editor page itself, since this does have quite a bit less impact on overall queries and execution within the system.