New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Liquid templates ContentItems property names became case insensitive #16016
Comments
@MikeAlhayek can you comment on this, please? |
Might the naming policy have been change after introducing STJ OrchardCore/src/OrchardCore/OrchardCore.Abstractions/Json/JOptions.cs Lines 44 to 47 in 23ee4f1
|
I just notice
@MikeAlhayek it's on your plate while you complete the JT PR |
That's not something we want to change, though. It seems that while the previous de/serialization logic was more forgiving, in the end, the code had a bug that's now surfaced. That's good. We may make the exception more user-friendly though if feasible. |
What's the bug in particular? It is true, that previous de/serialization logic was more forgiving, but the CaseInsesitivity is a mystery for me. I can't see it's purpose. How do we ensure, this doesn't happen again? The user interface shouldn't allow this. |
The bug is in your code :). I don't think there is one in OC. Identifiers everywhere in C# and OC are case-sensitive apart from selected cases, so I don't see why we would try to allow case insensitivity for part or field names (which are case-sensitive anyway) in Liquid. (To clarify, what this issue is about is case-sensitivity, not case-insensitivity, since your code worked because previously the serializer was case-insensitive.) |
@hishamco I don't think When the For example, if you have this class
you can deserialize this with no problem.
But, the following will only be deserialize correctly if
I am not very familiar Fluid project which may be the cause of the issue. @sebastienros |
We created a field named "Camelcase", then we created some contentItems, the we removed the field "Camelcase" and created a new one named "CamelCase". Everything worked fine until we upgraded to OC 2.0 |
Ah OK, got it, sorry about the confusion. |
What is the full stack trace to understand which component is not happy? |
This could be from
Where in JSON.NET the accessor would be case insensitive, but STJ might be case-sensitive. |
They behave the same, case sensitive https://dotnetfiddle.net/CxK4ls |
After upgrading from 1.9 to 2.0 we've noticed some of our liquid templates failing with a the error
ArgumentException: An item with the same key has already been added. Key: Camelcase (Parameter 'propertyName')
This happend because we are calling
{{ field.MyProperty.CamelCase.Text }}
This just so happens that in some time during design and development we misstyped the name of the field and later changed it from
Camelcase
toCamelCase
which left us with some harmless rubish in the JSON content... well at least until we upgraded to OC 2.0{"CamelCase":{"Text":null},"Camelcase":{"Text":null}}
Is this switch, to case-insensitiveness was done intentionally?
The text was updated successfully, but these errors were encountered: