Export Import Module
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!
Regards,
- Kalina
Hi Kali,
I would like to know if this functionality is only for enterprise editions, as recently all interesting functionality is for EE only.
Thanks,
Daniel
@Daniel oh good point! Regular editions keep getting new feature hosed. @kali What of merge conflicts... And linking in related data and taxa?
If it is to be only standard in EE, It would be nice if it could be made available as an extra-cost add-on, like Site Sync.
Hi all,
This feature will be for all editions! We look forward to seeing your use cases here !
Thanks,
- Kalina
Kali,
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.
Hi
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/
Regards
-Harish S
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
5. Import
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.
@Kali,
So am I missing it, or there's no import of content?...
(btw the structures Export\Import seemed to work great)
Hi Steve,
Work is in progress on the export/import feature. We expect to include it on our next release.
Regards,
- Kalina
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!
Mariush
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?
@Adam
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.
Thanks, Steve.
IMO, the db config option would be nice for some, but not all config files. I don't understand why, when I create a new custom field on a page, for instance, a config file needs to change. Shouldn't that change just sit in a table somewhere in the DB?
Also, even with db config, those values don't get synced with site sync. Having to tell managers that we need to re-deploy the configs just to sync a new dynamic module between environments is not a fun conversation to have, lol.
I don't disagree with you :) ...I don't trust a "sync" as far as I can throw it either. Got borked early on using the "Migration" tool from 3-4 and so many things were gimped, never ever going to do it again.
[quote]Adam said:
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?
[/quote]
Hi Adam,
You are raising an absolutely valid point. The quick and short answer to your questions is: YES! We are going to introduce a new configuration storage mode that splits the configs between file system and the database in order to avoid the pain of keeping configs in sync.
This feature has been designed with Continuous Integration and Continuous Delivery in mind and I'll shortly share more details about it.
Thanks, Mariush. That is great news!
Related to this, I wanted to ask a question about Site Sync and configs:
We are on 9.1.6119.0 and are seeing discrepancies in the documentation regarding site sync and config files. We are able to create and new dynamic content type and module in the source site and then sync that module to the target site just fine. It looks like both the target and the source site's config files get updated just fine.
So, is the documentation outdated for this version? And, given that the configs get updated on the target with respect to dynamic content, what other configs get synced or don't get synced with this version? (We're a little confused :) )
[quote]Adam said:
So, is the documentation outdated for this version? And, given that the configs get updated on the target with respect to dynamic content, what other configs get synced or don't get synced with this version? (We're a little confused :) )
[/quote]
DynamicModules are included in the supported types, this also assumes whatever is needed for them to work properly like their configs.
About other configs that we sync, you can have at the synchronized settings section.
At first sight, I couldn't find a discrepancy, so please specify what's missing or could be better documented from your perspective.
Hi Mariush,
I apologize for my confusion. It looks like the part that confused me was the docs on the prerequisites (docs.sitefinity.com/prerequisites-and-restrictions). I now see that the configs have to be the same just prior to setting up site sync.
However this line at the bottom is a little confusing to me:
"IMPORTANT: When creating a new module, if you have multisite license, you must manually synchronize the dynamicModuleConfig.config files on the source and the destination servers, prior to the synchronization."
Is this still needed when trying to sync new dynamic modules?
[quote]Adam said:
However this line at the bottom is a little confusing to me:
"IMPORTANT: When creating a new module, if you have multisite license, you must manually synchronize the dynamicModuleConfig.config files on the source and the destination servers, prior to the synchronization."
Is this still needed when trying to sync new dynamic modules?
[/quote]
Indeed, this piece of information is outdated and we will remove it from the documentation for the latest versions. Thank you very much for pointing it out!
[quote]Adam said:
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?
[/quote]
As mentioned earlier, we are working on a major improvement to this that will allow you to use proper continuous delivery process with Sitefinity. You can read about this in a separate forum post.