Save 37% off PRO during our Black Friday Sale! »

Importing & Exporting Nodes with Neos

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.

Ecfb276920529fc9b924ad4a0877d9ce?s=128

Karsten Dambekalns

July 18, 2015
Tweet

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.
  9. None
  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".
  15. None
  16. $  flow  site:export  -­‐-­‐tidy  -­‐-­‐package-­‐key  Neos.Sprint   All  sites  have

     been  exported  to  package   "Neos.Sprint".
  17. None
  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.

  40. None
  41. Generate a lot of nodes for up-front testing, to see

    how the system will perform when you imported in the end.
  42. None
  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