We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 12550
    • 107 Posts
    Или где-то что-то надо настроить?
      • 22301
      • 1,084 Posts
      cкорее всего, тебе помогут господа, знающие php... могу рассказать про свой опыт с аякссёрчем. засада в том, что любой поиск на сайте будет осуществляться силами мускула только по базе с контентом. нужно ли говорить о том, что мускулу не веданы русская морфология и остальные языковые тонкости. поиск стоит пришивать только в том случае, если он будет осуществляться, к примеру, по какой-нить номенклатуре, по названиям, имеющим одно единственное и устойчивое написание.

      а так, есть какие-то заморочки с кодировкой, как я смутно припоминаю, потому что запрос уходит с формы на сайте, отправляется в мускул, а дальше происходит выборка по полям, причём совпадение должно быть с точностью до буквы, правда, без учёта регистра. лучше конкретизируй, в чём у тебя проблема?

      :) yentsun на modx.ru поиск пришил, вот появится и расскажет.
        [img]http://jurist-info.ru/pic/rrr.jpg[/img]

        Безжалостный пияр!
        Artima -- неуч!
        Осторожно: преступная локализация -- modx-cms.ru
        Баштанник Андрей -- мегапрограммер из Белоруссии и поедатель говна, очень критично настроенный молодой человек!

        Дисклеймер для общительных: даю сам себе право транслировать в открытый эфир содержание лички, just for fun
        • 12550
        • 107 Posts
        Дак это все понятно. Локали в пхп стоят, поиск работает не на modx правда, а сам по себе на другом сайте.
        И здесь вроде бы работает, только ничего не находит, даже простейших комбинаций вроде 2006 - на любом языке одинаково пишется. )
        • На одном из сайтов я устанавливал сниппет FlexSearchForm от Etomite http://www.etomite.org/forums/index.php?showtopic=859&hl=FlexSearchForm. Только конечно пришлось его модифицировать, чтобы понимал русский и латышский язык.
          Вся фишка состояла в том, что нужно было использовать функции мультибайтных строк.
          Вначале сниппета прописал mb_internal_encoding("UTF-8");, а затем все операции со строками (обрезание строки, приведение к одному регистру для сравнения и т.п.) проводились через эти же функции mb_substr(), mb_strtolower() и т.д. И все работает как надо smiley
            Разработка сайтов и программных модулей на MODX.
            Опыт работы на MODx с 2005 года. Высокое качество.
            Компания Baltic Design Colors: http://www.bdcolors.ru.
            • 897
            • 1,620 Posts
            фишка в том что надо юзать UTF smiley
              "Und wenn du lange in einen Abgrund blickst, blickt der Abgrund auch in dich hinein."

              Не используйте Revo для "просто сайтов". Используйте Evo

              Who can defeat the Russian bear?
              • 33114
              • 518 Posts
              я лишь соглашусь насчет того, что проблемы с поиском связаны с MySQL. Например поиск на modx.ru чувствителен к регистру, что весьма плохо, и из-за того что кодировка полей базы данных - latin1. Получается символы хранятся в кодах и нечувствительность к регистру невозможна.
              Известный мне выход - изначально начинать заполнять сайт на MySQL 3 версий, они поддерживают кодировку полей win1251. Однако когда сайт уже построен на новых MySQL вроде как ничего не поделаешь:)

              Вот информационна страница моего хостера касательно всего этого:
              Работа с кодировками (mySQL 4 / 5)
              Кодировка базы данных (charset, collation) устанавливает режим работы с текстовой информацией в базе. Кодировка задается двумя параметрами: charset - набор кодов символов, рассматриваемых как текст, и collation - правило работы с этими символами (правила сортировки, сравнения, перевода регистров).

              В mySQL 4 появилась возможность самостоятельно задавать кодировки для таблиц и даже для отдельных полей таблиц.

              К сожалению, работа с разными кодировками в mySQL 4 и mySQL 5 сделана не вполне удачно. Мы можем предложить два способа работы.

              Работа с кодировкой по умолчанию

              По умолчанию на нашем хостинге установлен charset - latin1, collation - latin1_binary. Сравнение русских букв производится по их коду по номеру. Это позволяет делать следующее:

              Главное: Этот режим совместим со всем ПО - старыми и новыми клиентами, mySQL Front, PHP клиентами, ODBC, и т.д., т.е. достигается максимальная совместимость со всем тем, что работало с mySQL 3х версий.
              Хранение русских символов во всех режимах осуществляется правильно.
              Сортировка русских символов осуществляется правильно, кроме буквы Ё (к сожалению).
              К сожалению, регистро-независимое сравнение и преобразование регистров для русского алфавита в данном режиме не работает. Помните, это может привести к нерабочести приложений, которые на это рассчитаны!
              Для того, чтобы воспользоваться этим режимом, вам не нужно вносить никаких изменений в код - просто создавайте базу и работайте как обычно.

              Этот способ вполне подойдет людям, которым достаточно описанной функциональности, или в том случае, если решить проблемы, вызванные "корректной" работой с кодировкой, не удается.

              Работа с правильной кодировкой (CP-1251)

              Для работы с правильной кодировкой вам нужно с помощью средства управления базой, совместимого с mySQL 4, поменять кодировку таблиц. Удобнее это делать сразу после создания таблицы, чтобы поля унаследовали эту кодировку автоматом.
              Внимание: не забывайте, что поменять кодировку таблицы после создания там полей недостаточно, убедитесь, что поля тоже имеют правильную кодировку!

              Средства управления можно скачать с сайта www.mysql.com, например, mySQL Administrator.

              Главное: Этот режим не до конца совместим с ПО, рассчитанным на работу с mySQL 3, таким, как mySQL Front и т.п., также не всегда получается нормально работать с клиентами - PHP, ODBC, и т.д. Если вместо русских букв вы видите знаки ’?’ - вы попали именно в такую ситуацию.
              Большинство вопросов можно решить, воспользовавшись русскоязычными ресурсами по программированию, например, http://www.mysql.ru/.
              Обычно достаточно следовать короткому совету (см. примечание 1).
              Хранение и обработка русских символов во всех режимах осуществляется правильно.
              Внимание: практика показывает, что изменять charset и collation на таблице, которая уже имеет данные, бесполезно - вы получите ’?’ вместо русских символов.

              Примечание 1: Обычно для правильной работы с кодировкой CP1251 достаточно дать следующие команды после соединения с базой (это PHP код):

              mysql_query ("set character_set_client=’cp1251’");
              mysql_query ("set character_set_results=’cp1251’");
              mysql_query ("set collation_connection=’cp1251_general_ci’");

              Дополнительная информация

              К сожалению, служба поддержки не может оказывать помощь по решению проблем кодировок mySQL 4/5. Количество средств программирования и способов использования базы слишком велико, чтобы описать каждый случай.

              Практика показывает, что использование условно-правильного совместимого режима (latin1/latin1_binary), которое происходит по умолчанию, решает основную проблему работы с кодировкой (сортировку), и предоставляет хороший уровень обратной совместимости.

              В случае продолжающихся проблем мы можем также рекомендовать вам пользоваться базой mySQL 3.*, для которой на нашем хостинге установлена традиционная кодировка cp1251 (Windows). Однако помните, что в этом случае вам придется работать с текстами в кодировке cp1251.

                http://modx.ru - российская поддержка MODx
                http://newscup.ru - экспериментальный проект
                http://yentsun.com - персональный сайт