Better migration of "PHP from OS vendor" parameters
Please consider the following use case:
- testdomain.tld on a CentOS target server is using "PHP from OS vendor" version 5.3;
- The destination server is Ubuntu 14, with newer version of PHP from OS vendor, so you install PHP 5.3 with Plesk Installer;
- The migrated testdomain.tld will have different PHP parameters that may cause disruption of the website.
An example: PHP short open tag is enabled by default on PHP from CentOS repository, but is disabled on PHP 5.3 handler installed via Plesk Installer. If a PHP code uses short open tags, the script will stop working. Plesk Migrator should handle this case.
The problem may be in that destination server will not be able to use specified version of PHP for the migrated domain because of absence in official OS vendor’s repository. To prevent this kind of problems we see improvement of pre-migration checker which will notify you about possible post-migration issues. After that, the server administrator must solve the problem himself. The automatic resolving of these incompatibilities looks very dangerous.
While migrating some subscriptions only, it is not useful and confusing that that Plesk Migrator complain about:
- missing plesk-mobile extension on destination server
- missing Courier-IMAP (if destination server uses Dovecot)
> "in that destination server will not be able to use specified version of PHP for the migrated domain because of absence in official OS vendor’s repository"
Infact I installed the specified version via Plesk Installer.
> "The automatic resolving of these incompatibilities looks very dangerous."
No, if you limit to those PHP parameters you can already change via Plesk UI on a per-domain basis. Here is the list: https://snag.gy/VPKklM.jpg
Please check other glitches in my comments too.
Too, clicking "Details" link near to a failed migration freeze the browser for ages to open the popup even with short outputs.
Other small glitches I've found:
If a migration fails while performing database migration, business objects aren't fully migrated too and this isn't noticed at all. Even worse, when you fixed the database issue and retry the migration, clicking the button "Re-sync", a clever popup asks what objects has to be re-synced, but the checkbox "Business objects" is *deselected* by default. This is confusing and unexpected, as the database migration is not related to business objects.
1) Migrate testdomain.tld from target server A to destination server B;
2) Migration fails because MySQL is older on the destination server and some features aren't supported;
3) You fix the database issue and retry the database migration only, because files and mails we're migrated without issues.
4) The resulting domain is missing Let's Encrypt certificates.
5) Re-syncing migration selecting checkbox "Business objects" restores the missing certificate.