We are starting the work on Export Import functionality, which is a top request by the community (see: here and here).
It will allow you to export selected content, pages and page templates from Sitefinity and import it:
In the first iteration, we will focus on Content, and envision interface similar to the one here.
We will need your input on how you plan to use this feature.
What are the problems it will help you solve?
Let us know and we'll take this into account during the implementation!
I would like to know if this functionality is only for enterprise editions, as recently all interesting functionality is for EE only.
This feature will be for all editions! We look forward to seeing your use cases here !
Will this always be done in the context of a specific site (in the case of multi-site)? I'm curious this could be used to export content from "Site A" in a multi-site instance, and then import the data into "Site B" in the same multi-site instance? Something like that isn't possible with SiteSync since the content IDs would be created the same and cause conflict.
This feature is definitely helpful for our multiple global team environments. One feature i might request if not available is: can you pick the specific content that you want to export. Like pick only the content block items that i want to export instead of all content block items. I do not see that in the url: sgwtlh.axshare.com/
@Daniel oh good point! Regular editions keep getting new feature hosed. @kali What of merge conflicts... And linking in related data and taxa?
This is great.
It would also be great to be able to import non-Sitefinity data files into Sitefinity.
For example, the ability to import data from an excel / access / csv / tsv / xml / sql table (w/ connection string + sql query), then be able to map the fields to the Sitefinity data type would be great. Right now, we typically have to write custom import scripts to accomplish this.
Something like this?
1. Choose a content type: events, news, dynamic types, etc
2. Upload file: excel / access / csv / tsv / xml / json etc
OR connection string and sql query
3. Map fields: go through each field in data type and match it with a column in the uploaded file.
4. Review: show what first 5 rows looks like so the person uploading can ensure there aren't mistakes
6. Show results
Additionally, it would be great if the import / export process could be scheduled to happen on a daily, weekly or monthly basis w/ an email notification w/ the results.
So am I missing it, or there's no import of content?...
(btw the structures Export\Import seemed to work great)
Work is in progress on the export/import feature. We expect to include it on our next release.
Based on your questions and comments, we created a short survey to ask you about the way you'd like to use the data export/import functionality in Sitefinity.
It is available at https://www.surveymonkey.com/r/3KQL7WZ and contains only 10 questions, so please spend a minute to fill it in.
Many thanks in advance!
Are there any plans in the future to tame the beast that is the configuration files stored under app_data/Sitefinity/Configuration?
It doesn't make sense to me why so much data is stored in these configs. To me, only environment-specific variables, like those found in DataConfig.config or SiteSync.config should be stored there. Everything else, such as Dynamic Modules or custom fields on existing modules is really content and content structure, and should be stored in the DB. In addition, this data should sync with the new site sync feature.
Having to keep these files in sync between developers, dev ops teams and site sync is a massive burden!!
Also, given the current state of config management, why hasn't there been any documentation written on how to handle working with these configs between different teams and deployment environments?
You can choose to enable storing the config in the DB, it's always been an option, but filesystem has been the default.
We used to use DB config, but switched back... the ability to checkin\checkout the config files, and editing through Visual studio far outweighs keeping things in sync through the DB.