Импорт базы данных Опции

[Finnegan]

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

[Finnegan]

Настроил редирект по найденному старому .htacess
Вроде все заработало.

Но есть досадные ошибки.
1.
При первом заходе на сайт на страницах сбита кодировка, текст отображается знаками вопроса. Хотя в меню текст отображается правильно.
При перезагрузке страницы кодировка устаканивается и все буквы отображаются как надо.


Нужно что-то еще прописать в файл .htacess, чтоб отладить кодировку?

2.
Статические страницы отображаются без ошибок.
А вот страницы с новостями с ошибкой

Warning: Call-time pass-by-reference has been deprecated; If you would like to pass it by reference, modify the declaration of exec_acts(). If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file in /storage/h7/113/1450113/public_html/engine/includes/news.php on line 158 Warning: Call-time pass-by-reference has been deprecated; If you would like to pass it by reference, modify the declaration of exec_acts(). If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file in /storage/h7/113/1450113/public_html/engine/includes/news.php on line 449

Я правильно понимаю, что мне нужно в файле news.php изменить значение на true в строчках 158 и 449?

3.
Я импортировал базу данных от июля 2016.
Но у меня в папке с бекапами есть файл backup_2017_04_18_10_57
Могу я через этот файл восстановить базу данных до состояния на апрель 2017?
И если да, то как технически это сделать? В админ панели сайта не могу найти такую опцию.

[Adamos]

Нужно что-то еще прописать в файл .htacess, чтоб отладить кодировку?

Если сайт в виндовской кодировке, то

Код

AddDefaultCharset windows-1251

Я правильно понимаю, что мне нужно в файле news.php изменить значение на true в строчках 158 и 449?

Нет. У вас выводятся предупреждения, их надо отключить. Например, в том же .htaccess

Код

php_flag display_errors off

Если, конечно, движок сайта не перенастраивает этот флаг сам.

[Finnegan]

Нет. У вас выводятся предупреждения, их надо отключить. Например, в том же .htaccess

Предупреждения исчезли.

Если сайт в виндовской кодировке, то

Код

AddDefaultCharset windows-1251

А вот знаки вопроса периодически появляются на некоторых страницах. И пропадают после перезагрузки.
Кроме изменения .htacess, прописал cp_1251 general ci в кодировке базы данных (в phpMyAdmin)
Но проблема по-прежнему имеет место быть.


Поправка.
в базе данных в phpMyAdmin опять кодировка utf8mb4_unicode_ci
Видимо там исправления только на текущую сессию сохраняются. Странно.

Сообщение отредактировал Finnegan - 24.4.2017, 18:46

[baseq3]

Предупреждения исчезли.


А вот знаки вопроса периодически появляются на некоторых страницах. И пропадают после перезагрузки.
Кроме изменения .htacess, прописал cp_1251 general ci в кодировке базы данных (в phpMyAdmin)
Но проблема по-прежнему имеет место быть.


Поправка.
в базе данных в phpMyAdmin опять кодировка utf8mb4_unicode_ci
Видимо там исправления только на текущую сессию сохраняются. Странно.

ничего странного: php файл в другой кодировке
надо все в порядок приводить

[Finnegan]

ничего странного: php файл в другой кодировке
надо все в порядок приводить

А как это сделать?

Изменил в .htacess запись о кодировке на такую:
DefaultLanguage ru
AddDefaultCharset windows-1251
php_value default_charset "cp1251"

Но проблема остается. Вроде сайт отображается нормально, а как зайдешь в раздел с тестами, сразу весь текст на сайте превращается в знаки вопросов



Кстати.
И у меня появилась идея: что если обнулить базу данных (удалить таблицы и их содержимое),
оставить только пустую оболочку с именем БД и юзернеймом пользователя;
и запустить через админ панель файл backup_2017_04_18_10_57
чистая база данных восстановится из этого файла?

Или нужно, чтоб в БД были хоть какие-то данные и таблицы?

[Adamos]

Есть старинная админская мудрость: перед восстановлением базы из бэкапа сделай бэкап того, что есть.
Позволяет сохранить волосяной покров на ягодицах, если что-то пошло не так.

[Finnegan]

Есть старинная админская мудрость: перед восстановлением базы из бэкапа сделай бэкап того, что есть.
Позволяет сохранить волосяной покров на ягодицах, если что-то пошло не так.

Т.е. восстановление чистой БД из backup_2017_04_18_10_57 может прокатить?
Задница-то за два последних дня уже почти и так облысела, так что терять особо нечего.

[Adamos]

Может, конечно. В бэкап пишутся все команды создания таблиц и их наполнения.
В том числе - и кодировка, кстати. Но вам нужно перед этим настроить правильную кодировку базы, чтобы запрос к ней шел в правильной кодировке.

[Finnegan]

Может, конечно. В бэкап пишутся все команды создания таблиц и их наполнения.
В том числе - и кодировка, кстати. Но вам нужно перед этим настроить правильную кодировку базы, чтобы запрос к ней шел в правильной кодировке.

Кодировку я настроил. В phpMyAdmin нашел, где зафиксировать кодировку базы как cp_1251_general_ci, чтоб она не сбрасывалась.
Но возникла другая проблема. Я очистил содержимое базы данных и теперь не могу войти в админ панель сайта. Видимо логин/пароль админа как раз в таблице с юзерами был:)

[Finnegan]

В общем очистил все, кроме папки с юзерами в базе данных.
Восстановил базу данных из бэкапа backup_2017_04_18_10_57.
Теперь весь сайт в знаках вопроса. Ни одного слова на кириллице.

В .htacess запись о кодировке windows-1251 на месте. Но это не помогает.

[Adamos]

Вопрос в том, откуда берется "весь текст на сайте".
У текста, прописанного в самих PHP-файлах, база ни при чем - он выводится кракозябрами, если сервер неверно отдает в заголовках кодировку. В принципе, та строчка в .htaccess должна от этого помогать, но бывают нюансы.
Если же текст берется из БД, то проблема в кодировке соединения. Нет, это не сравнение cp_1251_general_ci, это другая настройка. Не уверен, что в PMA ее вообще можно решить, если у вас нет доступа к его localhost - у хостеров обычно пользователь имеет доступ только к конкретной базе. Тут решают либо костыли типа выставления "SET NAMES cp1251" / mysqli_set_charset в потрохах сайта, либо перекодировка всей базы.

[Finnegan]

Вопрос в том, откуда берется "весь текст на сайте".
У текста, прописанного в самих PHP-файлах, база ни при чем - он выводится кракозябрами, если сервер неверно отдает в заголовках кодировку. В принципе, та строчка в .htaccess должна от этого помогать, но бывают нюансы.
Если же текст берется из БД, то проблема в кодировке соединения. Нет, это не сравнение cp_1251_general_ci, это другая настройка. Не уверен, что в PMA ее вообще можно решить, если у вас нет доступа к его localhost - у хостеров обычно пользователь имеет доступ только к конкретной базе. Тут решают либо костыли типа выставления "SET NAMES cp1251" / mysqli_set_charset в потрохах сайта, либо перекодировка всей базы.

Текст меню берется из файла main.tpl - и там все отражается нормально.
Весь остальной текст на сайте - со статических страниц (их около 900) и "новостей" (около 30).
Так что все завязано на БД.

В самой базе данных это выглядит так:

[WolF]

Текст меню берется из файла main.tpl - и там все отражается нормально.
Весь остальной текст на сайте - со статических страниц (их около 900) и "новостей" (около 30).
Так что все завязано на БД.

В самой базе данных это выглядит так:

Проблема 99.9% в несовпадении кодировки текстового файла дампа БД с кодировкой базы. Причем надо понимать что у mysql несколько разных кодировок - кодировка соединения, кодировка самой базы, кодировка сервера.
Ещё в самом SQL дампе могут быть команды на изменение кодировки причем не факт что правильные.
Что бы сделал я
1) Открыл дамп базы в текстовом редакторе, поддерживающем работу с разными кодировками и автоопределением (какой нибудь Notepad++). Посмотрел какая там кодировка у текста.
2) Поискал бы в дампе команды на изменение кодировки типа SET NAMES utf-8 + нет ли явного указания кодировки для самих таблиц и текстовых полей в запросах CREATE TABLE .
Если в пункте 2 есть явное указание кодировки в дампе - для таблиц и полей и это нормальная кодировка (utf-8, cp1251_generai_ci и т.п.), то это хорошо. Эта кодировка должна совпадать с кодировкой самого
файла! То есть если в дампе команды на создание таблиц в utf-8 но сам файл в 1251 - это не очень хорошо . Тут поможет текстовый редактор который позволит сохранить дамп в соответствующей кодировке.
Самое плохое если в дампе есть явное указание кодировки, но эта кодировка некириллическая - к примеру latin1. Тогда придется долго и мучительно менять везде глобальным поиском и заменой на ту же 1251 , потом пересохранить файл в такой же кодировке.
3) На этом этапе если всё сделано корректно у нас есть правильный дамп. Правильный - это значит его внутреннее содержимое соответствует тем командам которые этот дамп дает mysql серверу.
Собственно останется его импортировать. PhpMydmin можно указать кодировку, в которой находится дамп при импорте. Естественно нужно выбрать ту, у который мы приводили дамп двумя пунктами ранее.

[Finnegan]

Дамп базы - это файл .sql?

[WolF]

Дамп базы - это файл .sql?

Ага. Вот к примеру:

-- MySQL dump 10.13 Distrib 5.5.47, for Linux (x86_64)
--
-- ------------------------------------------------------
-- Server version 5.0.95

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

--
-- Not dumping tablespaces as no INFORMATION_SCHEMA.FILES table on this server
--

--
-- Table structure for table `BANNER`
--

DROP TABLE IF EXISTS `BANNER`;
/*!40101 SET @saved_cs_client = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `BANNER` (
`ID_BANNER` int(11) unsigned NOT NULL auto_increment,
`ID_RAZDEL` int(11) default NULL,
`ALT` varchar(255) default NULL,
`GIF` varchar(255) default NULL,
`URL` varchar(255) default NULL,
PRIMARY KEY (`ID_BANNER`)
) ENGINE=MyISAM AUTO_INCREMENT=36 DEFAULT CHARSET=utf8;
/*!40101 SET character_set_client = @saved_cs_client */;

Я выделил на примере на что обратить внимание. В дампе во первых в самом начале дампа и перед импортом каждой таблицы стоят команды "забыть" какая там кодировка была и установить свою - utf8 .
Вот файл обязан быть этой же кодировки по содержимому. И созданная база данных крайне желательно чтобы была в этой же кодировке.

[Finnegan]

1) Открыл дамп базы в текстовом редакторе, поддерживающем работу с разными кодировками и автоопределением (какой нибудь Notepad++). Посмотрел какая там кодировка у текста.
2) Поискал бы в дампе команды на изменение кодировки типа SET NAMES utf-8 + нет ли явного указания кодировки для самих таблиц и текстовых полей в запросах CREATE TABLE .

Открыл NPP три файла .sql
1. в файле .sql, который я не мог загрузить (от апрель 2017), кодировка "UTF8 без BOM"
2. в файле .sql, который я загружал (от июль 2016), кодировка "UTF8 без BOM"
3. в файле .sql из восстановленого бэкапа, кодировка "ANSI"

Строчки SET NAMES нет ни в одном из дампов.

Записи о кодировках есть:
1.-2. в CREATE TABLE записи типа
) ENGINE=MyISAM DEFAULT CHARSET=cp1251 AUTO_INCREMENT=[xxx] ;
3. Много записей типа
) ENGINE=MyISAM DEFAULT CHARSET=cp1251 ;
# TD`ng_flood`cp1251_general_ci ;

Я выделил на примере на что обратить внимание. В дампе во первых в самом начале дампа и перед импортом каждой таблицы стоят команды "забыть" какая там кодировка была и установить свою - utf8 .
Вот файл обязан быть этой же кодировки по содержимому. И созданная база данных крайне желательно чтобы была в этой же кодировке.

У меня перед началом таблиц в 1-2 .sql есть только одна запись:
SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO";
а в 3. /sql вообще никаких записей перед таблицами нет,


Получается мне нужно в ручную прописать SET NAMES utf8 и сохранить файл в этой кодировке?

[Adamos]

Нет, у вас вполне типичный дамп базы, работающей в cp1251. PMA сохраняет этот дамп в UTF-8 по умолчанию, вне зависимости от кодировки базы.
При импорте файла тоже нужно выбрать кодировку UTF-8.

[Finnegan]

Нет, у вас вполне типичный дамп базы, работающей в cp1251. PMA сохраняет этот дамп в UTF-8 по умолчанию, вне зависимости от кодировки базы.
При импорте файла тоже нужно выбрать кодировку UTF-8.

В том-то и дело, что
- в phpMyAdmin ограничение размера <2 Mb, так что не могу загрузить ни один .msql
- в sxd могу загрузить созданный им же дамп.sql #3 в кодировке utf8, но текст на сайте все равно со знаками вопроса
- в adminer могу загрузить только .sql #2, но без указания кодировки (там только кнопка выбрать и выполнить) и если поверх выполнить бэкап, то все снова становится со знаками вопроса.

Получается замкнутый круг.

[baseq3]

Получается замкнутый круг.

пора доверить решение этого вопроса профессионалам
тут уже сто раз все обмылили как и что делать
все проблемы с sql файлом решаются в ultraedit
и с кодировкой и с размером

да и еще
у нормального хостера должны быть архивы сайта
их можно попросить в тех поддержке

Сообщение отредактировал baseq3 - 25.4.2017, 20:46

[WolF]

В том-то и дело, что
- в phpMyAdmin ограничение размера <2 Mb, так что не могу загрузить ни один .msql
- в sxd могу загрузить созданный им же дамп.sql #3 в кодировке utf8, но текст на сайте все равно со знаками вопроса
- в adminer могу загрузить только .sql #2, но без указания кодировки (там только кнопка выбрать и выполнить) и если поверх выполнить бэкап, то все снова становится со знаками вопроса.

Получается замкнутый круг.

Сложно вслепую что то советовать. Я бы сохранил файл дампа в кодировке 1251 через редактор так как сайт судя по всему работает именно с ней и попробовал бы импортировать через консольный mysql , запустив его через php. То есть написал бы простой php скрипт
<?php
system("/usr/bin/mysql -uпользователь -pпароль -Dбаза -hхост --default_character_set=cp1251 < /путь_к_сайту/дамп.sql");
?>
Залил бы на сайт и запустил бы в браузере. Скорее всего таким образом, если сделать все правильно, удастся корректно импортировать любой из дампов.