-
Notifications
You must be signed in to change notification settings - Fork 25
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
difference in preview vs Sulu data object (array vs object) - settings property #117
Comments
Thx for reporting. Interesting that it is even a object on the website would it expected that if empty array also there how the code is written. But good to know that it atleast is correctly normalized there. I think we need to have a deeper look at it. If you want to have a look at it it would be interesting what |
In which files and locations would that be for Sulu preview and Sulu headless output? |
The line you mention here: https://github.com/sulu/SuluHeadlessBundle/blob/0.x/Content/ContentTypeResolver/BlockResolver.php#L73 You can also use |
Hm, I'm a bit confused.
Is the same line called in both views? |
Yes once you need to debug it in the preview and once when rendered on the website. |
Okay that helps a little bit. Would be itneresting where the stdClass comes from as that should also be the case then in the preview. But I think maybe its already saved that way and as the preview is not saved it is outputted this way. A workaround would be |
Definitely interesting, yes.
Same happens when the page is saved + published.
Sounds like a feasible solution. |
It looks like there is some difference in the
settings
property.Is this already known, a bug, feature or something else due to typecasting?
preview:
frontend:
The logic seems to come from here:
https://github.com/sulu/SuluHeadlessBundle/blob/0.x/Content/ContentTypeResolver/BlockResolver.php#L73
$content[$i] = ['type' => $blockPropertyType->getName(), 'settings' => $blockPropertyType->getSettings()];
I guess in the preview it should also be an object? Not sure if it is because of the logic of
getValue()
for block properties combined with the normalization.The text was updated successfully, but these errors were encountered: