[DC-728] Updating slug in I18N behaviour yields non-unique slug Created: 11/Jun/10 Updated: 05/Oct/10
|Affects Version/s:||1.2.0, 1.2.1, 1.2.2|
|Reporter:||Florian Aschenbrenner||Assignee:||Jonathan H. Wage|
There seems to be a bug in the way, doctrine tries to find a unique slug for a table that is I18N-enabled and has a slug in it.
Now, if we insert a new entry, the slug get's created as expected. If we now insert another entry that would yield the same slug, the slug is made unique by adding the postfix as expected - all well so far.
Now, if we try to update the entry with the slug with the postfix, what i think is an error happens (Excerpt from Sluggable.php, lib/Doctrine/Template/Listener/Sluggable.php):
So, the $record->exists() check evaluates to true and $table->getIdentifierColumnNames() yields the fields id and lang, so the whereString is something like
Now for the problematic part:
So the resulting whereString has something like
which will never yield a result in my eyes, thus, the postfix is never incremented and the slug defaults to the the slug of name without postfix.
|Comment by Rodrigo Borrego Bernabé [ 24/Jun/10 ]|
We've also found this problem and make a temporal workaround. But maybe our workaround can give someone an idea on how to fix the bug so I'm pasting the changed code here
In file sfDoctrinePlugin\lib\vendor\doctrine\Doctrine\Template\Listener\Sluggable.php (getUniqueSlug method)
|Comment by Christian Seaman [ 05/Oct/10 ]|
Rodrigo, I think the solution is simpler than you might expect...
The problem is that it is doing an AND where it should be doing an OR to find records other than the current one.
So, you just need to replace this part of Sluggable::getUniqueSlug():
With this code (the 3rd line has extra brackets and OR instead of AND):
In more detail, the WHERE clause being built up is saying:
However, to check that it's not the same record you just need one of the key values to be different (not all of them) so the check should be something like:
The modification to the code as stated above generates queries that look like this, which I'm pretty sure is correct: