5

Resolved

Search settings being incorrectly overriden when saving site settings

description

When saving general site settings, the search settings are overridden with null values. I'm using the latest commit (0a097fe7b0c1) from the 1.x branch.

Steps to repro:
  1. Create a search index then go to the search settings page and select it.
  2. Click on the Settings link to open the general settings page and click save.
  3. Go back to the Search settings page. The search index you selected in step 1 is no longer selected.
I stepped through this in the debugger and found that in the SearchSettingsPartDriver the model is not being updated with previously saved values during the call to TryUpdateModel. This is causing an empty model to be saved which effectively overwrites any previously saved search settings.

I'm wondering if this is a more pervasive issue too. I looked at the SearchSettingsPartDriver history and found no recent changes that account for the issue so I'm wondering if it's happening for other setting parts attached to the Site content item.

comments

joshby wrote Feb 14 at 3:35 PM

I can repro the issue on 1.7.2 as well. I'm surprised no one (including myself) has run into this before.

Piedone wrote Feb 21 at 11:19 PM

This is also affecting SmtpSettings.

Duplicate: https://orchard.codeplex.com/workitem/20506

Piedone wrote Feb 21 at 11:20 PM

Also happens on 1.x.

jao28 wrote Feb 25 at 4:37 PM

For what it is worth I have observed that ANY settings connected to site settings which utilize a ViewModel (i.e. don't directly use the part as a model) will lose all their setting when any other settings connected to site settings are updated. Unfortunately, the "TryUpdateModel" succeeds when updating a ViewModel. However, it just sets the values to "Null" since the viewmodel names hardly ever match up with the part names and the part names are all that actually exist. So, search settings are getting overridden every time.

The "hack" fix for this is to do this in SearchSettingsPartDriver.cs Editor method:
// submitting: rebuild model from form data
if (updater.TryUpdateModel(model, Prefix, null, null)) {
    // update part if successful
    // Because this gets triggered with every part connected to site settings, need to ensure we are only updating when on the same model 
    //  In this case I am testing that the SelectedIndex is set, this is a true hack as you need to know a "primary" field to check for it to work
    if (!String.IsNullOrEmpty(model.SelectedIndex)) {
        part.SearchIndex = model.SelectedIndex;
        part.SearchedFields = model.Entries.First(e => e.Index == model.SelectedIndex).Fields.Where(e => e.Selected).Select(e => e.Field).ToArray();
        part.FilterCulture = model.FilterCulture;
    }
}
Again, this is a complete hack as not every setting has a key field. Really needs to be a means of overriding "TryUpdateModel" to see if the Prefix even exists in any of the Keys before proceeding to updating when you are in Settings. I don't see how it can be done as the updater doesn't let you access the keys... but that is the only logical way I can think of.

Piedone wrote Feb 25 at 5:08 PM

The issue here is (and the reason it only affects parts using view models) that when a content item using editor groups is posted then all editors (that are not hidden through Placement) are updated. This isn't an issue if the part is used as a view model as it will just contain the saved values, but view models won't be filled because there is no corresponding POST data.

I think the real solution here is not to update editors of those shapes that aren't displayed because of in a different editor group.

Piedone wrote Feb 27 at 2:38 PM

I think this is a duplicate of: https://orchard.codeplex.com/workitem/20457