Fix slug generation if the getRegenerateSlugOnUpdate method return false

[hermann8u]

This PR aims to fix the bug described in the issue #471

If the getRegenerateSlugOnUpdate method return false, the slug will be generate if its value is null.

This behavior seems legit because you can set the slug manually and it won't be regenerated. However if you set manually the slug value to null, it will be regenerated (the setter doesn't allow this anyway).

[TomasVotruba]

Wow, thank you for finding time! 🎄

Could you also add a test case to show, what went wrong? So we don't have this bug in the future due to unrelated changes.

[hermann8u]

Any idea how to ignore this blocking "CS" check?

The getRegenerateSlugOnUpdate method is private on the trait but is considered as unused in the CS check when I override it in the implementing entity.

EDIT

Ok, I just add the class to the skip section for this rule of the CS config

[TomasVotruba]

Where is this property used?

[hermann8u]

It is not but I keep it from the SluggableEntity I copied. The goal of this property is to have an other property which is not concerned by the slug generation. For the moment, this property is useless, so we have 3 choices:

• Keep it for future test case
• Remove it because there is no test based on it
• Add test concerning it like in Knp\DoctrineBehaviors\Tests\ORM\SluggableTest class

What do you think?

[TomasVotruba]

I'd remove it in both, because it doesn't add any value

[hermann8u]

The value of the date property in Knp\DoctrineBehaviors\Tests\Fixtures\Entity\SluggableEntity is to test that the slug is not updated when we change an unrelated value.
But in Knp\DoctrineBehaviors\Tests\Fixtures\Entity\SluggableWithoutRegenerateEntity, there is no test with this date property so I agree to delete it.

[TomasVotruba]

Ok, I just add the class to the skip section for this rule of the CS config

👍

Thanks for adding test case here.

[TomasVotruba]

Thank you 👍