Hey @lfcnutter,
First, thanks for trying Migro!
For LocalWP you should use your Database Socket instead of the Host, you can find this configuration inside the Database tab on your local site.
Edit: Sorry, my bad, I’m assuming that you’re using Mac, but you may be using Windows for your test. In this case:
Local on Windows runs each site’s MySQL over TCP on its own port rather than a socket file, which is why Migro couldn’t guess it. Open LocalWP, select the other site, go to the Database tab and note the Port (a 5-digit number like 10090). In Migro’s “One field left” box, enter 127.0.0.1:10090, substituting that port. If that’s rejected with “not allowed to connect”, try localhost:10090 instead. Migro accepts a host:port value in that field.
Let me know if you have any other issue!
Thanks,
Al
-
This reply was modified 1 month, 3 weeks ago by
auadix.
Thank you. I checked the LocalWP Database tab and the Local Site Shell.
My current LocalWP installation on Windows does not display a Database Socket. It only provides:
Source site:
Host: localhost
Port: 10011
Destination site:
Host: localhost
Port: 10017
I also checked the Local Site Shell. There is no DB_SOCKET environment variable or any other database socket value available.
It therefore appears that this LocalWP version is using TCP connections through localhost and the individual port numbers.
Could you please confirm how Migro should be configured for this current LocalWP setup?
I edited the message but it may have been a bit late for you to see:
I made a wrong assumption that you’re testing on Mac, but for Windows is a bit different, as you pointed out:
LocalWP on Windows runs each site’s MySQL over TCP on its own port rather than a socket file, which is why Migro couldn’t guess it. Open LocalWP, select the other site, go to the Database tab and note the Port (a 5-digit number like 10090). In Migro’s “One field left” box, enter 127.0.0.1:10090, substituting that port. If that’s rejected with “not allowed to connect”, try localhost:10090 instead. Migro accepts a host:port value in that field.
Try this and let me know if it works! 🙂
Thanks!
OK pairing now successful using localhost:10011 and localhost:10017
have pushed a test page to production it has worked but the Live Progress bar still shows 99% even though below it shows success.
is this expected?
I need to run more tests on Windows!
No, it’s not expected. After initial tests on Windows I just assumed things were paired with Mac and hosted environments, but apparently it’s not.
The success below is the source of truth, but I’m preparing a new minor version to fix both the conditions you found, not detecting that is a windows machine and getting the port properly with the paring code and failing to reach 100%.
Sorry for those issues, I promise you those are Windows specific and my fault for not properly testing in a different environment! 🙂
Thanks,
Al
No problem. looks like an ideal plugin for my use and thanks for the quick responses.
let me know when the fix is vailable and I’ll run another test
I appreciate your patience! I’m working on this right now and will be running a bunch of other tests on Windows before the release, but you can expect later today since those are small fixes.
Will message you back here when it’s done.
Thanks again for trying Migro!
Hey @lfcnutter,
The new version is now up: 2.5.5.
I ran a lot of tests using Windows and the plugin should be more stable now to your local tests.
Thanks for pointing it out and it should work much better now.
Please, if you find any kinks, let me know so I can make things right! 🙂
If you decided in the end to use Migro, let me know and I will send you a Pro license for the year to compensate for your help!
Best,
Al
new version looks good.
2 localwp sites set up from scratch and migro installed on both.
pairing was automatic
uploaded 3 images on dev to media library
added those 3 images to existing page and selected for migration
migration of page and media library images successful
live progress bar now completes correctly
Migro Health still shows ToDo Configuration source (in blue)
does migro think this is still to be completed?
Query on possible future development:
Would it be possible on the Batch Content Migration to have a button against a selected item that could check the current status of that item on staging and live.
An indication of just exact match or different may be extremely useful.
Further testing results
all test up to this point have been made using a WordPress Administrator account
I’ve now tested Migro while logged in as an Editor alongside our custom editorial workflow.
The migration itself behaves very well and preserves the workflow statuses correctly.
However, an Editor can also access Migro Settings. From that screen the Editor appears able to change the environment from Production to Staging and can access Update Connection/Delete Connection controls.
For our use case, Editors should be able to work through the editorial workflow, but Migro configuration/pairing and production deployment should be Administrator-only.
Is there currently a capability setting for this, or could the Settings/pairing controls be restricted to administrators (manage_options)?
Both things are in the roadmap and can be accellerated.
The Editor capabilities was a bit put aside since I was just trying to give people access, but this is a easy win, to just display settings for user that has manage_options. I can get this out this weekend for sure.
For the current state this is part of the plan, together with dry run, so people know what will change before approving the migration. I think I can break it apart because knowing that things are in synch remove stress from the migration process, you don’t need to migrate things that are already up-to-date, so it’s easier for all. Will get this done mid-week.
About Migro Health showing it blue. Migro Health came up because some team are used to full DB migration and if they ran this Migro would lose contact with the other environment and break. Migro Health brings two major fixes, one is self-healing, if Migro detects the DB got overwritten it gives an option for the user to fix it by clicking a button, the other option, is what you’re seeing. Migro is asking you to replace the DB/REST API configuration with a wp-config.php entry (from the section: Make this site immune to database refreshes), you can just click the “Ignore this, the setup is fine as it is”.
When I have those updates live I let you know, those are great feedback, I really appreciate you taking your time to make Migro better! 🙂
OK. no need to fast track on my account. Still evaluating so am quite prepared to wait and see things once they are properly tested.
Those are good things to have, I’ve been mostly working right now in Page Builders capabilities and I need a break. So much tests back and forth for each of the existent Page Builders, it’s a lot of boring work. 😛 Change will be good!
Hello again @lfcnutter!
Migro 2.6.0 is officially out! Lots of cool stuff in this release, including all the features I was working on: the “In Sync” checkmark with automatic skipping for already migrated content, the Dry Run mode with diff viewing, and a bunch of small reliability fixes discovered during testing.
A quick note on how “In Sync” works: it’s a learning feature. As you migrate, Migro creates a matching key between environments to track synced content (which helps prevent false “out of sync” reports caused by dynamic page markup). It checks the destination site to confirm sync status and if it can’t definitively prove an item is synced, it migrates it anyway to make sure no updates get missed.
I also adjusted permissions for the Editor role. I couldn’t reproduce the Editor seeing the Settings page, but I decided Editors should really only see Batch Migration and the Quick Guide. All other settings are now strictly restricted to administrators (manage_options).
Hope you enjoy this version! Give it a try, and if you run into any bugs or have ideas for improvements, let me know.
Have fun!
Best,
Al
OK updated and ran some tests. looks like this could really suit our environment.
Permissions: v2.6.0 successfully removes the configuration controls from Editors, but Editors can apparently still perform migrations. For MBKA we’d prefer an option to make migration/Push/Pull to/from Production Administrator-only.
Dry Run differences: will Migro normalise source/production hostnames when deciding whether content differs. Otherwise pages containing absolute URLs may appear changed solely because for instancedev.montybees.org.uk becomes montybees.org.uk.
