v10: Setting defaults

[KevinJump]

Separately from the Settings/Content discussion also considering what the sensible defaults for uSync on v10 might be ?

Settings

Root Folder

Settings	v9 default	"vNext" default
RootFolder	"uSync/v9/"	"uSync/vNext"

Not necessary, but by having the version in it we force people to make the conscious choice when using the uSync files as part of the update.

UseFlatStructure

Settings	v9 default	"vNext" default
UseFlatStructure	True	?

Puts all the files for a type (e.g content/doctypes) into a flat folder - makes item moves/renames less hassle (because you don't have to change the whole folder tree when an item changes).

GuidFileNames

Root Folder

Settings	v9 default	"vNext" default
GuidFileNames	False	?

Uses the Key (Guid) for the filename - makes it harder to quickly see what has changed on disk, but it makes the management of renames,moves,deletes, etc a lot easier - because files can't change their name, can always be unique (no clashes)

FailOnMissingParent

Settings	v9 default	"vNext" default
FailOnMissingParent"	false	?

uSync is quite tolerant of corruption/failure if you attempt to sync something and the parent item doesn't exist, uSync will either find the nearest ancestor or put an item in the root. this settings makes uSync error on a type if it can't find the parent. if this was say a doctype that could cause down-level sync errors.

Other settings or defaults ?

Happy to take suggestions for other settings - For example how might we make it easier to control content/media/settings (see current docs for how we do that now)

[leekelleher]

Commenting on those specific settings...

• Root Folder - With v7 and v8, I would always relocate this to be under ~/App_Data/uSync, reason being that I didn't want the uSync files to be publicly exposed. With v9, the root ~/uSync folder isn't publicly accessible by default, (e.g. not under wwwroot), so I've been leaving it in place. So for vNext, I'm happy with the default.
• UseFlatStructure - I'm trying to recall what false would do... is it the def.config files in nested folders? Yeah, I'd keep this as default.
• GuidFileNames - I do change this to be true, for the reason you say - node name renames/moves don't change the file names (on disk), feels easier on the git commits.
• FailOnMissingParent - I wasn't aware of this one; would leave as default.

I generally leave the rest of the config with the default settings.

[KevinJump]

thanks lee,

Just to confirm yes - UseFlatStructure = false - generates a folder tree similar to what you see in Umbraco (so content in folders, doctypes in folders for each container etc).

I am wondering today if we offer a one time migration option from the v9 to v10 folder - so if you copy over v9 content, usync tells you lets you import it.? this would let us change to something like guidfile names really easily, not worry about clashes and old files still being around.

[NikRimington]

I have mixed views on the GuidFileNames option. I love the ease I have for looking at the files and knowing what they relate to without having to delve into their content. But I can also understand why GuidFileNames is "better" from a software perspective.

I've never changed any of these options personally.

One setting that isn't listed here, that I think the default could do with changing is Dictionary Handler being set to one way by default, but then that kinda conflicts with if you are shipping content around where you would want it to bring it with any publishing.

[KevinJump]

yeah - i am the same with the GuidNames, I to have always liked being able to see the list of files in the site, but i am not sure how often that is done and the code is way simpler when handling guidnames 😄, while we will still have both (so the complex code is still there), there is just less chance if it 'going wrong' with renames etc (i think!).

Dictionary names is interesting, I see from forums and stuff this is often thing people using both uSync and 'other' syncing tool for Umbraco want to change a lot. different scenarios call for it to be treated as settings and as content, and as one way and as both. Maybe what we really need is a nice way to quickly flick between behaviours and clearly communicate to people which way it is working 🤔

thanks.

[NikRimington]

I think the problem with Dictionary items is the "structure" for them is essentially schema, but the values for them for each language is content... You almost need 2 handlers, a Schema + default value handler, and then a "content change" handler. But who knows, just thought I'd mention it :-D

[KevinJump]

yeah we could double pass it,

i think deep down in the code, we sort of can do a create but not populate, and then maybe have "content" version populate the values.

Pondering.... 👍