The 2 most famous wp migration plugins don’t work in v4. Duplicator and All in one WP migration.
Duplicator gets stuck on the first step.
All in one wp migration gets stuck on the very beginning when importing.
Anyone tried this? v3 had no problems with any of the two, so I guess the v4 has some restrictions.
Every other host I tried it on worked it all out just fine.
Hi, I have found EE4 is not ready for production server use. The migration script rtcamp provided is unreliable, didn’t work even after I tore it apart and rebuilt it. More importantly, the docker implementation in EE4 is very brittle and has broken catastrophically on me 3 times. I hope to eat those words, but so far thats’ my experience. I am falling back to EE3 which did not have these problems.
I love EE3, it has been very useful, I appreciate the excellent work that rtcamp has done, but I cannot recommend version 4 for production use. I have documented some bugs and problems at
Thanks for feedback. I figured as much, but I hoped things like this would work.
I think there are some restrictions on permissions in question which are blocking the ‘‘import’’ part, maybe database is blocked in some way when the database import begins but fails.
I don’t see any other reason on why it would fail. The files are just uploaded and extracted, but the database is where it all gets connected.
It must be the database problem because that is the first thing to import.
Maybe I am wrong.
For now. The only solution is to import database manually + the same with the files… or use wordpress importer and then add media library.
Final update here: I’m walking away. The server wont load the containers, error messages below. The ee4 docker implementation is too brittle to use. For fresh installations it may work ok. For real world, it seems like it needs some development and bug fixes to be usable. Documentation is super shallow. This product is not ready for production use, imo. I admit I only have superficial knowledge of docker, but EE does not trap error conditions or recover gracefully when there are problems. See you all in a year or so.
Best advice for anyone: take frequent snapshots! Working installations broke on me when I rebooted. Good luck.
I may be able to help a bit, since I just did this 3 times. I basically compared how the ee4 migration script works and a couple of websites with instructions. Bottom line: if you can move the source server WP site database and the source /htdocs/wp-content to the target server, in theory, you’re done.
But there are few wrinkles. I found the easiest way to move the database was to open PhpMyAdmin or Adminer (my choice) on both servers, then on the source site dump the database SQL to the screen, then just cut and paste it into the target site and run it in a SQL query window TO A TEMPORARY DB NAME. That way you dont have to re-run it if there are any problems. Then on the target database DROP all the tables except wp_users and possibly wp-options.
Then copy all the other tables from the temp database to the target database.
These are the wrinkles:
If you overwrite the users table, with the old users and passwords, you may not be able to log in. As long as you don’t stomp on the new user ee created for you, you should be fine.
Regarding the wp_options table, I found that the target WP site did not always write/read properly. So in my case, I kept both the wp_users and the wp_options tables of the target site database, then I hand configured the rest of the way. You may want to compare contents of the source and target wp_options files, and just copy over a few of the theme configuration records… that partially worked for me, but in the end it was less work to just hand configure the new site.
IMPORTANT UPDATE:
the underlying assumption that you can just move database tables between source and target databases is that they are the same DataBase version. I got caught on this 2x. At some point after the tables are moved, and a reboot, WordPress will compare the database version number in the database vs what is in /wp-include/version.php and then it will force you to a dialog box saying that there is a DB version mismatch, and you should click OK to “upgrade”. screenshot below. If you click OK, WP will hang at that point and EasyEngine wont load properly on reboot. Big problem.
Solution: upgrade wp version on source site, or do this https://stackoverflow.com/questions/17308436/wordpress-error-database-update-required/23506630
Regarding the website directory /htdocs/wp-content: if the versions of WP are close enough, or the same, then it should work fine. If the source and target versions are not too close, then you may have to merge the subdirectories to be sure you dont remove things the newer version needs that the older version doesn’t have.
Good luck, YMMV.
root@eta:~# docker info
Containers: 16
Running: 3
Paused: 0
Stopped: 13
Images: 8
Server Version: 18.09.1
.
.
.
root@eta:/opt/easyengine/services# docker-compose up -d
Creating services_global-redis_1 …
Creating services_global-nginx-proxy_1 … error
Creating services_global-db_1 …
Creating services_global-redis_1 … done
ty on endpoint services_global-nginx-proxy_1 (34810441eca136fd3bfdd3e14474bf824d05e7d37076d41814fc3158083c2ab1): Bind for 0.0.0.Creating services_global-db_1 … done
ERROR: for global-nginx-proxy Cannot start service global-nginx-proxy: driver failed programming external connectivity on endpoint services_global-nginx-proxy_1 (34810441eca136fd3bfdd3e14474bf824d05e7d37076d41814fc3158083c2ab1): Bind for 0.0.0.0:443 failed: port is already allocated
ERROR: Encountered errors while bringing up the project.
I chose not to use the migration script, I prefer to do these things manually. Just wanted to add that I’ve had a lot of success using UpdraftPlus to migrate sites: create a new WordPress site, install UpdraftPlus, upload the old site’s UpdraftPlus backup files to the UpdraftPlus folder in the new site’s wp-content folder, then use UpdraftPlus’ restore functionality (themes, plugins, uploads and database). It failed just once on a larger database.
I’ve also moved databases manually by downloading a copy of the old site’s DB using WP Migrate DB, which will do the necessary search-and-replace on URLs (if moving domains), then creating a new EE4 site, completely removing all tables from the new database, then restoring via an app like Sequel Pro or DBeaver. One extra step I found necessary, for whatever reason, is after restoring the DB log in to the new site’s shell:
ee shell domain.com
…and flush the object cache with…
wp cache flush
The restored DB worked fine after doing this.
+1 for UpdraftPlus. Never had a problem with it migrating from EE v3 to v4, or just restoring sites on existing ee installation.
I tried the migration script also and it failed miserably. Most of the code just does not work. Function names called by the wrong name, messed up file locations. I gave up and just used WP-cli to export and import database and rsync to move files. I had to change VPS hosts to use docker anyway so after spending hours on this I used WP-cli and moved 4 sites in about 10 minuets.
My only real huge issue with V4 so far is the update commands do not work. You can not change SSL, cache, or other settings. I like to be able to turn caching off for testing and then turn it back on. I am also worried about renewing LE ssl certs.
I have imported a couple dozen sites into v4 using Duplicator without issue.
However, what might be happening is the wp-config.php file needs an edit.
EE places it in the parent folder, which is a best practice. Duplicator will take the file (from wherever it was on the source, including the parent folder), and will drop it in the main folder.
Then, there’s a conflict - you’ll have two files. the original one, and the imported one.
The solution is to remove the imported one, and leave the original one. HOWEVER - the ‘wp_prefix’ variable may need updating to be the same as the source/imported site.
Try that. I guarantee it works.
@zewsk - this issue will cause the ‘DB update required’ message above too. Same issue.
@davidsandbrand Thanks for clarification. I understand what needs to be done, but it requires editing in the middle of the installer.php process. So, after the first step or second (idk) I have to edit WP-config files etc etc.
I will test that later on, but it is more complicated than just using manual migration.
So, I would rather copy-paste files manually, merge the new wp-config with old, and use phpmyadmin to replace database.
But, All in One WP Migration offers simpler solution. No headaches after migration.
I found a way without having to modify any files. I don’t want to write here everything I did, mostly because I have it here on my blog. So feel free to check it Easyengine v4 WordPress migration.
I trust Duplicator and All in One WP Migration will be better supported in the future, but for now, this semi-automatic solution seems the best.
If I choose to do everything manually it takes too long.
Cheers
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.
