A mere eleven-or-so weeks after the release of the Theme & Plugin Files addon, WP Migrate DB Pro version 1.9 is out the door!
We’ve added a brand new backups tab to make it easier to manage any backups you do with WP Migrate DB Pro and cleaned up a large part of the core PHP codebase to make it faster for us to push out the features we know you want in the future.
Let’s see what’s new.
Backups Tab For Better Backup File Management
The major new feature in this release of WP Migrate DB Pro is the addition of the Backups tab to the user interface. The backups you do with WP Migrate DB Pro aren’t meant to be a replacement for server-side site backups; rather, backing up your database right before you perform a migration can be helpful if something goes wonky in your workflow.
For years we’ve had the option to backup either your remote or local database before running a push or pull. The problem was, until now, there wasn’t a way to view these backups through the plugin interface or even know they existed! The backups tab aims to make managing these files easier.
When you click on the backups tab you will see a list of all the database backups you’ve created during previous migrations. By default, these backups are stored in the /wp-content/uploads/wp-migrate-db/
folder. Each backup can be downloaded from this tab and then easily restored via WP Migrate DB Pro’s import feature or using a tool like phpMyAdmin or Sequel Pro.
This tab is the first step toward a more full-featured backup manager in the future. As Brad outlined in his recent post, a future version of the backups tab will have options to create a new backup as well as restore from an existing backup file.
This first version of the backup tab should help speed up any part of your workflow that involves database backup files.
Major Code Re-organization For Faster Development Cycles
While the new (and awesome) backups tab is the most prominent change in WP Migrate DB Pro 1.9, the largest changes are under the hood. Up until this release, the PHP code for WP Migrate DB Pro was, shall we say, less than optimal to work with 😂. As with many older projects, the technical debt of the PHP codebase had started to add up, with lots of ‘magic’ occurring under the hood. I’ve been working on the plugin since I started with Delicious Brains Inc in 2016 and I still don’t know how some of those old classes worked.
OOP Abuse
The biggest issue was the misuse of object inheritance, with many classes extending some parent class and adding/changing/removing properties and/or methods along the inheritance chain. This was often maddening when trying to add a new feature and would lead to extra long development cycles as we’ve mentioned in the past.
The goal of this refactoring cycle was, more than anything, make the file and class structure more rational – and ultimately ‘flat’. The new codebase has very little inheritance as we don’t require it in 90% of the cases. I aimed to not go off the deep end on refactoring methods and smaller chunks of code, but focused more on making the overall structure and architecture sound. This involved adding an autoloader, using a dependency injection container to load all the new classes and bumping the minimum required PHP requirement to 5.4. Finally taking our own advice!
PHP 5.4+ Now Required
That’s right folks, WP Migrate DB Pro now requires an outdated version of PHP that hasn’t been maintained since Sept 2015 😆!
In all seriousness, we chose to bump the minimum PHP requirement for WP Migrate DB Pro because we know that very few of our customers are using versions below PHP 5.4. When requests are sent to the Delicious Brains license API we also include the requesting server’s PHP version.
As you can see, less than 1% of customers are using PHP 5.3 and PHP 5.2 so we figured it was time to bump the minimum supported PHP version. We’ll probably bump the minimum PHP version again in future as these numbers drop.
Fancy New PHP
Adding an autoloader lets us add new classes and have them automatically included in the codebase. This largely removes the need for include
and require
statements. Using PHP’s spl_autoload_register()
function we now load in namespaced classes following the PSR-4 format. Having an autoloader made it much easier to break apart the large, four-thousand line SUPER classes we had.
The next new piece of code was adding a dependency injection container to the code base. Modern PHP applications generally use something called dependency injection. It’s a pretty clean way to write code – you ‘inject’ all the dependencies your class has up front. This leads to loosely coupled, more testable code. What this means for WP Migrate DB Pro is that by creating new, specialized classes to hold legacy code, we can inject these classes into other classes that require them.
Here’s a snippet of the new BackupsManager
class constructor with the Http
and Filesystem
classes injected:
public function __construct(
Http $http,
Filesystem $filesystem
) {
$this->http = $http;
$this->filesystem = $filesystem;
}
Where the dependency injection container fits in is initializing the injected classes and sorting out their dependencies. By using a container and defining each class’ dependencies through configuration, we’re able to write much cleaner, class-based code.
And cleaner, class-based code should result in even more releases coming in 2019.
Gutenberg Ready
We’ve tested WP Migrate DB Pro with the latest beta release of WordPress 5.0, a release that includes the new Gutenberg editor bundled into core, and everything is running as it should.
We were initially concerned as Gutenberg stores block metadata in HTML comments in the post_content
column of the wp_posts
table. However, this data is simply a JSON encoded object and is not an exotic PHP serialized data structure. WP Migrate DB Pro’s find and replace can handle JSON data in post_content
just fine.
What’s Next
While the one overall goal of this release was to get a better handle on the PHP codebase, the refactoring work is not done! Next up is tackling the JavaScript and getting that code in better shape and easier to work with. We’re aiming to get WP Migrate DB Pro’s codebase in tip-top shape so that all those new features Brad mentioned can be added to future releases – and much more rapidly at that.
What do you think about the backups tab and our approach to refactoring the codebase? Let us know in the comments.