I am attempting to migrate changes in Views, Templates, Forms and Layouts from one site to another. I have used the export function in Toolset on the source site and haven't had any issues importing all export files, with the exception of Views.
I have verified that the version of all Toolset plugins are the same on both sites, but when upon attempting to import views, I get an error like the following:
Failed to import Content Template attachment - loop-item-in-search-company-seamen
When this error occurs, Content Templates fail to import fully. I have attempted to take out the offending view and template in the source XML, but then I just hit another similar error.
I can provide a copy of the import file and access to a cloned version of the offending site if that helps.
Hello and thank you for contacting the Toolset support.
Yes, please share the export files and allow us access to the cloned site. Your next reply will be private to let you share credentials safely. ** Make a database backup before sharing credentials. **
Hello Brandon, and thank you for sharing this staging site and the export files.
I believe that the issue is caused by a server restriction instead of an error from Toolset. For two reasons:
- The import finishes successfully in my local setup. Check this screenshot hidden link
- On the staging site, if you run the import again, the content template that was not imported, will be imported and the process will stop on the next content template in the export file.
In my local setup and based on the Health check data from WordPress, it seems that I have fewer resources than you staging site. But the import completes successfully in my local install:
- Local: hidden link
- Staging: hidden link
My local setup does have larger max_input_vars, but I don't think it is relevant in this case, as we only send one file.
In the staging site, I first run the import and it stopped on a content template. I extracted the XML file and tried to see if it is causing the issue, so I have removed some information from the content template where the process stop(HTML comments, HTML attributes that contain ":" such as style or javascript in href). And I was performing the import each time from the updated XML file. Then I realized the import completes the failed content template and stops on the second without having to change the XML file.
At this point, I suspect that the server is configured to restrict resources even if it does not look so from Health check data hidden link
I'll suggest that you run the import on another server or in your local development environment and see if it will finish correctly or not. If it finishes correctly, you will need to ask your hosting provider about it. I suspect that there is some hidden restriction.
I hope this helps. Let me know if you have any further questions.
Today I created a brand new server. No other resources/sites running, just this test site. I've ensured that the parameters around php/php-fpm (time limit, mem limit, post size, etc) all have more than enough provisioned.
Environmentally, it's being fronted by nginx, instead of OpenLiteSpeed. I switched these over incase OpenLiteSpeed was doing something funning in the pipeline request. I also ensured nginx was configured for ample request payload from the client.
At the end of it all, it made no difference. The same type of error still presented.
As you can see here: hidden link
My health parameters are shown here: hidden link
Forgive me for asking, but clearly there is an error here and there's just not any debug information to suggest as to why it failed that comes from this Import feature. Simply saying it's "failed" is not useful at all.
I am not convinced that there is "some hidden restriction" as you've suggested. It's just a standard Ubuntu 20.04 install, with nginx & mysql with PHP configured correctly for processing large postback data. I would have been keen to see some deeper debugging of your plugin to determine the root cause of the "failed" message.
Hello Brandon, I understand your point of view. And I would be more than happy to debug this if only I could reproduce it.
Yesterday, I tried in my local setup. Today, I created a new installation in our online platform on CloudWays. It is a shared server that we, supporters, use from time to time. The import of the views has completed successfully hidden link
Just to be sure, I imported the views file again by overwriting the existing elements hidden link and it finished successfully hidden link
You can try it by your self using the following credentials: hidden link
Toolset / toolset@support
Are you not able to login to the site I provided for you along with the export files and the File Manager on the site to debug the underlying reason why it may be failing? That may help highlight what it may be about the server images being provided by our hosting provider?
So we are using Vultr for server provisioning and have tried it on Ubuntu 18.04 running OpenLiteSpeed and Ubuntu 20.04 running Nginx. Yet the same problem. I can confirm that your site imports fine.
Could I ask which cloud provider you provisioned your CloudWays instance with and what the general specs were of that instance? (OS, CPU & Mem)?
Our servers on the CloudWays platform are usually 1Gb memory. I think that it is the first offer here hidden link
I added a line of code to the views plugin to log the error that occurs on your server. Check this screenshot hidden link
And it logged the following error:
[08-Feb-2021 15:58:27 UTC] Failed to create Content Template WP_Error Object
(
[errors] => Array
(
[db_insert_error] => Array
(
[0] => Could not insert post into the database.
)
)
[error_data] => Array
(
[db_insert_error] => The user specified as a definer ('9t1xVragBmp4Yt'@'localhost') does not exist
)
)
Getting closer now. I'm starting to now think this is a DB issue. There may be nuances with sql client syntax as the source site run MariaDB 10x and the destination DB is MySql 8x.
Interestingly though, I cannot determine how it picked up the username ed as a definer 9t1xVragBmp4Yt. I searched the import files and all files from the root of the site and couldn't be found anywhere. So not sure where this comes from. It may be somewhere in the schema data deep in MySQL.
The link to the SO article you provided unfortunately didn't really assist, but it did make me think. Personally I have been using mysqldump command line tool for backing up the database. This dump has been decorating some database triggers we have configured and set's the context to run under '9t1xVragBmp4Yt'@'localhost'
I believe this was the first problem. Deleting the triggers and running import, the error Could not insert post into the database
Once that was corrected though, I started getting the error Failed to import content template attachment. It seems to go through a validation using the function media_handle_sideload() and that was failing. I'm guessing here that it's taking the encoded data block for these images from the import xml and for whatever reason can't validate this data.
Solution at this point is to remove the attachments from the xml and manually copy over these attachments/files, or what I have done for now is simply commented out this check at line 1004 of the PHP file you put the debug line in:
This will have to do for now. I do believe we have two separate issues going on here and it may just be something bundled in (or not) with Vultr's base images.
At this point, I'm happy to close this. Appreciate your attempt to solve this.
Thank you Brandon for this feedback. I'm really glad I could help. So, I'll kindly ask you to mark this ticket as resolved and open a new ticket if you have any further questions or you want to discuss another point.
