The next Sitefinity release will include numerous improvements in the Site Sync functionality
We will focus on issues from support and on popular requests from the Feedback Portal:
What were the major pain points/missing features you encountered in Site Sync?
We will attempt to address all submission and provide a resolution.
+1 to Matt's and Jonathan's suggestions.
Below are mine:
Allow multiple users
to be able to schedule independent sync jobs simultaneously. For instance:
At 1pm User 1 schedules Page 1 to be synchronized at 3pm
At 1pm User 2 schedules Page 2 to be synchronized at 3:15pm
At 1pm User 3 schedules Image Library 1 to be synchronized at 3pm (the
system may automatically adjust the time if it conflicts with an existing task)
3pm User 4 schedules Page 4 to be synchronized now (this
conflicts with the sync task of Page 1 already scheduled for 3pm, so the
system will automatically put this task in the queue and execute it when the
other task finish)
The UI should show all current scheduled tasks ordered by time and by different
2. Implement auto-retry of failed task – sometimes the
target servers (as they are live / public servers) are busy with public traffic
and the Sync requests time out. It would be good if SiteSync could auto-retry
the task after a certain period, e.g. 5 minutes. Otherwise the user has to
manually schedule the same content for synching and they are doing this (sync
content to live) all day long.
3. Email notifications on site sync task completion would be nice.
4. I think right now there is an issue with versioning:
Scenario: I edit page A at 12pm and schedule a sync task for that page for 3pm.
Someone else comes along and changes page A at 1pm and schedules it to be
synced at 4pm.
The current implementation will take the latest published page and sync that.
So the page that I wanted to sync at 3pm will now contain the changes someone
else made at 1pm.
I guess this is something that could be avoided by Publish at a certain date
time, but that is a very restricted solution.
on the geo-located scenario, do you use forms ? and does the load-balance takes care of split form submissions / aggregate all in one single place ? (some submissions on server A, others on server B, others on server C)
Thank you all for the valuable feedback!
Can you give us example of how you would use syncing of configuration? Is this part of deploying new functionality from staging to production? If so, would you mark some areas of configurations which should not be synced?
We are planning to add syncing per site.
We will also look into the option to sync to more than one server at a time.
We will try to address all your suggestions.
Let us know if you come up with more ideas and suggestions!
+1 for this one as well:
Currently there is no way for the user to Sync labels to the live servers. Business users should ask IT to manually copy the .resx file to the live servers, which is not always feasible.
Note: SiteSync can sync image libraries that are stored on the file system, so it should have no problems synching resx files from the file system as well.
I would like to point to this discussion here:
We have a similar issue where we want to sync Config Files, particularly for Dynamic Modules. Yes, we would like to choose which Configs we want to be synced. We want to move these Config files in the DB but we can't until we know Site Sync would also look after syncing configs stored in DB.
+1 to the idea of syncing resource files. Additionally, being able to sync Site Search indexes would be great too.
Would love to start seeing better error messages. Currently, we have over 7 sites that we sync. When there is a failure for a page for example, we can't tell what particular site that page didn't sync for. We often have to check ELMAH logs on the destination server to see a more relevant error message. The Site Sync results page and the ELMAH logs on source server don't give us a better idea of why something failed.
Let me share more details on the planned improvements for Site Sync:
Scheduling Multiple Site Sync Tasks
You can see version 1 of the wireframes here.
In Multisite mode, there will be different sync tasks for the different sites.
In Multisite mode, they will be able to filter by site.
The above will extend the usage of site sync and will give greater visibility on future and past syncs.
Improvements will include:
We will have numerous fixe as well including the ones reported on the feedback portal:
Let us know of your feedback and comments.
Thanks for the ideas!
@Bart - sounds good but unfortunately there are no plans for creating groups during sync as it will be pretty complex.
@Matt - It is reasonable. We'll try to provide appropriate error message.
We've heard your requests and we are going to provide a synchronization for Search Indexes, Labels & Messages (Resources) and Configurations and all those items are stored by default on the file system (in different folders). So we want to ask all of you some questions:
We'll be glad to hear your experience on this.
More details on NLB and AppData folder could be found in the official documentation.
Thanks again for the feedback.
To answer your questions:
1. Currently no, we do not use NLB, but we will in the near future.
2. Configs are on the file system, but we do not do much changes there. If any - they will be manually synced between the servers.
On another client, we have NLB and Distributed File System Replication setup on the App_Data folder so it replicates automatically between the nodes on Azure.
1. Yes, we use NLB.
2. At the moment, its a custom built solution to sync the contents of the folder but what we want to do ideally is to store the Configs in DB.