1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Won't Fix [Workaroundable] unable to rename phrase title

Discussion in 'Resolved Bug Reports' started by ragtek, Apr 15, 2011.

  1. ragtek

    ragtek Guest

    I can't save a already existing phrase, where i only changed some small chars to big chars in the title. (sorry don't know how it's called in english:D )

    For example:

    old phrasename: ragtek_NUNS_conversation_subject
    new phrasename: ragtek_nuns_conversation_subject

    errror: Phrase titles must be unique in a language. The specified phrase is already in use.

    i think it's because the datawriter checks only if the title exists and it doesn't care of small/big chars

    for the datawriter FOO is equal to foo so it's duplicate and it throws the error that it's not equal:(

    PHP:
    protected function _preSave()
        {
            if (
    $this->getOption(self::OPTION_CHECK_DUPLICATE))
            {
                if (
    $this->isChanged('title') || $this->isChanged('language_id'))
                {
                    
    $existing $this->_getPhraseModel()->getPhraseInLanguageByTitle($this->get('title'), $this->get('language_id'));
                    if (
    $existing)
                    {
                        
    $this->error(new XenForo_Phrase('phrase_titles_must_be_unique_in_language'), 'title');
                    }
                }
            }
        }
     
  2. Brogan

    Brogan XenForo Moderator Staff Member

    I presume this is because phrase titles are case agnostic.

    I suppose a workaround would be to rename the original phrase to something different and then once again with the upper case characters.
     
  3. ragtek

    ragtek Guest

    case agnostic
    that's what i was searching for, thx:)

    i wish i wouldn't think so complicated^^
    instead of doing this, i started debugging and searching for the problem^^
     
  4. Mike

    Mike XenForo Developer Staff Member

    This can be worked around, though it introduces possibilities of weird behaviors with MySQL, particularly related to collations. The safest thing is to leave it as is, and do the a->b->A workaround.
     

Share This Page