What's New✨

As more and more development teams signed up for SpinupWP, it became clear that the events view screen needed some improvements. We’ve added a new team events view, which shows all events across an entire team. At the same time, we’ve improved the events view to indicate which site the event was actioned on.

Backblaze storage is a super affordable alternative to Amazon S3. As our customers have often requested it, we’ve made it available as a Storage Provider for your site backups. You can learn how to set up and enable Backblaze for your site backups in our Backblaze Storage Provider doc.

Wouldn’t it be great if you could somehow automate the manual tasks you have to complete after you’ve created a new WordPress site on SpinupWP? Maybe you need to install a specific theme, disable some default plugins, or configure specific site settings. Now you can, with the availability of the Deploy Script feature on all site types.

Previously only available on sites created from a cloned Git repository, the Deploy Script feature makes it possible to run any terminal commands after the new site is deployed. You can install any plugins or set WordPress-specific settings using WP-CLI and even run server-specific commands utilizing this feature.

At the moment, this is available when setting up a new site. We plan to add post-provision scripts for newly created servers and an account-wide way to create and manage scripts to run against new sites or servers in future iterations.

Inactive content is any content on your site that isn’t accessed often (like your Terms and Conditions page). Previously, inactive content was automatically removed from the cache if it was not accessed for 60 minutes. With this update, whatever you set your site’s Page Cache setting to, will also be applied to any content deemed inactive, and the cache duration will be set accordingly. Just one more way we’re helping keep your WordPress sites lightning fast.

Since launching our in-app notifications in June, we’ve been iterating on how to give SpinupWP users more precise control over the notifications they receive. It’s now possible to subscribe or unsubscribe to notifications for a specific server or site. Simply switch the Notifications toggle at the top of a server or site dashboard to set your notification preference.

The next step in the evolution of our notification system is only to notify you when something needs your attention. For example, is it really necessary to notify you the moment a server needs a reboot? No. We should certainly show that the server needs a reboot in the dashboard right away. However, it doesn’t warrant a notification until some time has passed and the server still hasn’t been rebooted.

We’ve deployed a new system for verifying that your DNS points to your SpinupWP servers when adding HTTPS-enabled sites. This new system improves the reliability of DNS verification.

We’ve also made error messages more useful when we detect that Cloudflare is in use:

When you log into your dashboard, you’ll now see a new bell icon next to your account avatar, which includes an icon with the number of unread notifications.

Clicking on the bell will open the notifications list, which will present you with the list of your current notifications. You can view the details of the notification, mark it as read or unread if you need to come back to it later, or mark all notifications as read. The notifications list will currently include the last 100 notifications, both read and unread.

We’ve also added a new Notifications settings screen, which you can access by visiting Your Account in the account drop-down then clicking the Notifications link on the left. Here you can control which notifications you subscribe to and whether to dispatch them via email, show them in the SpinupWP dashboard, or both.

If you find you get too many emails from SpinupWP, tweaking these settings should allow you to cut back on email notifications.

All SpinupWP servers come with Certbot preinstalled so that you can use a free Let’s Encrypt certificate to secure traffic to and from your websites. While Let’s Encrypt certificates are more than suitable for most WordPress websites, you might be in a situation where you need to use a custom certificate from an external certificate authority like DigiCert or Thawte. In this case, you will need to copy the certificate and its associated private key to your server and enable the custom certificate in your SpinupWP dashboard.

Learn how to use an external certificate with SpinupWP in our Custom HTTPS Certificate doc.

At SpinupWP we keep a close eye on any packages we install on your servers, so you don’t have to. There are two updates related to these packages that we’d like to bring to your attention.

Recently we discovered a bug in the Ubuntu package repository that we use to install PHP on SpinupWP servers. This bug meant that on some servers, if you ran apt upgrade to manually upgrade your server, the redis, imagick, and igbinary modules for PHP could be uninstalled. This might result in errors being logged to your site debug.log, making these files quite large.

After a long wait, WP CLI 2.5.0 was released on the 19th of May. This is an important update because it includes support for PHP 8.0, which was officially released in November 2020.

To incorporate these changes, the next time you log into your dashboard you’ll see an upgrade notice for your servers titled “Upgrade Server – Fix PHP Package Issues & Update WP-CLI” which includes both of these updates. We recommend running this upgrade as soon as possible.

Once the upgrade is done, we suggest checking any debug.log files on that server. If you’re using our recommended SpinupWP plugin, the log file will be located at /sites/DOMAIN/logs/. Otherwise, the WordPress default location is the wp-content directory.

We’ve just pushed out a critical upgrade to all SpinupWP customer servers to patch a Composer vulnerability.

We have a policy at SpinupWP of never making any changes to your server unless we consider them to be absolutely critical. Composer has released a fix for a command injection security vulnerability that was reported a few weeks ago. We felt that it was important to act on, so we’ve automatically updated Composer on your server.

The main impact of this vulnerability is to services passing user input to Composer, including Packagist.org and Private Packagist.

You can now switch your sites to run on PHP 8!

Upgrading your site to use PHP 8 can be done by clicking on the Settings menu item from the site dashboard and changing your PHP version to 8.0.

To make things easier, we also released an upgrade that allows WP-CLI to run its commands using the PHP version of the site it’s running on. This means that if you keep your sites on PHP 7.4, everything will work as you expect it to, making for a much smoother server and site management workflow.

WP-CLI will now use the site’s selected PHP version instead of using the latest version of PHP on the server.