Sounds reasonable, do you want to elaborate ?

I have the same problem! It started when we upgraded a R1-site to R2 SP1. When we trying to save a page on a non master language that have global properties we get this error.

Mattias, which property is causing the problem ?

The root of the problem could be that a property is signaling IsModified=true when it really should not have been modified (since we can't save global properties on any other language than the master-language they should have been correctly disabled).

The property thats causing the problem is a global property of type: xhtml-string.

 So what are you saying? Is this a problem that can't be fixed until next release? I saw that there were a bug (#18011) similar to this that had been fixed in the R2 SP1 but that just concerned MultiLinkProperty.

This bug has been fixed after SP1 (I added a new bug since this fix actually corrected another bug caused by the same underlying behvaiour):
Bug #23775: Cannot save common property on non-master language (XHTML-string)

The only workaround I can think of until the next SP is to listen to SavingPage event and setting IsModified to false for this propery when not on the master language.

We have a site upgrade from CMS 4.62 to CMS 5 SP1 where we see this issue, after reading this thread we were hoping that it would be fixed after upgrading to R2 SP2, but no luck.

We have this code in an eventhandler wired up to the SavingPage event:
e.Page["T_Name"] = "Some string we get";

The T_Name property is a common property, and if we are saving on another language this throws the error described in this thread.

In CMS 4 these changes were just ignored.
I have not read anything in the changelog or braking changes between CMS4 and CMS5 regarding this.

Anyone else still see this bug?

Regards,
Morten Sorby

The fix was that we threw this exception when there was no changes to common properties, that has been fixed in SP2 as far as I know.

You need to add an condition in your eventhandler to only update common properties when the master language is being saved. That error is by design.

Ok, so it's a pretty major change that's gone under my radar.
I agree that it's a good thing to not just suppress it like in CMS4, however the CMS5 implementation is not a whole lot better then suppressing the change.

I say this because the error gets thrown way down in the ValidateLanaguageSpecificUsage called by EPiServer.PageSaveDB.CreateAndSave().

From my point of view it should be thrown on PropertyDatas SetPropertyValue method.
That way it would be thrown instantly when trying to set the property and prevent one from having an in-memory PropertyData that cannot be committed to the persistent layer passed along the event chain and all sort of decisions being made based on it.
-Just like in CM4. The only difference is that now you get a nasty error reminding you that you might have messed up the business logic along the way:-)

Great feedback Morten, I'll have a look what the other devs think about it.