Eliminate storage of non-dirty settings

[westonruter]

I think I know why I was having environment problems yesterday. I think it was because I had so many settings loaded into the Customizer (278) and many of the settings were large being post settings with potentially very large post_content. I just looked at a snapshot I made and I calculated its size at 76,170 bytes (via wp post get 305 --field=post_content | wc -c). This is large. The post_content field is a LONGTEXT in MySQL which means it can store a snapshot post_content that is 56,386 times larger. Nevertheless, this is a ton of data to be passing back and forth with each snapshot update, and it could get is into trouble with timeouts and network latency.

I think we should perhaps remove the full scope from being a feature for the sake of scalability. With the UX changes in #30 it's not even an option anymore in the UI, and I think that it has always been a bit dubious in its usefulness. Thoughts?

[valendesigns]

I think that would be sane, and I'm all for it.

[westonruter]

@valendesigns is this something you had a branch for which you want to include in 0.4.0?

[valendesigns]

It's already in 0.4.0 I merged the branch locally.

[westonruter]

I've some followup in #46.

[valendesigns]

I've not tested it but that change looks like it's reverting things. Wouldn't it now add all the settings again, regardless of if their dirty?

[westonruter]

@valendesigns oh, possibly. I assumed that the JS wasn't sending the non-dirty settings in the request, but maybe this wasn't done?