Skip to content
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

Add test for weird cases #1532

Merged
merged 3 commits into from
Aug 9, 2022

Conversation

jordisala1991
Copy link
Member

@jordisala1991 jordisala1991 commented Aug 9, 2022

Subject

I am targeting this branch, because this fixes a bug in 4.x, introduced while we upgraded to SonataBlockBundle 4.0

Closes #1496

@jordisala1991 jordisala1991 marked this pull request as ready for review August 9, 2022 11:54
@jordisala1991
Copy link
Member Author

As you can see, the first commit shows the issues mentioned by @eerison . And the second commits fixes them. I have added 2 string cases:

  • Any string -> no call to setPosition
  • Numeric string -> call to setPosition previous cast to int

@@ -22,7 +22,7 @@
* id: int|string|null,
* name?: string|null,
* enabled: boolean,
* position: int|null,
* position: int|string|null,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It didn't followed the whole but since you're doing a is numeric check, should it be numeric-string here ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

numeric-string is more restrictive than string. IMO we should try to see if the string is numeric, so we cast it, or is not numeric, so we not setPosition.

if (isset($content['position'])) {
$block->setPosition($content['position']);
if (isset($content['position']) && is_numeric($content['position'])) {
$block->setPosition(\is_string($content['position']) ? ((int) $content['position']) : $content['position']);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about always casting to int ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will try, I tried to be clever so I don't get complains for phpstan/psalm , for already int casting.

@@ -181,8 +181,8 @@ public function loadBlock(array $content, PageInterface $page): PageBlockInterfa

$block->setEnabled($content['enabled']);

if (isset($content['position'])) {
$block->setPosition($content['position']);
if (isset($content['position']) && is_numeric($content['position'])) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we throw an exception when it's set but not a numeric ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure TBH, old snapshot data, if it is not easily fixable, might contains some weird data.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For now I would go for the , let's try to see what data can get on the snapshot content and fix all the errors. Later we might want to provide a command to fix snapshots, or fix snapshots on the fly while being loaded. Not sure right now, but at a first step, I would prefer to not throw a lot of exceptions on old data.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah sure. I think you can just cast to int everytime and it's ok for me

@Hanmac
Copy link
Contributor

Hanmac commented Aug 9, 2022

we should probably do a similar MR in 3.x to stop such values if possible
so when 4.x comes around, the database values are fixed?

or do we need a doctrine migration script / or Command for this?

@eerison
Copy link
Contributor

eerison commented Aug 9, 2022

we should probably do a similar MR in 3.x to stop such values if possible so when 4.x comes around, the database values are fixed?

or do we need a doctrine migration script / or Command for this?

I suggested this few minutes ago in your PR :D

I guess we just need to check if there are position or some data saved wrong, we could raise a deprecate message, the guy just need to generate a new snapshot.

@eerison
Copy link
Contributor

eerison commented Aug 9, 2022

Ok I guess it is a good news (I hope 😄 )

I tested this branch, and I don't see the setPosition error anymore!

I just see this error

An exception has been thrown during the rendering of a template ("The options "manager", "page_id" do not exist. Defined options are: "attr", "class", "code", "extra_cache_keys", "layout", "template", "ttl", "use_cache".").

But after merge this, probably this PR #1524 gonna fix this issue too :D

I guess we could merge this, don't you 😃

@VincentLanglet
Copy link
Member

I guess we could merge this, don't you 😃

Yes, I just wait for @jordisala1991 to take a look at my suggestions ;)

@VincentLanglet VincentLanglet merged commit d660cf8 into sonata-project:4.x Aug 9, 2022
@jordisala1991 jordisala1991 deleted the hotfix/tests branch August 9, 2022 13:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants