Ироглифы при создании новой записи
-
При создании новой записи вся админка становится ироглифами, типа:
Добавить запись
И такое предупреждении:
Warning: Creating default object from empty value in /home/…………./docs/wp-admin/includes/post.php on line 642Два дня назад обновляли WordPress с 4.3 до 4.9.1 обновления проходили успешно.
Увидев страницу с ироглифами отключил все плагины и тему заменил на дефолтную, не помогло.
-
иероглифы лечатся добавлением в верх файла .htaccess строки
AddDefaultCharset UTF-8
Не помогло(((
# BEGIN WordPress AddDefaultCharset UTF-8 <IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteRule ^index\.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] </IfModule> # END WordPress
(А я ж Вам говорил, что есть проблемы с кодировкой)
# BEGIN WordPress
AddDefaultCharset UTF-8
Сказано: «в верх». Верх выше.
В секцию
# BEGIN WordPress ... # END WordPress
вообще ничего руками вписывать не стоит, потому что wordpress рано или поздно все равно заменит весь блок на свой.
SeVlad большое спасибо, по ссылке помогло: В панели управления хостингом выставьте кодировку по умолчанию utf-8.
Странно, как сайт у них ранее работал на версии 4.3 с windows-1251При создании новой записи стал русский, но ошибка другая сохранилась:
Warning: Creating default object from empty value in /home/…………./docs/wp-admin/includes/post.php on line 642
Код строки 642:
$post->post_content = apply_filters( 'default_content', $post_content, $post );
Отключение всех плагинов и переключение на тему Twenty Sixteen Версия: 1.4, не помогло(((
Ребята, проблема очень серьезная, помогите, если нужно дам новые данные, что необходимо. Иначе мне голову «открутят» за обновления
При создании новой страницы такая же ошибка.
Warning: Creating default object from empty value in /home/..../docs/wp-admin/includes/post.php on line 642
При создании комментария пишет: ОШИБКА: Не удалось сохранить комментарий. Пожалуйста, повторите попытку позже.Видимо, одна проблема все связано.
А проверьте-ка свободное место на хостинге и состояние БД. Всякое бывает. Некоторые хостеры при превышении лимитов переводят базу в состояние read only.
На хостинге сейчас:
Место 1.2 ГБ из 4.3 ГБ
БД написано Активнаа где написано read only такого статуса не нашел, может в phpMyadmin?
2 дня назад я попробовал архивировать сайт, не получилось, места не хватило.
Потом сжал картинки и освободил 1 гиг, теперь спокойно делается архив. Не знаю могло ли это повлиять, навряд ли.вангую, что поможет изменение версии php.
тоже так думал, сейчас:
PHP Version 5.6.31,
mysqlnd 5.0.11-devА nic пойдет ли на это, не знаю их правила.
А еще мне дали технический пароль от хостинга (на NIС RU такой есть), может права ограничены, из-за этого что-то не идет?
Прочитал правила, технический пароль: предназначен для специалиста, непосредственно осуществляющего настройку технических параметров услуги. Значит тут все ок.
а где написано read only такого статуса не нашел,
Это в правах пользователя БД на саму базу. Я смотрел в ПУ хостинга (ISPmanager). В PMA в явном виде, кажется, нет, но если залогинились в PMA от того же юзера, что и движок, можно попробовать создать таблицу и запись в ней.
Это всего лишь одна из версий. Ошибка не из числа тех, что в FAQе.
Кстати, лог ошибок php смотрели? Там может быть подсказка.
Странно, как сайт у них ранее работал на версии 4.3 с windows-1251
Вот пример того, как древняя ошибка (в данном случае неправильная настройка сервера) аукается через много лет.
Судя по др. проблемам наверняка в базе уже битая (разная) кодировка и исправлять нужно по-отдельности каждую таблицу если не каждую неправильную строку. Легко не будет. Возможно что и не всё устранится (опять вылезет через время).
АПД. Это не 100%, но вероятность такого весьма велика. Встречалось.
- Ответ изменён 6 лет, 8 месяцев назад пользователем SeVlad. Причина: АПД
В инструкции: список всех переменных (в том числе и тех, которые нужны для настройки кодировка MySQL) можно получить с помощью команды show variables
SeVlad в phpMyadmin командой show variables вывел данные о кодировке, код ниже. Там встречается 1251, об этом речь?
Variable_name Value auto_increment_increment 1 auto_increment_offset 1 autocommit ON automatic_sp_privileges ON avoid_temporal_upgrade OFF back_log 550 basedir /usr big_tables OFF bind_address 10.21.12.63 binlog_cache_size 32768 binlog_checksum CRC32 binlog_direct_non_transactional_updates OFF binlog_error_action IGNORE_ERROR binlog_format STATEMENT binlog_gtid_simple_recovery OFF binlog_max_flush_queue_time 0 binlog_order_commits ON binlog_row_image FULL binlog_rows_query_log_events OFF binlog_stmt_cache_size 32768 binlogging_impossible_mode IGNORE_ERROR block_encryption_mode aes-128-ecb bulk_insert_buffer_size 8388608 character_set_client utf8 character_set_connection utf8 character_set_database cp1251 character_set_filesystem binary character_set_results utf8 character_set_server cp1251 character_set_system utf8 character_sets_dir /usr/share/percona-server/charsets/ collation_connection utf8_general_ci collation_database cp1251_general_ci collation_server cp1251_general_ci completion_type NO_CHAIN concurrent_insert AUTO connect_timeout 10 core_file OFF csv_mode datadir /var/lib/mysql/ date_format %Y-%m-%d datetime_format %Y-%m-%d %H:%i:%s default_storage_engine InnoDB default_tmp_storage_engine InnoDB default_week_format 0 delay_key_write ON delayed_insert_limit 100 delayed_insert_timeout 300 delayed_queue_size 1000 disconnect_on_expired_password ON div_precision_increment 4 end_markers_in_json OFF enforce_gtid_consistency OFF enforce_storage_engine eq_range_index_dive_limit 10 error_count 0 event_scheduler OFF expand_fast_index_creation OFF expire_logs_days 0 explicit_defaults_for_timestamp OFF external_user extra_max_connections 1 extra_port 0 flush OFF flush_time 0 foreign_key_checks ON ft_boolean_syntax + -><()~*:""&| ft_max_word_len 84 ft_min_word_len 4 ft_query_expansion_limit 20 ft_stopword_file (built-in) general_log OFF general_log_file /var/lib/mysql/cmdb1154.log group_concat_max_len 1024 gtid_deployment_step OFF gtid_executed gtid_mode OFF gtid_next AUTOMATIC gtid_owned gtid_purged have_backup_locks YES have_compress YES have_crypt YES have_dynamic_loading YES have_geometry YES have_openssl DISABLED have_profiling YES have_query_cache YES have_rtree_keys YES have_snapshot_cloning YES have_ssl DISABLED have_statement_timeout YES have_symlink DISABLED host_cache_size 728 hostname cmdb1154.nic.ru identity 0 ignore_builtin_innodb OFF ignore_db_dirs init_connect SET NAMES cp1251
Вот статья хорошая: здесь
- Ответ изменён 6 лет, 8 месяцев назад пользователем Egor2015.
об этом речь?
Речь о том, что база работала (да и работает как я вижу) в 1251. И апач наверняка тоже. Для ВП же родная кодировка UTF8.
Те поступающие данные перекодировались в 1251 и в этом виде заносились в БД. Но все ли и в какой период — это вопрос.
Я встречал когда в одной базе, в одной таблице текст был в разных кодировках. И восстановить их было не всегда возможно — вероятно текст был многократно перекодирован во время переносов с хостинга на хостинг.
- Тема «Ироглифы при создании новой записи» закрыта для новых ответов.