Поддержка Проблемы и решения Ироглифы при создании новой записи

  • При создании новой записи вся админка становится ироглифами, типа:
    Добавить запись

    И такое предупреждении:
    Warning: Creating default object from empty value in /home/…………./docs/wp-admin/includes/post.php on line 642

    Два дня назад обновляли WordPress с 4.3 до 4.9.1 обновления проходили успешно.
    Увидев страницу с ироглифами отключил все плагины и тему заменил на дефолтную, не помогло.

    • Тема изменена 4 года, 10 месяцев назад пользователем Egor2015.
    • Тема изменена 4 года, 10 месяцев назад пользователем Egor2015.
Просмотр 15 ответов — с 1 по 15 (всего 29)
  • Модератор Yui

    (@fierevere)

    ゆい

    иероглифы лечатся добавлением в верх файла .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, не помогло(((

    • Ответ изменён 4 года, 10 месяцев назад пользователем Egor2015.
    • Ответ изменён 4 года, 10 месяцев назад пользователем Egor2015.

    Ребята, проблема очень серьезная, помогите, если нужно дам новые данные, что необходимо. Иначе мне голову «открутят» за обновления

    При создании новой страницы такая же ошибка.
    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 такой есть), может права ограничены, из-за этого что-то не идет?

    Прочитал правила, технический пароль: предназначен для специалиста, непосредственно осуществляющего настройку технических параметров услуги. Значит тут все ок.

    • Ответ изменён 4 года, 10 месяцев назад пользователем Egor2015.
    • Ответ изменён 4 года, 10 месяцев назад пользователем Egor2015.

    а где написано read only такого статуса не нашел,

    Это в правах пользователя БД на саму базу. Я смотрел в ПУ хостинга (ISPmanager). В PMA в явном виде, кажется, нет, но если залогинились в PMA от того же юзера, что и движок, можно попробовать создать таблицу и запись в ней.

    Это всего лишь одна из версий. Ошибка не из числа тех, что в FAQе.

    Кстати, лог ошибок php смотрели? Там может быть подсказка.

    Странно, как сайт у них ранее работал на версии 4.3 с windows-1251

    Вот пример того, как древняя ошибка (в данном случае неправильная настройка сервера) аукается через много лет.

    Судя по др. проблемам наверняка в базе уже битая (разная) кодировка и исправлять нужно по-отдельности каждую таблицу если не каждую неправильную строку. Легко не будет. Возможно что и не всё устранится (опять вылезет через время).

    АПД. Это не 100%, но вероятность такого весьма велика. Встречалось.

    • Ответ изменён 4 года, 10 месяцев назад пользователем 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

    Вот статья хорошая: здесь

    • Ответ изменён 4 года, 10 месяцев назад пользователем Egor2015.

    об этом речь?

    Речь о том, что база работала (да и работает как я вижу) в 1251. И апач наверняка тоже. Для ВП же родная кодировка UTF8.
    Те поступающие данные перекодировались в 1251 и в этом виде заносились в БД. Но все ли и в какой период — это вопрос.
    Я встречал когда в одной базе, в одной таблице текст был в разных кодировках. И восстановить их было не всегда возможно — вероятно текст был многократно перекодирован во время переносов с хостинга на хостинг.

Просмотр 15 ответов — с 1 по 15 (всего 29)
  • Тема «Ироглифы при создании новой записи» закрыта для новых ответов.