This is what host gator came replied back to me with.... Let me know if this makes sense or other options for smoother importing on Host Gator shared servers.. Thanks
Thank you for contacting Hostgator Support!
We would be happy to assist you with this. I have reviewed this issue for you, and thank you very much for the excellent replication video. By repeating your steps, I was able to reproduce the error, and observe the execution of the code. The problem here is that the import script is running as a single php process, and is taking too long, causing it to be killed by the php execution time limit.
It's not possible to increase this execution time on a shared account like this, but most import scripts circumvent this problem by "chunking" the import, and using ajax calls to import chunks of the data at a time, each chunk in an individual PHP process which starts and finishes quickly.
To get around this, there are three possible options: 1. Try running the same import repeatedly. This is a long shot, but if the script's code checks for pre-existing files, it may skip the ones it already has and keep importing the new ones with every attempt. Again, this is unlikely to work, but if it does, you've got your data. 2. Import the data manually, if the theme provider offers those demo packages separately. 3. See if the developers have version of the importer that operates in chunks, rather than a single import process.
Regarding the fact that it works on other servers, there are too many variables to determine why it may be working differently. The problem is conclusively the fact that it's running out of time, so anything that slows down the import may put it over the line if it's close. It could be that their servers are under higher load now than they were before. It could be that some plugin or something about this code is injecting actions into the update process that cause it to take slightly longer. The size of the sample data could have grown, etc.
If you have any further questions or concerns, please don't hesitate to let us know.
So everything is clear now. Your current hosting is just incompatible with wp_remote_get() which uses loopbacks of course but is a default WP function. If you want to import all demo data like: content, images, menus, widgets, etc, loopbacks are necessary and this can not be jump. Of course we have possibility to import all data manually but even that thing does not work in some cases.
We don't want to recommend any because in the same hosting company might do not have those limits while the other one would have because admin decided to share server between to many users to get better profit. We can just tell you that many of BeTheme users use hosting services like: MediaTemple, GoDaddy and OVH for example.
Comments
We would be happy to assist you with this. I have reviewed this issue for you, and thank you very much for the excellent replication video. By repeating your steps, I was able to reproduce the error, and observe the execution of the code. The problem here is that the import script is running as a single php process, and is taking too long, causing it to be killed by the php execution time limit.
It's not possible to increase this execution time on a shared account like this, but most import scripts circumvent this problem by "chunking" the import, and using ajax calls to import chunks of the data at a time, each chunk in an individual PHP process which starts and finishes quickly.
To get around this, there are three possible options:
1. Try running the same import repeatedly. This is a long shot, but if the script's code checks for pre-existing files, it may skip the ones it already has and keep importing the new ones with every attempt. Again, this is unlikely to work, but if it does, you've got your data.
2. Import the data manually, if the theme provider offers those demo packages separately.
3. See if the developers have version of the importer that operates in chunks, rather than a single import process.
Regarding the fact that it works on other servers, there are too many variables to determine why it may be working differently. The problem is conclusively the fact that it's running out of time, so anything that slows down the import may put it over the line if it's close. It could be that their servers are under higher load now than they were before. It could be that some plugin or something about this code is injecting actions into the update process that cause it to take slightly longer. The size of the sample data could have grown, etc.
If you have any further questions or concerns, please don't hesitate to let us know.