Importing & Exporting Nodes with Neos

Wondering how to use the site import / export features during development and while delivering / maintaining a project? Do you have the need to import content from various sources into your brand new Neos project?
These slides give you an overview of how to get the most out of the import / export commands and will show you how an import of content can be done through code in various ways.

Transcript

1. Importing & Exporting Nodes with Neos
2. Karsten Dambekalns Neos and Flow developer 37 years old lives in Lübeck is a Flownative 1 wife, 3 sons 1 manual espresso maker likes canoeing & climbing
3. Where is my data?
4. A node is the smallest unit in which Neos stores content. A node can represent a document or pieces of content on a document, so nodes can be nested. Node
5. The content repository is the storage for all nodes. Content Repository
6. Database The content repository uses a regular relational database to store nodes and their properties. Actively dealing with that should be the exception to the rule.
7. Site package In Neos the site package acts as a container for all assets a site needs and can also contain the site content.
8. Sites.xml Site content can be exported to an XML file in the site package or elsewhere. That file contains the structure, content. Used assets of a site can be contained there or be exported alongside.
10. Common Tasks
11. Import freshly kickstarted site
12. $  flow  kickstart:site  -­‐-­‐package-­‐key  Neos.Sprint   -­‐-­‐site-­‐name  'Neos  Sprint  Nuremberg'   Created  .../Sites.xml   Created  .../Root.ts2   Created  .../Default.html   Created  .../NodeTypes.yaml   $  flow  site:import  -­‐-­‐package-­‐key  Neos.Sprint   Import  of  site  "Neos  Sprint  Nuremberg"  finished.
13. Export to the site package
14. $  flow  site:export  -­‐-­‐package-­‐key  Neos.Sprint   All  sites  have  been  exported  to  package   "Neos.Sprint".
16. $  flow  site:export  -­‐-­‐tidy  -­‐-­‐package-­‐key  Neos.Sprint   All  sites  have  been  exported  to  package   "Neos.Sprint".
18. Use the tidy option if you want to be able to read diffs between states.
19. Export to standard output
20. $  flow  site:export  -­‐-­‐tidy  >  site-­‐export.xml   $  flow  site:export  -­‐-­‐tidy   <?xml  version="1.0"  encoding="UTF-­‐8"?>   <root>    <site  name="Neos  Sprint  Nuremberg"  state="1"   siteResourcesPackageKey="Neos.Sprint"   siteNodeName="sprint">      <nodes  formatVersion="2.0">        <node  identifier="d8d4ae92-­‐53e0-­‐ ef20-­‐9d5e-­‐6fd5578c9713"  nodeName="sprint">          <variant  sortingIndex="100"  workspace="live"   nodeType="TYPO3.Neos.NodeTypes:Page"  version="1"  
21. Export to a file
22. $  flow  site:export  -­‐-­‐filename  site-­‐export.xml   All  sites  have  been  exported  to  "site-­‐ export.xml".
23. Export to a package or file to have resources exported to individual files.
24. Multiple site exports
25. Why would you need more than one site export in a project?
26. Showcase available node types.
27. Provide a fixture for automated testing.
28. Have a “demo site” giving an impression of how the final site could look like.
29. Deliver base structure for a site to the client. Removal of nodes is not supported, import only adds/updates currently.
30. $  flow  site:export  -­‐-­‐filename  site-­‐base.xml   All  sites  have  been  exported  to  “site-­‐base.xml".   $flow  site:prune   All  sites  and  content  have  been  removed.   $flow  site:import  -­‐-­‐package-­‐key  Neos.Sprint   Import  of  site  "Neos  Sprint  Nuremberg"  finished.   $flow  site:import  -­‐-­‐filename  base-­‐structure.xml   Import  of  site  "Neos  Sprint  Nuremberg"  finished.
31. Creating content through code
32. Warning: Only some user serviceable parts inside
33. Option I Generate XML
34. Option II Create nodes in PHP
35. Generating valid node names use  \TYPO3\TYPO3CR\Utility;   Utility::renderValidNodeName($name);
36. Use NodeTemplate $tpl  =  new  NodeTemplate();   …   $node  =  $parent   -­‐>createNodeFromTemplate($tpl);
37. Handle node variants in all workspaces in case an editor has modified it and not published it yet. Otherwise the data gets overwritten again when the editor publishes.
38. When importing, re-use existing tooling.
39. This will avoid memory and performance issues by batch processing.
41. Generate a lot of nodes for up-front testing, to see how the system will perform when you imported in the end.
43. Import performance
44. When using the Node API performance issues will come up eventually.
45. You may need to use NodeData directly.
46. Do not get used to working with NodeData. While needed for fast and memory-conserving imports, it is not public API and should be used with great care.
47. Be prepared to handle things like updating the node index, flushing the content cache and setting uriPathSegment manually.
48. Option III Do not import
49. Fetch content on-the-fly If you can fetch (some) of the content from an external source, like Redis or Elasticsearch, you could just use an Eel helper in TypoScript to pass it to the rendering. No “real” nodes, but still cached in the content cache, hence fast.
50. Option IV Content Object Proxy
51. Use content objects If you have your data in some Flow application anyway, or it makes sense to have it as entities, you can add a content object to a node. The node acts as a proxy to the entity, exposing its properties.
52. Questions? Ideas?
53. karsten@flownative.com www.flownative.com @kdambekalns share your thoughts
54. www.flownative.com