Skip Navigation

[Resolved] Export and then import Toolset Forms > The XML file could not be read

This thread is resolved. Here is a description of the problem and solution.

Problem: I'm seeing an error when I try to import Forms using an export of Forms from another site. It says the XML file could not be read.

Solution: A character entity was breaking the XML parser. Update to the latest version of Forms to get the fix for this issue.

This support ticket is created 4 years, 6 months ago. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Sun Mon Tue Wed Thu Fri Sat
8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 - -
13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 - -

Supporter timezone: America/New_York (GMT-04:00)

This topic contains 8 replies, has 2 voices.

Last updated by takoL 4 years, 5 months ago.

Assisted by: Christian Cox.

Author
Posts
#1370729

I am trying to: export toolset forms from one of our sites and then import the toolset forms in one of our sites. This always worked. Since a few days, we get the following error message:

The XML file ( ... ) could not be read.

Is this a bug in the latest version of forms or is one of our cred forms corrupt?

#1371035

Hi, I'll be glad to take a look. I'm not aware of any open issues with Forms exports that would be causing this error. Is it possible for you to upload the XML document to Drive or Dropbox and provide a download link here? I'll take a look at the generated file and see if there is any obvious problem.

#1371039

Thanks in advance!

hidden link

#1371099
Screen Shot 2019-10-27 at 1.31.40 PM.png

I see some XML in this document causing problems. It looks like some of the Forms contain Modal elements, and the markup for those elements includes an HTML entity ×, which is breaking the XML document. I'm attaching a screenshot here of one instance of the × entity on line 961, but the entity can be found three times in the XML document.

As a quick fix, you can delete the 3 instances of that × entity and resave the XML file. Then replace that entity later if you want.

So the next question is did the Forms export system convert some characters incorrectly, or is the × text verbatim as it was written in your Form markup? Please check the modal markup in Form 1254 (from the original site), and let me know what text is included in the "Close" or dismiss button. Is it actually × or is there some other character being converted incorrectly? If you can copy + paste the code that would be helpful. I'll take a look and see if this is something we can address in a bugfix or by updating our documentation.

#1371117

Thanks for your answer!

Indeed form 1254 it contains the string '&times'. However, this form is a legacy form we do not use anymore but has been around for a long time in our exports which have worked up until recently. I have removed this particular string from all three forms containing it, and the import works after that. That would indicate that the latest version of the toolset forms code has changed the way it handles this (kind of) string of characters?

For your interest please find below the markup of form 1254. Maybe this can help you resolve

<!-- Button trigger modal -->
<a type="button" class="btn btn-primary btn-sm" data-toggle="modal" href="#assignTask">
<i class="fas fa-plus"> assign task
</a>

<!-- Modal -->
<div class="modal fade" id="assignTask" tabindex="-1" role="dialog" aria-labelledby="assignTask" aria-hidden="true">
<div class="modal-dialog modal-dialog-centered modal-lg" role="document">
<div class="modal-content">
<div class="modal-header">
<a type="button" class="close" data-dismiss="modal" aria-label="Close">
<span aria-hidden="true">×</span>
</a>
</div>
<div class="modal-body">
[credform class='cred-form cred-keep-original']

[wpv-view name="select-participant" view_display="layout" project="[wpv-search-term param='parent_project_id']"]

<div class="form-group d-none">
<label>Assignment Title</label>
[cred_field field='post_title' value='assigned' urlparam='' class='form-control' output='bootstrap']
</div>

<div class="form-group">
<label>Deadline</label>
[cred_field field='deadline' value='' urlparam='' class='form-control' output='bootstrap']
</div>

<div class="modal-footer">
<a type="button" class="btn btn-secondary" data-dismiss="modal">cancel</a>
[cred_field field='form_submit' value='Submit' urlparam='' class='btn btn-primary btn-lg' output='bootstrap']
[/credform]
</div>
</div>
</div>
</div>
</div>

#1371131

That would indicate that the latest version of the toolset forms code has changed the way it handles this (kind of) string of characters?
It could be a problem in Forms or in the export process, or a way in which data is handled internally across those processes. I will ask my 2nd tier support team and hopefully receive some feedback tomorrow. In the meantime, the string

&times;

...can be effectively replaced with the corresponding HTML entity...

&#215;

That should preserve the text output you already had in place in these forms, and not break the XML exporter / importer. I'll let you know what I find out as soon as possible.

#1373077

Our developers have provided an update. This issue will be resolved in Forms 2.5.3. I will keep you updated here as I learn more about the release schedule.

#1380967

Forms 2.5.3 is now available for download or automatic update. It includes a fix for this problem so that the entity...

&times;

...no longer breaks the XML import/export process. You can continue to use the workaround offered before, or you can use the entity above in the future. Please let me know if the issue is not completely resolved.

#1380985

My issue is resolved now. Thank you!

This ticket is now closed. If you're a WPML client and need related help, please open a new support ticket.