Happy Halloween! 🎃 Prime Mover 1.7.0 latest release is a major update. Check out this release notes for details.
= 1.7.0 =
- Fixed: Migration issues with sites using different database charsets.
- Fixed: Missing language folders during migration.
- Fixed: PHP 8.0 errors on MySQLDump class.
- Fixed: Corrupted migration with non-UTF8 WordPress sites.
- Fixed: Incorrect database charset used when exporting UTF8 sites.
- Fixed: Runtime error on theme restore due to file permission issues.
- Fixed: Runtime error on uploads restore due to permission issues.
- Fixed: Runtime error on plugins restore due to file permission issues.
- Fixed: Plugin deactivated when switching to non-permissive theme.
- Fixed: Stalled import due to incorrect admin capabilities of source site.
- Fixed: Unhandled WP_Error during plugins restore.
- Feature: Added force UTF8 database dump feature on non-UTF database sites.
- Feature: Supported migration from non-UTF8 sites to UTF8 charset.
- Compatibility: Tested for WordPress 6.1 release.
Full Internationalization Support
Previous versions of Prime Mover has some issues with non-English languages. The issue is more pronounced if the languages do not use the default UTF8 (utf8mb4) encoding. In addition, previous versions do not use utf8mb4 as default charset during the backup. This creates problems with languages that uses supplementary characters such as Chinese or Japanese languages.
Prime Mover 1.7.0 solves all internationalization issues as follows:
- Migrate the WordPress wp-content
languagesdirectory. This way the WordPress admin languages is always correct. For example if the user sets the admin languages as Greek, then it’s Greek also on the target site.
utf8mb4as default database backup character set. This is if your server supports this character set (depends on MySQL version) and if this is used by WordPress.
- Fully supports backup and migration of non-UTF8 sites. If your site uses non-UTF8 charset (e.g.
hebrew) – then you can still use Prime Mover to backup and migrate your site. This assumes that your target site is also using the same dB charset as your source site.
- [PRO version] Supports migration of non-UTF8 to UTF8 database character sets. For example – if you want to migrate your WordPress site that is using
tis620(Thai) character set to UTF8 (utf8mb4) dB charset. This is possible with the PRO version. This is useful if you want to change your charset to widely accepted utf8mb4 (which is MySQL 8.0 defaults).
- [PRO version] Supports migration of UTF8 to non-UTF8. This is used in cases where you want to switch the dB character set from
utf8mb4(UTF8) to something different that is more specific to your language.
Note that this version is fully backward compatible to packages created before Prime Mover 1.7.0. So you could still restore those packages without any issue. However if your site is non-English and if its affected with the internationalization issues, display glitch on characters ,etc – it is best to create an updated backup using Prime Mover 1.7.0+ so the site will be restored correctly.
Also, please note that migration and backup requires both sites to have the same charset. This is a technical requirement by MySQL and also WordPress. For example – you cannot migrate or mixed database with different charsets or collations. If Prime Mover detects that you are migrating or restoring to a different character set from your source – it will output a runtime error. Please check out this dedicated tutorial on handling this.
Efficient handling of permission issues
This version also handles the recurring runtime error issue during restore caused by permission issues. In previous versions – when a single file encounters a permission issue (e.g. could not be copied from package to destination folder) – a runtime error is returned. This runtime error is fatal and the restore could no longer be continued even if only a single file with permission issue is detected.
In Prime Mover 1.7.0+ – this is handled more efficiently as follows:
- Prime Mover checks if file exists on target destination and if writable.
- If writable – proceed with the restore (as it usually does, copy or move the file to destination).
- If not writable – check its destination file checksum vs the source file checksum.
- If the checksum matches – both files are the same.
- If files are the same – copying is skipped – since it is redundant. There is no point copying back to a file that is already the same as the source (even if its non-writable).
- Now if checksum is different. This implies that the source and target file is not the same. Prime Mover should copy the target file to destination for a correct migration or backup restoration. However Prime Mover will not be able to do so because of permission issues. This is the only time a runtime error is returned. The runtime error is so specific so user knows exactly what do with that file (e.g. either delete it so it can be replaced with an updated version).
Using the above modified handling – Prime Mover does not return false alarms on runtime error where copying is redundant. This will significantly reduce the number of issues associated with this and only requires the user to handle the runtime error when its absolutely necessary.
Stalled import due to no admin capabilities
There is an issue where the source site removes all capabilities for administrator yet it is included as user and export. On the target site – the
admin no longer have admin capabilities and this stalled/freezes the import. This is because the AJAX process requires administrative privileges but there is no admin user. It returns 400 error request.
Prime Mover 1.7.0 fixes this issue by restoring the administrator capabilities back to default.
WordPress 6.1 full compatibility
Prime Mover 1.7.0 is fully tested to work with latest WordPress 6.1 for both single-site and multisite platforms.