No migration file present, remote export started

I would like some help with analysis why Shipper doesn’t want to move any of my 3 trial-to-move websites its stuck at 1% or [Task 1 of 14]: Export remote system

WPMUDEV Hosting < Self hosting on VestaCP (Ubuntu 18.04 LTS)

March 5, 2019 4:21 pm - No migration file present, remote export started
March 5, 2019 4:21 pm - [Task 1 of 14]: Export remote system
March 5, 2019 4:20 pm - No migration file present, remote export started
March 5, 2019 4:20 pm - [Task 1 of 14]: Export remote system
March 5, 2019 4:20 pm - No migration file present, remote export started
March 5, 2019 4:20 pm - [Task 1 of 14]: Export remote system
March 5, 2019 4:19 pm - No migration file present, remote export started
March 5, 2019 4:19 pm - [Task 1 of 14]: Export remote system
March 5, 2019 4:18 pm - No migration file present, remote export started
March 5, 2019 4:18 pm - [Task 1 of 14]: Export remote system

WPMUDEV Hosting < Self hosting on IIS 8.0 (Windows Server 2012 R2)

March 5, 2019 4:22 pm - Remote domain reachable, attempting export
March 5, 2019 4:22 pm - Pinging remote domain
March 5, 2019 4:22 pm - Attempting remote export auto-start
March 5, 2019 4:22 pm - No migration file present
March 5, 2019 4:22 pm - [Task 1 of 14]: Export remote system
March 5, 2019 4:21 pm - No migration file present, remote export started
March 5, 2019 4:21 pm - [Task 1 of 14]: Export remote system
March 5, 2019 4:21 pm - No migration file present, remote export started

  • Luís
    • Support

    Hi damyang ,

    Hope you're doing well :slight_smile:

    I saw the message you left on the Support notes about the DNS changes, after our live chat I was doing a migration but seems it was interrupted due to the changes in the DNS that you was doing.

    Also, I saw that you are trying to perform a new migration right now:

    Please let us know if it worked properly!

    Cheers, Luís

  • damyang
    • Flash Drive

    Hello Luis,

    thank you for your cooperation. Actually something unexpected happend. In early afternoon, I found out that you guys managed to successfully start migration and I was really happy. I’ve had “live” log opened in one of my browsers.

    When it succeeded, right about when email about that arrived, at first I didn’t check content on Destination. I just fixed DNS Domain names and turned public DNS records to the new (destination) server. Since I use Cloudflare DNS it was extremely fast thanks to their low/Auto TTL times. And than… bam! Site was default and empty. Of course I checked content and it was acutally expected behavior, since no content was there to show.

    I turned DNS record back, so production site went live again and checked destination in peace again.

    First thing I checked was Shipper / Tools – “live” log as I name it and new migration was ongoing… without me ever starting it. It was even more weird, because regarding time stamps, it was running all time along, so it seemed like there were two threads of it. I couldn’t stop it, because the progress bar didn’t show up to me so I just left it as it was and gone home. There were errors all along, of course, because it lost connection because of DNS actions.

    And now in late evening, after you message arrived here, I see it fixed itself somehow (or it was you maybe?) and it continues where it left off in the afternoon after I interfered it with DNS actions.

    We will see what will happen after it will finish. I will let you know of course.

    PS: other site started migration as well… from my point of you, by itself “automagically” somehow, or it was you? Or it was lagged starting operation from my yesterday’s unsuccessfull trial…

  • damyang
    • Flash Drive

    Hello again,

    Two of three websites went Server Error 500 and I figured out that the one we were Shipping together was affected by imported Plugins issue. I renamed “Plugins” folder and website opens – but it is default and empy. Via FTP I see transfered content, but Database is not aware of any of that.

    I think I will pass on Shipper and try it again sometimes in the future. Until than, I guess I will migrate manually or using other tools. Thank you for now!

    Damjan

  • damyang
    • Flash Drive

    Hey!

    I am linking this post here for reference: https://premium.wpmudev.org/forums/topic/shipper-is-stuck-at-1?replies=6#post-1382855

    If Nithin is willing to join in, than he is more than welcome. As I said in that post, if you guys are willing to continue troubleshooting, than go for it. As far as I am concerned, I support to get all-around experience for you and for me. I am not in a hurry with migration, so we can play with this one as we wish.

    I deleted destination website and created one from scratch. Access is (re)enabled…

  • Nithin
    • Support Wizard

    Hi damyang,

    Hope you are doing good today. :slight_smile:

    We can give one more test via Shipper plugin, and see how that goes. However, before performing the migration, could you please increase the server resources of your source website?

    I tried to create a php.ini file in the root directory of your source website, but it doesn’t seem to increase the memory_limit, and max_execution_time to the following values:

    upload_max_filesize = 128M
    post_max_size = 256M
    memory_limit = 512M
    file_uploads = On
    max_execution_time = 600

    Could you please check whether you could increase the above-mentioned rules via cPanel as mentioned in here:

    https://www.copahost.com/blog/increase-php-memory-limit-cpanel/

    If you don’t see such options via cPanel, asking the hosting provider to make the changes in your side would be helpful.

    I have increased the memory_limit to 512M in destination website. Please do let us know once the resources are increased in the source website so that we could run a new migration process, and see how that goes.

    Looking forward to your reply, have a nice day ahead. :slight_smile:

    Regards,

    Nithin

  • damyang
    • Flash Drive

    Hello Nithin,

    thank you for you answer. For this Website I have self hosting on VestaCP / Ubuntu 18.04 LTS and now all settings are set appropriately and services restarted (just to be sure they are effective). So another test has a go – green light… Thank you!

    Damjan

  • damyang
    • Flash Drive

    Hello!

    Migration was successfull based on Shipper log (attached).

    – Database is there with all the tables (I guess all of them, it seems like it, I didn't check tables one by one)

    – Files/Folders structure is there (checked by SSH and SFTP)

    – wp-config.php was edited by the Shipper accordingly (new DB name etc.)

    – Trying to visit website by its new temp name https://tehbo.wpmudev.host (Error 500)

    – Renamed /plugins to /plugins-renamed via SFTP (website opens, but it's blank / default)

    – I managed to get into wp-admin that way

    – Renamed /plugins-renamed back to /plugins (website still opens in new browser, OK, still blank / default)

    – Checked content via WP Dashboard: Pages, Posts, Media Library (all empty), Plugins (back in business since I renamed folder back to original, Theme is of course not validate, but that is not important atm)

    – Checked Settings/General (website URL populated accordingly to temp name by Shipper, https://tehbo.wpmudev.host, which is fine for the beginning)

    I'll leave it now as it is for you to check stuff-abouts… Thank you!

    BR, Damjan

  • Nithin
    • Support Wizard

    Hi damyang,

    Thanks for running further test, and for sharing your observation. I could notice the homepage currently seems to point a 404 page.

    The logs do look fine, however, I’m bringing that into our developer’s attention. It seems like the wp-admin login what was shared for the source site(luiswpmu), is no longer working.

    So, I wasn’t able to check both the website dashboard, could you please enable send the WP admin login credentials for both the websites, so that this could be looked upon.

    You can send credentials by using our secure contact form: https://premium.wpmudev.org/contact/#i-have-a-different-question

    – To Mark to my attention, the subject line should contain only: ATTN: Nithin Ramdas

    -Source WordPress admin username, and password

    -Destination WordPress admin username, and password

    -login URL

    -FTP credentials (host/username/password)

    -link back to this thread for reference

    -any other relevant URLs

    Please do follow up in the ticket once you have sent the above credentials. Have a nice day. :slight_smile:

    Kind Regards,

    Nithin

  • damyang
    • Flash Drive

    Hello Nithin,

    I’ve sent creds and everything using contact form. I enabled Source WordPress access through WPMUDEV Dashboard once again.

    Destination WordPress access and FTPS was prepared for you since WPMUDEV Dashboard was not transferred by Shipper or was left inactive – not sure; I intentionally left everything intact after Shipper did its job.

    Thanks!

    Damjan

  • Nithin
    • Support Wizard

    Hi damyang,

    Hope you are doing good today. :slight_smile:

    Thanks for sharing the login creds, I checked with the developer, and we could confirm the export to work fine from the source, but the import process to the destination seems to be stalled for some odd reason.

    We could confirm the export is intact, and running an import from the destination website should be enough to make the stalled migration restart, and run an import into the destination.

    I have already started the import on your website, it can take 3-5 hours to finish. Please let us know how that goes so that we could give a closer look if needed.

    Regards,

    Nithin

  • Nithin
    • Support Wizard

    Hi damyang,

    Sorry for the delay in getting back to you. Thanks for keeping the site as it’s. I could notice the issue, and it’s pointing towards the CornerStone plugin. These are the related errors to the plugin side:

    [26-Mar-2019 06:41:03 UTC] PHP Fatal error: Uncaught Error: Call to a member function get_element_names() on boolean in /xxx/wp-content/plugins/cornerstone/includes/classes/elements/class-element-front-end.php:28

    PHP Stacktrace:
    xxx/wp-includes/class-wp-hook.php(286): Cornerstone_Element_Front_End->register_shortcodes('')
    xxx/wp-includes/class-wp-hook.php(310): WP_Hook->apply_filters(NULL, Array)
    xxx/public_html/wp-includes/plugin.php(465): WP_Hook->do_action(Array)
    xxx/public_html/wp-settings.php(526): do_action('wp_loade

    [26-Mar-2019 06:41:03 UTC] Napaka v WordPress podatkovni zbirki Table 'xxxx_wpmudev_host.wp_ye_revslider_sliders' doesn't exist za poizvedbo select bot.txt info_cron.sh restart.sh restore-snapzfs.sh snapzfs.sh staging_sync.sh stats_cron.sh update.db.creds.sh wp-update-major.sh wp-update.sh from wp_ye_revslider_sliders where <code>type</code> != 'template' OR <code>type</code> IS NULL order by id ASC, ki jo je povzrou010dil/a require_once('wp-load.php'), require_once('wp-config.php'), require_once('wp-settings.php'), do_action('wp_loaded'), WP_Hook->do_action, WP_Hook->apply_filters, Cornerstone_Element_Front_End->register_shortcodes, Cornerstone_Plugin_Base->component, Cornerstone_Plugin_Base->loadComponent, Cornerstone_Element_Manager->setup, Cornerstone_Element_Manager->upgrade_classic_elements, Cornerstone_Element_Orchestrator->getModels, Cornerstone_Element_Base->model_data, Cornerstone_Element_Base->load_controls, CS_Revolution_Slider->controls, RevSliderSlider->getArrSliders, RevSliderDB->fetch

    Seems like Shipper isn’t able to update the changes in Cornerstone plugin, and the plugin seems to be calling old table structures. Since it’s a premium plugin it can have its own update structure, and it’s tough to say whether Shipper could make all relevant changes in the plugin side to reflect migration changes.

    I could notice there is a new plugin update for Cornerstone plugin, could you please update the plugin in the destination website, and see whether it makes any difference? Also, please do check other than Cornerstone plugin is other aspects of the website got migrated without any issue?

    I’m bringing these logs into our developer’s attention so that we could see what could be done in such use case.

    Will keep you postetd once I get further feedback regarding this from the developer asap. Have a nice day ahead. :slight_smile:

    Regards,

    Nithin

  • damyang
    • Flash Drive

    Hi!

    This could make some sense. It’s all about the famous X Theme, which uses its own page builder Cornerstone.

    The specialty here is that this theme needs to be activated. Its vendor use model: 1 licence = 1 production site + 1 staging site available. Both, production and staging if used, need to be activated to work properly.

    And here we come to the point, where problems using Shipper come to the surface, obviously. It makes some kind of a sense that Shipper is not able to change those stuff, because it messes with activation in a way, if you know what I mean. Maybe there will be no possible way out of this if X Theme is used.

    If I compare X Theme to another popular Divi Theme + Builder… Divi comes with unlimited site usage when bought where this shouldn’t pose a problem.

    I am thinking about workaround: maybe I should temporarily activate another Theme before using Shipper.

    If all of this turns out to be true, maybe you guys should check about this with theme vendor, since there will be lot of possible customers out there using this theme. If no solution will be possible, Shipper should have these kind of things on pre-flight check and stop / disable migration with correct reason.

    There are a lot of articles on the web containing subject like “The best and most popular wordpress themes of {year}” and this theme is on that lists for a few years now.

    I believe that updating Cornerstone will not help, since this need for updating came within last week, when site was already shipped. Because I’ve tried shipping for more than 5 times in a row and everytime with same issue, I guess there is nothing I or we can do at the moment, until your Devs will reverse engineer it or get in touch with theme.co / Apex (https://theme.co/apex/).

    Thanks!

    Damjan

  • damyang
    • Flash Drive

    Ahhh, I am sorry, because I wrote last reply without checking the site first. Only after that I realised that you managed to fix it working, but this time with errors you mentioned, which were actually really related to activation. I decided to go with the proper way and entered the address of staging site, activation was successful and everything is fine now (see attache screenshots). When I will decide, I will just switch DNS and job will be done. Excelent!!

    I am just interested in that did you do, that made it working this time (to the state with that activation error). Did you rename plugins folder and than reenabled again…? Thank you a lot!!

    Damjan

  • Nithin
    • Support Wizard

    Hi damyang,

    I decided to go with the proper way and entered the address of staging site, activation was successful and everything is fine now (see attache screenshots).

    Thanks for the screenshot, which gives a better idea. So, seems like the site URL needs to be 1st registered before activating the theme. That would explain the error.

    I am just interested in that did you do, that made it working this time (to the state with that activation error). Did you rename plugins folder and than reenabled again…?

    Yes, I renamed the cornerstone folder name, under:

    /wp-content/plugins/cornerstone

    To:

    /wp-content/plugins/cornerstone-off

    So, the website loaded fine. Since you were able to activate the plugin by adding the URL in the theme side, seems like everything is intact.

    The issue was mainly with the site not registered in X theme. Not sure how well we could do to prevent such issues to occur, however, I have brought this into our developer’s attention so that he could see what could be done in such use case too.

    Please let us know if you have any further query. Have a nice day ahead. :slight_smile:

    Regards,

    Nithin

  • damyang
    • Flash Drive

    Hello Nithin,

    yes, I think that the best procedure in this case would be, filling in / registering the staging site’s NEW address before Shipper is even run. I guess that everything would be fine though. I might give it a try.

    About what you (as WPMUDEV / Shipper) could do in this regard? I think that you should put additional info into pre-flight check.

    Something like a suggestion or warning or info to the user that one should pay attention if having such themes, which requires activation or special treatment. And than maybe link to some examples where the list of those themes will get bigger when more practical experience will come in. X theme would be the 1st one the list obviously :slight_smile:

    If there would be even a real check in sense of (IF THEME = X THEME or ?-THEME or ?-THEME …. THAN WARNING + SUGGESTION) that would be even more awesome. This “?” will get populated with time just to improve user’s and yours experience. This would be my point of view.

    Thank you for everything! I will mark this case as Resolved now.

    Cheers!

    Damjan

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.