Возмоно ли настроить так, чтобы в базе MySQL русские записи хранились не ввиде крякозябров, а ввиде текста. Заглядываю туда через MySQL-Front и вижу крякозябры. Но можно ли настроить так, чтообы везде было по русски? Кодировки типа 1251 отпаают a-priori, поскольку записи придется вести не только по русски, но и на других языка, у которых есть свои таблицы. И всё это наперемешку, в пределах одного сообщения может быть.
Кодировка UTF8 в базе данных
В этом случае вам обязательно нужно использовать MySQL не ниже 4.1. Если это условие выполяется, то в моей сборке в файле wp-db.php в самом конце присутствуют закоментированные строчки по идее вам достаточно установить:
(Естественно и сам WordPress добжен быть UTF8).
Да уж не ниже… в аккурат 4.1
А ваша сборка у меня вообще пошла по крякозябрам, не только внутри /в базе/, но и снаружи /веб интерфейс/
И эти директивы совсем не способствуют понимаю 🙁
Не знаю, что и делать уже
Если пошли крокозяблы, значит вы неверно используете кодировку. Если ваш блог в UTF8, то и сборку берите UTF8. Насчет крокозяблов в базе, то MySQL свои данные хранит в юникоде, поэтому для отображения, например через phpMyAdmin, можно настроить "сопоставление" кодировок. В этом случае вы и увидите данные "изнутри". То есть
а) установите сборку в той кодировке в которой вы вносили данные в блог;
б) добейтесь корректного отображения текста на сайте. Для этого коментируете строчки с SET – их можно по отдельности "включать";
в) если у вас все равно выскакивает крокозяблы, значит увас или проблемы с базой, либо вы все-таки используете не Utf8, или неверно устанавливали кодировку блога.
Насчет английской версии. Уже, честно говоря миллион раз говорил, что для нее все равно какая кодировка – английский текст входит во все кодировки, поэтому он будет отображаться корерктно, что у англичан, что у руссоязычных, что у китайцев.
коцал вручную атрибуты таблиц базы данных 🙁 после чего зараотало. но это в оригинальной сборки. ваша сборка у меня ругается, мол нет прав ни на что, кроме как заходить в админскую панель и смотреть на доску объявлений…
Нет, тут я ничего сказать не могу. Если вдруг поборите, то дайте знать, вдруг у кого будет подобная проблема.
Да вот, например. Еще один такой случай.
http://forum.maxsite.org/viewtopic.php?id=73
я не стал долго бороться, просто закинул несколько файлов из вашей сборки /где прописана нумерация для рубрик/ в оригинальную, и на этом успокоился. а жаль…
На самом деле был еще один такой же случай, но причину мы так и не смогли установить и чем все закончилось я так и не знаю. Сам-то я устанавливал десятки WordPress своей сборки и нигде таких проблем не было. Если можно было бы как-то локализовать проблему, то можно было бы и найти сам баг. А так я даже не могу предположить где искать – оригинальная версия практически ничем не отличается от моей сборки – функциональность один в один, за исключением исправлений трэкбаков, пингов и добавленного порядка рубрик.
Linux Fedora Core 4. права все были прописаны начиная с пользовательского каталога уже. ставил аж 777, но почему-то не помогло. При этом SELinux в системе был отключен (disabled)
Да вот какой прикол. Попытался поставить снова. Поставилось. Вроде раотает. Но русские буквы показываются с косяками :(. Раскоментировал
$wpdb->query("SET NAMES ‘utf8’");
$wpdb->query("SET CHARACTER_SET_CLIENT=’utf8’");
После чего началась свистопляска. В админской панели большинство панелей перестало открываться, выдавая сообщение: "Вы не имеете достаточно прав для доступа к данной странице". Тогда я закоментировал строчки обратно. Снова всё работает, но проблема с русским… 🙁
Бредятина
Да, спотыкается именно из за строчки:
$wpdb->query("SET NAMES ‘utf8’");
Если строчку раскомментировать, то wordpress начинает мне отказывать в доступе к административным страницам
таже петрушка, с отказом в достпе к административным страницам, если прописать директиву в my.cnf
[mysqld]
init-connect=’SET NAMES utf8’
При этом. Сразу после инсталяции wordpress я проверил базу данных. Так вот сообщения там хранятся в виде кракозябров. Никакого намека на Привет, мир… В браузере однако показывается:
"Привет, мир!
Сентябрь 15, 2006
Добро пожаловать в WordPress. Это Ваша перва�? запи�?ь. Отредактируйте или удалите ее. Затем начинайте пи�?ать."
Что касается mysql, то я его даже пересобрал с with-charset=utf8, так что теперь:
mysql> show variables like ‘character%’;
+————————–+—————————-+
| Variable_name | Value |
+————————–+—————————-+
| character_set_client | utf8 |
| character_set_connection | utf8 |
| character_set_database | utf8 |
| character_set_results | utf8 |
| character_set_server | utf8 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
+————————–+—————————-+
7 rows in set (0.00 sec)
Но по сути ничто не изменилось
Что не изменилось? Вы вначале установили WordPress, потом изменили настройки сервера, а теперь хотите, чтобы WordPress корректно работал? Так не будет. Добейтесь корректной работы MySQL, а уже потом ставьте WordPress.
Ваше утверждение "сообщения там хранятся в виде кракозябров" – это абсурд, поскольку каким образом MySQL хранит свои данные никого волновать не должно – это его внутренняя структура. Или вы уже и файлы таблиц исправляли? Чего же вы теперь хотите???
Мой совет – поставьте денвер заново, пусть будут настройки по умолчанию.
Проверьте работу MySQL. Сделать это можно с помощью phpMyAdmin.
Создайте отдельного юзера, его пароль и базу данных для WordPress.
Сделайте отдельный хост (или даже localhost подойдет), куда вы будете устанваливать WordPress.
После этого установите WordPress. Укажите параметры доступа к базе в wp-config.php.
Не трогайте SET! Или, если вы хотите принудительно изменить кодировку базу данных (не блога!), то сделайте это ДО инсталяции WordPress. Тогда у вас никаких крокозябел не будет. Если же вы сделаете это ПОСЛЕ установки, то они и появятся, поскольку вы изначально внесли свои данные и они сохранились в БД в одной кодировке, а после переключения (SET) вы их храните и получаете уже в другой.
Оригинальная сборка работает. Доабавил эти две строки в файл и всё…
Не работает ваша сборка. При этом ставил до и после изменения настроек сервера. Косяк идет из за параметра set names, вне зависимости, прописан он в вашем файле или же в конфиге mysql. При этом оригинальная сборка даже глазом не моргнула… Всё делали и отдельных юзеров и тд.
Повторяю. Сначала менял, потом инсталлил. Всё спотыкается на особенность сборки.
при одних и тех же условиях задавая $wpdb->query("SET NAMES ‘utf8’"); оригинальная сборка работает как надо, а ваша ругается, мол, у меня нет прав.
А зачем вы выполняете SET?
Судя по вашему логу, ваша MySQL уже работает в UTF8. В чем тогда смысл еще раз указывать это через SET?