Changing default "<response>" and "<item>" tags in XML export

I would like this functionality as well. I have a client taking webform submissions and translating them to an XML feed they can import into their CRM, but if I'm unable to change the "<response><item>...</item></response>" format it doesn't do them any good.

I need a way to display XML format with the following structure:

<?xml version="1.0" encoding="utf-8" ?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title></title>
    <link>[link to xml]</link>
    <description></description>
    <language>en</language>
<slide>
	<title>[slide-title]</title>
	<startdate>July 18, 2017</startdate>
	<enddate>November 19, 2017</enddate>
	<time>11 am - 4 pm</time>	
	<location>[location here]</location>
	<description>TBD</description>
	<image>path/to/image/here</image>
</slide>
<slide>
	<title>[slide-title]</title>
	<startdate>July 18, 2017</startdate>
	<enddate>November 19, 2017</enddate>
	<time>11 am - 4 pm</time>	
	<location>[location here]</location>
	<description>TBD</description>
	<image>path/to/image/here</image>
</slide>
</channel>
</rss>

As you can see, besides being able to change the field tags, I also want to change the <item> tags to <slide> to group each item and <response> to <channel>

In D7, the xml version had the headers tags:

<?xml version="1.0" encoding="utf-8" ?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title></title>
    <link>[link to xml]</link>
    <description></description>
    <language>en</language>

available ... why isn't it included in D8?

I was looking for how to set or change the encoding. That would be helpful too in addition to changing the default XML tags.

Suscribing too.

I am trying to do the same. -- I used Views Data Export module for Drupal 7. it looks like it is not available for D8 now.

I am interested in this feature as well.
D7 you could define the root and item node. This feature doesn't not exist in D8.

Is it planned for future beta or RC release ?

I ended up creating a custom serializer.

Mostly based off the code sample from here: https://www.drupal.org/forum/support/module-development-and-code-questio...

Here are some other helpful links:
https://www.drupal.org/forum/support/module-development-and-code-questio...
https://www.drupal.org/docs/8/api/serialization-api

I've been digging into this because I need it to be "nodes"/"node" not "response"/"item". Using the tips in #10, I made my own serializer but wasn't sure what to put in it. I was hoping to reuse as much of the core one as possible and found that you can change the rootnode (see https://www.drupal.org/project/drupal/issues/2824837#comment-12353490 ) but "item" is hardcoded deep in there.

I also found that the core XML serializer might be going away in Drupal 9: https://www.drupal.org/project/drupal/issues/2926034

I'm not sure how to write this properly so just am going to cobble something together. Would be nice to see better xml support in the module, though.

Here is a patch that does this. It allows the following:

• Changing the root node name
• Changing the individual item node names
• Wrapping the items optionally with yet another node. This allows for use cases like

Ah, my markup from the third bullet was lost. It allows for use cases like:

<rss>
<channel>
<item></item>
<item></item>
</channel>
</rss>

Oops, forgot to set the new options in the defaults. Here we go.

It seems I forgot in batch exporting to remove the custom nodes added via configuration from the beginning and end of batch. Now it should be better.

Hi, I received the follow errors when I tried to patch with composer.
The issue came up with #12, #14 & #15.

- Installing drupal/views_data_export (1.0.0): Loading from cache
- Applying patches for drupal/views_data_export
https://www.drupal.org/files/issues/2021-01-16/2886357-14.patch (Changing default and tags in XML import)
Could not apply patch! Skipping. The error was: Cannot apply patch https://www.drupal.org/files/issues/2021-01-16/2886357-14.patch

[Exception]
Cannot apply patch Changing default and tags in XML import (https://www.drupal.org/files/issues/2021-01-16/2886357-14.patch)!

It's a great feature. Thanks !
Following !

The patch applies to the latest DEV version of the module, not the release 1.0.0.

thank you for the patch from #15, Upchuk
unforch it is not working for me ( Drupal 8.9.13, Views data export 8.x-1.x-dev)
I assume that you have checked a newer version of the XmlEncoder, where XmlEncoder::ROOT_NODE_NAME actually exists (in symfony/serializer 5 for example https://github.com/symfony/serializer/blob/5.x/Encoder/XmlEncoder.php), but in symfony/serializer 3.4 it does not exist https://github.com/symfony/serializer/blob/3.4/Encoder/XmlEncoder.php

Thats why I am using your patch with the slight change there and it works perfectly for me.

Cheers!

@Nikolay Borisov can you please provide an interdiff so I can see what was changed? Difficult to see otherwise.

sure @Upchuk.
Maybe you simply did it on Drupal 9. Apparently in the version 4.4 of the symfony/serializer compoenent the ROOT_NODE_NAME constant exists -> https://github.com/symfony/serializer/blob/4.4/Encoder/XmlEncoder.php (apparently introduced in version 4.2 of the component), where the version that is coming with Drupal 8 it is missing (simply check your version in the codebase where it is working with "composer show symfony/serializer" - in my case it was v3.4.47)

Cheers!

+++ b/src/Plugin/views/style/DataExport.php
@@ -322,7 +322,7 @@
+      $context['xml_root_node_name'] = $options['root_node_name'];

I would check if the constant is defined and do a fallback if not. Also, not sure why the tests are failing now.

@Upchuk I think it is a very good idea!
Here is a patch for that.

Hello,
the patch seems to work for me. Would like to have this functionality in this module.

Attached a patch that works on 8.x-1.0 version.

Seems good to me, thanks. Tested on Drupal 9.2 + Views data export 8.x-1.0

I am testing on Drupal 9.2 + Views data export 8.x-1.0
Only #25 is working for me but it's getting failed in test also it has missing schema for xml_settings, root_node_name, item_node_name, items_wrapper_node

Added updated patch to fix the test.

Re-roll the patch

Fixed formatting issue from patch #30. Also fixed #title attribute for item_node_name which was placed under items_wrapper_node as a duplicate #title.

The patch in #34 isn't enough to meet my requirements, I still need some more options. Please see desired XML output:

<?xml version="1.0"?>
<recall lang="en" xmlns="urn:recall-schema">
	<product_name>Thrifty Kitchens brand Ancient Whole Grains Salad recalled due to presence of stones</product_name>
	<date>2020-03-11</date>
	<id>63475</id>
	<country_id>CA</country_id>
	<product_type>Food</product_type>
</item>

What is missing:

• My exports are only for a single entity. I am using a view with contextual filter using nid. I need to remove the root node element so the item node becomes the root node.
• I need to be able to add attributes to the "root" node, in this case the item node.
• I need to be able to remove empty fields so if no data is available the element is not returned in XML.

New patch implements the required changes above, while still supporting requirements from previous comments. I tested this with both standard and batch methods and works as expected with any combination of the options enabled.

New XML options:

Patch in #35 works for me, thanks!

Patch in #35 works for me too, thanks!

But how can I set <?xml version="1.0" encoding="UTF-8" ?>
Maybe one more parameter as Root node attributes for xml element parameters?

Patch #35 works for even for the 8.x-1.1 release.
but what about this

PHP 7.4 & MySQL 5.7, D9.3 Skipped, branch did not pass for 4 weeks

?

#35 add extra settings but xml output by default is like:

<?xml version="1.0"?>
<response><item/></response>

How can I add this infos ?:

<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0">

Thanks

Added XML prolog encoding="utf-8" to patch #35

I have problem to apply patch #42

Get below messages....
Could not apply patch! Skipping. The error was: Cannot apply patch https://www.drupal.org/files/issues/2022-09-25/2886357-42.patch

[Exception]
Cannot apply patch Ρυθμίσεις παραμέτρων της εξαγωγής xml για το root-item (https://www.drupal.org/files/issues/2022-09-25/2886357-42.patch)!

Thanks Xperd, #44 patch works.

One more issue. The produced file is not optimized in tree structure (beautifier style) like other xml files. How can we achieve this?

Sorry styling of tree I think is problem of my editor as on Chrome works ok.

changes to improve functionality and code:

• I needed some more elements inside the root node, so I introduced an additional config field called "metadata" as a textarea
• also, I replaced the custom replacement of {{ lang }} by allowing the use of token in the attributes and metadata fields
• additionally I switched to dep. inj. where possible

still left to do:

• instead of strpos and str_replace, switch to a better way of manipulating the XML (i.e. using DOMDocument)

The code in #47 and in the MR need to be reconciled. It would also be great to add a batch export test for these custom xml tags.

The #47 has one issue.
If you open the settings of the data export format with enabled warning logging ($config['system.logging']['error_level'] = 'verbose';) you will get a warning "Warning: Undefined array key "metadata" in /var/www/html/web/modules/contrib/views_data_export/src/Plugin/views/style/DataExport.php on line 241".

I have updated the #47 patch to fix this warning.

Thank you very much the path #50 work well!

#50 works

how to add attributes to Item node name?
can this be done via the API?

#50 works also.

I would suggest to move the "Item wrapper node name" before "Item node name" configuration field.

Hello,

I am not seeing the drop down info for the xml settings. however, I do see it for the CSV settings.

#50 works

The XML configuration worked in my environment

#50 works +1. This patch is super handy for generating xml sitemap!

This looks great, and thanks for the hard work everyone, but this sort of change really should have some tests to make sure we're not breaking things for existing sites, and that the new settings work correctly etc. so setting back to needs work.

@steven jones Thanks for the feedback. Reading between the lines, it sounds like the minimum needed here might be a test confirming that the XML response remains unchanged with the new feature settings unchanged. That would help ensure existing sites aren’t affected. Does that sound like the right approach? (Noting there are currently no XML output tests.)

@steven jones I added a test as I suggested in #62 plus what it should look like with this change as well. It's super bare bones but maybe give you the confidence to commit?

Couple of notes:

• the new options weren't defaulted so I added some defaults unioned on to prevent
  

  Exception: Warning: Undefined array key "metadata"

  issues from showing up after commit.

• The previous version of this didn't have encoding="utf-8" so my test would likely fail in a test-only run. Though likely a good thing to have on XML so I didn't remove it from this MR.

Hiding patches to avoid confusion.

I reviewed the latest changes in the MR and tested them locally. Everything works as expected. The changes are minor, focused on code improvements, and include appropriate test coverage. I did not encounter any regressions or issues introduced by this patch.

Regarding the CSV and XML collapsible panes: when I expand these panes, collapse them, and then expand them again, they appear shortened as if they did not expand because only a portion of the content is immediately visible. The remaining content requires scrolling to view, which can be misleading. This seems to be a UX quirk, not caused by this MR, and likely a general issue in Drupal core.

Marking this MR RTBC. Thanks for the improvements and for adding test coverage.

Thanks @joelpittet for the work on this, and thanks everyone else for your continued patience with Views Data Export maintership!

Okay, so the code as it stands does have a few issues, specifically because of using string replacements to do some of the heavy lifting rather than an XML library. This reminds me of the famous stack overflow answer about parsing HTML with regex.

For example, at the moment I can set both the 'root node name' and 'item node name' to say 'response' and then use the new 'XML metadata field to add some more stuff in, and all that stuff actually gets repeated throughout the file, not only after the root node, as is the intention of the code.

I think there are a lot of sticky issues that we might need to sort out with this stuff, like the fact that it seems weird that you can inject arbirary non-valid XML into the middle of the XML document anyway. Seems like this is going to be super brittle going forward if this doesn't get done right.

I appreciate that the current batched export code also does string replacements, but I think that's another bug waiting to happen. Presumably you can't have a field called 'response' in a batch XML export, yes in fact, that breaks very badly at the moment!

I think what I'd like to do is:

1. Restrict the scope of this issue to the original report only, i.e. allowing someone to change the <response> and <item> tags.
2. Work on getting a test in for that functionality, which should be pretty easy tbh.
3. Get just those points committed and mark this ticket as done. This will give us a proper place to put options, the beginnings of the code that's currently in the MR anyway and add in custom handling for XML where we'll need it in the future anyway.
4. Replace out the current string manipulation of XML in the batched export with proper XML manipulations. This can be a new ticket that could be worked on separately.
5. Raise separate tickets for the other features introduced in this ticket, which is:
   • Removing the root node entirely (presumably only valid to do if there's only a single child node anyway.)
   • Adding attributes to the root node - This doesn't need to be done as a single text field, as the Symfony serializer actually has built-in support for doing these already, so we could provide nice escaping etc. and not do simple broken plain string swaps.
   • XML Header (the metadata) This seems like a bit of a weird one to me, but I understand that there might be some use-cases out there that would want to add some arbitrary XML to the root node of the file. Again this should get added via the XML encoder if possible, but maybe having big warning messages all over this entry field that you're likely to break things unless you know exactly what you're doing, then maybe it's okay.
   • Removing empty values from the output.
   • Adding an extra wrapper with an arbitrary name.
6. Encourage others to work on those tickets/get them committed in a timely way.

Sorry if that sounds super annoying / convoluted, but I think rather than hold up some of these features because they aren't all ready, it makes sense to split them out.

I'll make the other tickets in moment, and we can refocus the work here to be back to the original issue.

Sort of tempted to remove the cheeky addition of the encoding="utf-8" bit, and then the changes here really will be absolutely minimal and could get merged right in.

I recommend keeping encoding="UTF-8" in there — it ensures correct character decoding, avoids cross-platform inconsistencies, and even if XML parsers are required to assume UTF-8 by default, it’s still best practice to include it explicitly.

@joelpittet yeah, agreed, I think it should almost always be in there, but I don't want to break something random in someone's export, so I think I'll punt that change to #3522528: Allow specifying the XML encoding property and maybe we can make it the default for new installs or something like that.

You happy with the code otherwise?

Thanks everyone for your patience, I'll note that I'm committing a partial version of what was in MR!75, so if you're using all the features of this MR/patch then you might want to stick with that until all the sub issues of #3522419: [META]Make XML output more configurable are in, and then upgrade to the version of VDE that has those in.