Imagine there was a way to enter content on one Drupal website and have it automatically appear on another. Suppose you could just as easily send it to five, or for that matter a hundred other sites if you wanted, and on each one it could be edited or deleted just like you’d entered it manually…
Okay, maybe it’s not that romantic after all. But assuming this site-to-site transfer of content is something you’re after, you can stop imagining and start building using the instructions below.
Real world use case: A client of ours has three Drupal sites, each managed by a different administrator who adds news stories to his or her own site. In order to make the most of their content, they want to be able to share some stories between sites, but each administrator needs to have control over whether any particular story is published on his or her site.
Alternate use cases: In addition to sharing almost any kind of content between two or more sites on an ongoing basis, you could also use the setup below for a one-time content migration. If the thought of eliminating hours of dull copying and pasting doesn’t get your blood pumping, stop reading here and consult your therapist.
Part I: Set up an outgoing feed using Views on Site A
1. Enable the Views and Views Data Export modules on Site A.
2. Create a new view to aggregate the content that you want to send to Site B. In our case, this was just a view that displayed published nodes of the ‘News Story’ content type.
3. Create a new display, but instead of choosing ‘Block’ or ‘Page’, choose ‘Data Export’.
4. Add a path for your new display, just like you would for a page display.
5. Change the format of this display to ‘XML file’. Note that you won’t actually be creating a file unless you check the box next to ‘Provide as file’ in the settings. DON’T check this box—you want to create an XML feed, not a downloadable file.
6. Add all the fields from this content type that you want to pass on to site Site B. If it’s just the title and body fields, great, but you can also add more complex ones like the author or date. In any case, make sure that you keep the labels on each field (you’ll need these when reading the feed to figure out which field is which).
7. (optional) If you want to get really fancy and send an image, you’ll have to add the URL of the image since the image itself won’t show up in the XML output. One way to do this is to first add a relationship to the attached image (‘File Usage: File’), and then use this relationship to add the URL as a field (‘File:Path’). If you can’t get that working, you could also use the Image URL Formatter module.
8. Save the view and go to the path that you set up in step 4. If you see some XML gobbledygook that looks like it might have the fields you just added, you’re in good shape.
Part II: Set up a Feed importer and Feed Processor Node on Site B
For this part, follow the Xpath module documentation to create an XPath feed importer and feed processor. The instructions are reasonably good up until about step 7 or 8, at which point they become practically unintelligible. Ah, the joys of open source documentation. I’ll try to fill in here as best I can:
Once you have your importer set up, you need to create a new feed processor node (as described in roughly step 7 in the link above). In their example, this is just a new node of the ‘xml job feed’ content type. In our example below, the content type is just ‘feed’.
In the title field for this new node, put whatever you like. In the URL field, put the path of the feed that you created on Site A (see Part I, Step 4).
So far, so good. Next, click “XPath Parser settings” (right below the URL field) to expand it. This is where you determine which fields from the XML feed correspond, or “map”, to which fields on the imported nodes. You need to use XPath syntax, which you can read more about here. Better yet, since your XML was created by the Views Data Export module and should look almost identical to ours, just take a look at the example below and tweak as necessary:
The trickiest part about this is the ‘Context’ field, which essentially tells the feed processor where to look in the XML for the other fields— in our case, inside the <nodes> tag, and then inside each <node> tag. The other three fields determine which XML data should be used for each field on the new nodes. For example, the data inside the <image-url> tag in the XML will be mapped to the ‘field_image’ field when a new imported node is created.
One final interesting note: while we initially assumed we’d have to map the image URL field to a plain text field, it turns out that’s not the case: if you map it to a file upload field instead, it works just fine and actually imports the image for you. If only the rest of the setup were this easy!
Part III: Import!
1. Click the ‘import’ tab on the feed processor node you created in Part II.
2. Sit back and enjoy the fruits of your labor. Once you’ve got it working, you can turn on “Periodic Import” on your feed importer and set this up to happen on its own in the future.
* It’s possible to avoid the XPath parser module altogether by using CSV (comma separate value) format instead. The downside is that you’ll lose all your HTML formatting in transit because that data export module’s CSV setting strips it out—if this is unacceptable, you’ll have to stick with the longer (but more rewarding) route described above.