UPDATE: November 10, 2019 (most of the plan below is now realized in version 1.0.6+)
We are excited to announce that we are starting the planning stage for version 1.0.4 and beyond. The planning input is based on experiences with our plugin users and testing. Below are the sketch of the plans:
We will improve the usability of Prime Mover in limited hosting environments. What you can expect is that even if the server times out and terminate the server side request during export and import process, you can expect the process to complete. This is a bit difficult mission to do but we are confident we can pull this one. The current control we have in place is Apache native timeout but we discovered that PHP process isn’t terminated with this. There are lots of server timeouts, for example the PHP-fpm request_terminate_timeout that terminates server side processing when the limit is reached. Currently with version 1.0.3, if server terminates the request server-side, the client side hangs up. This isn’t good or users, so either we can add notice to user that the export or import cannot continue because the server side request is already terminated. The tricky thing here is that when request is terminated, WordPress native shutdown hook won’t fire. We will look for an alternative solution. Test Prime Mover for ultra-large databases. The largest database we tested is around half a gigabyte. This is not very common in most sites. But we planning to test for databases greater than 2GB. Producing this type of database is not easy and its not simple to find very large sites with this size. We will add support for specifying a blog ID in the multisite sub-site to sub-site migration. Currently with the latest version 1.0.3, Prime Mover requires that both sub-sites needs to have an exact blog ID. This is most likely the case for example a dev to production migration scenario or vice versa where both sites are cloned at the beginning so source/target sub-sites have same blog ids. However, in some instances, user might want to migrate from one multisite to a completely different multisite. This requires a different blog ID. User should be able to specify this when exporting. Add support also for migrating site users. This should be an optional export setting. In this case, if a package includes site users, they will be restored to the target site just like they were on the source site. As a result, the users from the source site will now also be users of the target site. This requires migrating the WordPress users and user meta table data, which is a bit tricky thing do. Currently users tables are not involved in the migration. And we preferred to have it this way.
If you are using Prime Mover and want to suggest an idea for features or anything, please contact us to include your inputs.