Author Archives: Pashaster

About Pashaster

Создатель и основной автор данного проекта. Профессиональный разработчик с 4-летним стажем.

Чтение файла в PHP. Выбираем оптимальный вариант

parser-fajla-phpПриветствую вас, друзья! :-)

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

Ничего в этом сложного нет, но иногда глаза разбегаются от обилия вариантов, предоставляемых средствами серверных языков. Если говорить конкретно о PHP, на котором я сейчас программирую, то с помощью его функций можно считывать содержимое файлов и построчно, и целиком в строку, и в массив, причём для последнего варианта существует ещё несколько способов… Вот такие пироги :-)

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

Поэтому, сегодня я продемонстрирую вам работу различных функций PHP для чтения файлов, чтобы, когда вам нужно будет создать PHP парсер файла для решения реальных задач, вы знали, из чего выбирать. А также подскажу, как именно в «боевых условиях» сделать правильный выбор.

Поехали! :-)

Создаём PHP парсер файла — начальные условия

Перед тем, как мы начнём, пару слов о задаче, для которой я создавал парсер файла на PHP, а затем выбирал из реализованных вариантов оптимальный.

Однажды у меня на работе возникла проблема, которая заключалась в том, что в БД хранились телефоны пользователей в неверном формате. Сам баг я, естественно, без проблем пофиксил.

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

Для этого мне был предоставлен текстовый файл с идентификаторами пользователей и их телефонами, которые нужно было перенести в БД.

Должен сказать, он получился весьма увесистым: 352 Кбайта и 8223 строки текста, в каждой из которых содержался идентификатор пользователя и его телефон в формате id_пользователя:номер_телефона.

Словом, вся задача заключалась в построчном чтении файла PHP средствами, выделения из строки идентификатора и телефона с последующим обновлением значения телефона у пользователя в БД, найденного по айдишнику.

Мой проект был реализован на PHP фреймворке Yii, следовательно в дальнейших примерах кода вы встретите элементы его API для работы с БД, в частности, поэтому не пугайтесь :-)

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

Ну, а после я расскажу, по каким критериям и как именно я выбирал среди них оптимальный вариант. И, естественно, поделюсь результатами :-)

Так что данная статья — отличная тренировка терпеливости :-) Суть её будет заключаться в подробном изучении следующего материала вплоть до результатов, которые будут ждать вас в конце. По ходу, кстати, можете поработать ещё и над фантазией, предполагая, как именно будет выбираться идеальный вариант.

Чтение файла в PHP построчно с помощью fgets()

Для того, чтобы прочитать файл построчно, в PHP есть специальная функция fgets(). Чтобы с её помощью считать содержимое всего файла, её нужно вызывать в цикле, проходясь по всем строкам.

В итоге, PHP парсер файла, реализующий данный алгоритм, у меня принял следующий вид:

<?php

$filename = "users.txt";

if (file_exists($filename) && is_readable($filename)) {
    $fh = @fopen($filename, "r");

    if ($fh) {
        while (($line = fgets($fh, 4096)) !== false) {
            if (!empty($line)) {
                $params = explode(':', $line);
                if (!empty($params[0]) && !empty($params[1]) && $params[1] != 'Fake') {
                    $client = Clients::model()->find('unique_id IN (:id1, :id2)', array(':id1' => strtolower($params[0]), ':id2' => strtoupper($params[0])));
                    if ($client) {
                        $client->phone = str_replace(array("\r", "\n"), "", $params[1]);
                        $client->save();
                    }
                }
            }
        }

        if (!feof($fh)) {
            echo 'Error: unexpected fgets() fail\n';
        }

        fclose($fh);
    }
    else echo "Check the filename, file doesn't exists!";
}

Немного расшифрую свою писанину, если у кого-то возникнут сложности в понимании.

В самом начале, переменной $filename присваивается значение имени файла, который будет парситься, с полным путём к нему. Далее следуют PHP проверка существования файла и читаем ли он с помощью функций file_exists() и is_readable() соответственно.

Если всё ОК, то открываем файл с помощью функции fopen(), которая вызывается с PHP оператором управления ошибками для того, чтобы отключить вывод ошибок, генерируемых данной функцией. Использовать я его решил, чтобы сгенерировать своё сообщение об ошибке вместо стандартного.

Если файл открыть получилось, то мы проходимся по всем его строкам в цикле, пока файл не закончится, и, если строка не пустая, разделяем её по символу двоеточия функцией explode().

Затем проверяем, что id пользователя и его телефон не пустые, ищем пользователя в БД по айдишнику и, если таковой существует, то обновляем ему номер телефона, убрав из значения номера предварительно символы переноса и начала новой строки.

Ну, и ещё я использовал PHP функции strtolower() и strtoupper() для проверки существования в БД пользователя с идентификаторами, которые могли быть прописаны в различных регистрах, т.к. они в моём случае состояли из символов и цифр.

Далее по коду следуют различные сообщения об ошибках, которые могут возникнуть на разных этапах, а также функция закрытия файла — fclose().

PHP парсинг файла в массив с помощью file()

Данный метод чтения файла в PHP предполагает использование функции file(), которая открывает файл и помещает его содержимое в массив. При этом элементами массива будут являться, как раз, строки считываемого файла, что в моей ситуации отлично подходит.

Код данного варианта PHP парсера файла получился следующий:

<?php

$filename = "users.txt";

if (file_exists($filename) && is_readable($filename)) {
    $lines = @file($filename);

    if (!empty($lines)) {
        foreach ($lines as $line) {
            if (!empty($line)) {
                $params = explode(':', $line);

                if (!empty($params[0]) && !empty($params[1]) && $params[1] != 'Fake') {
                    $client = Clients::model()->find('unique_id IN (:id, :id2)', array(':id' => strtolower($params[0]), ':id2' => strtoupper($params[0])));
                    if ($client) {
                        $client->phone = str_replace(array("\r", "\n"), "", $params[1]);
                        $client->save();
                    }
                }
            }
        }
    }
    else echo "Check the filename, file doesn't exists!";
}

Как видите, от предыдущего способа чтения файла в PHP данный отличается только своим началом, где файл открывается и сразу же считывается функцией file() вместо связки fopen() + fgets(), как ранее.

Далее код такой же.

PHP чтение файла в переменную с помощью fread()

Ещё одной функцией PHP для разбора файла является fread(), с помощью которой можно читать различные фрагменты файла указанной длины. Чтобы прочитать файл в PHP целиком, в качестве размера фрагмента я указал размер файла, полученный с помощью функции filesize():

<?php

$filename = "users.txt";

if (file_exists($filename) && is_readable ($filename)) {
    $fp = @fopen($filename, 'r');
    
    if ($fp) {
        $lines = explode("\n", fread($fp, filesize($filename)));
    }

    if (!empty($lines)) {
        foreach ($lines as $line) {
            if (!empty($line)) {
                $params = explode(':', $line);

                if (!empty($params[0]) && !empty($params[1]) && $params[1] != 'Fake') {
                    $client = Clients::model()->find('unique_id IN (:id1, :id2)', array(':id1' => strtolower($params[0]), ':id2' => strtoupper($params[0])));
                    if ($client) {
                        $client->phone = str_replace(array("\r", "\n"), "", $params[1]);
                        $client->save();
                    }
                }
            }
        }
    }
    else echo "Check the filename, file doesn't exists!";
}

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

Преобразование строки в массив на PHP проще всего сделать с помощью уже применявшейся сегодня функции explode(), в качестве разделителя в которую был передан символ начала строки.

А дальше всё идёт по накатанной :-)

Создаём PHP парсер файла на базе file_get_contents()

Ну, и напоследок, я решил реализовать PHP парсинг файла с помощью функции file_get_contents(), которая, как раз и предназначена для чтения файла целиком в строку, т.е. работает, практически, как fread($fp, filesize($filename)).

За тем лишь исключением, что file_get_contents() самостоятельно открывает файл и считывает его, в то время как для использования fread() нужно было предварительно открыть файл через fopen() и получить его указатель для дальнейшего использования.

В целом, код PHP парсера файла на базе file_get_contents() будет практически как и в предыдущем случае:

<?php

$filename = "users.txt";

if (file_exists($filename) && is_readable ($filename)) {
    
    $lines = explode("\n", file_get_contents($filename));

    if (!empty($lines)) {
        foreach ($lines as $line) {
            if (!empty($line)) {
                $params = explode(':', $line);

                if (!empty($params[0]) && !empty($params[1]) && $params[1] != 'Fake') {
                    $client = Clients::model()->find('unique_id IN (:id1, :id2)', array(':id1' => strtolower($params[0]), ':id2' => strtoupper($params[0])));
                    if ($client) {
                        $client->phone = str_replace(array("\r", "\n"), "", $params[1]);
                        $client->save();
                    }
                }
            }
        }
    }
    else echo "Check the filename, file doesn't exists!";
}

На этом всё. Пришло время подвести итоги производительности всех перечисленных вариантов и выяснить, какой же PHP парсер файла оказался самым оптимальным для дальнейшего использования.

Какой способ обработки файлов в PHP является оптимальным?

Чтобы выбрать из найденных вариантов самый оптимальный, т.е. самый быстрый, я решил определить время выполнения скрипта PHP в каждом случае. Для этого я воспользовался методикой, описанной в статье по ссылке.

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

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

Помню, когда я учился в школе и писал свою научную работу по физике (да, был такой опыт :-) ) на её защите перед университетскими преподавателями меня постоянно упрекали за недостаточное количество экспериментов (я делал по 3 опыта для каждого случая). «Светилы науки» называли цифры в 100, ну или, хотя бы, в 10 экспериментов для сравнения различных ситуаций, чтобы можно было делать какое-то их сопоставление и минимизировать вероятность случайного превосходства одного над другим.

Да, досталось мне тогда от них крепко, но их рекомендации я хорошо усвоил, что даже сейчас об этом помню, хотя прошло уже более 10 лет с тех пор. Тем более, что данные рекомендации действительно были основаны на законах математической статистики и теории вероятности.

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

В итоге, я решил ограничиться 10 экспериментами для каждого варианта PHP парсера файла, чего, как оказалось в итоге, оказалось вполне достаточно, чтобы выделить явного лидера без всякой подтасовки фактов и зацепок за сотые и тысячные доли секунды превосходства.

Результаты вычислений времени работы разработанных мною PHP парсеров файла представлены в следующей таблице и рассортированы по PHP функциям, на базе которых они работают.

Эксперимент fgets() file() fread() file_get_contents()
1 9,147 9,722 10,539 2,008
2 8,950 9,006 9,495 1,733
3 8,821 8,845 9,207 1,642
4 8,717 8,876 8,931 1,758
5 9,010 9,091 8,703 1,635
6 9,110 8,640 9,712 1,633
7 9,074 9,626 9,13 1,645
8 8,886 9,204 9,048 1,701
9 8,667 8,918 9,438 1,713
10 8,852 9,197 9,537 1,567
Среднее 8,923 9,113 9,374 1,704

Как видите, помимо значений времени выполнения скрипта в каждом из 10 экспериментов, я решил подсчитать среднюю температуру по больнице :-)

А именно, арифметическое среднее время работы каждого PHP парсера файла, чтобы можно было выявить лидера.

И им оказался, как видите, последний вариант, реализованный на базе функции file_get_contents(), который выполняет чтение содержимого файла в строковую переменную с дальнейшим его преобразованием в массив и обработкой в цикле.

Все остальные варианты PHP парсеров файлов работают примерно с одинаковой скоростью.

Почему именно он обогнал своих конкурентов я, если честно, не имею ни малейшего понятия. Могу лишь предположить, что операция чтения файла в строку с помощью file_get_contents() требует меньше ресурсов, чем формирование готового массива строк с помощью file().

А превосходство над fgets() и fread() можно списать на то, что перед их использованием требуется открытие файла с помощью fopen(), на что требуется время.

Да, на самом деле, это и не важно, т.к. цифры говорят сами за себя: благодаря использованию функции file_get_contents() PHP парсер файла на его базе работает в 5 раз быстрее остальных, что и повлияло на моё решение использовать его на практике.

Разбор файла в PHP — выводы

Как я уже и говорил в начале, мои опыты не являются безупречными и опираться исключительно на полученные в их ходе результаты не стоит, т.к., несмотря на быстродействие file_get_contents() в моей ситуации, бывают случаи, когда намного удобнее и эффективнее использовать другие приведённые мною PHP парсеры файлов.

Кроме того, не стоит забывать, что PHP сам по себе является синхронным языком программирования, т.е. все серверные операции происходят последовательно без возможности настройки их параллельного выполнения, в том числе, и на разных ядрах серверного процессора.

Следовательно, на время выполнения операций, прописанных в PHP коде, может влиять целый ряд факторов, среди которых основным является нагруженность ядра в момент работы PHP приложения.

Я это особенно ощутил во время проведения опытов, когда один и тот же PHP парсер файла отработал за 9, затем за 12, а потом снова за 9 секунд на трёх последовательных итерациях из-за банального запуска проводника Windows во время второго случая, который, естественно, тоже требует серверных ресурсов.

Учитывая данные особенности, я проводил эксперименты практически одновременно, друг за другом, при одинаковом комплекте запущенных программ, чтобы не распылять ресурсы серверного железа.

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

Если же вы будете работать с асинхронными серверными языками (C#, Java) или технологиями (Node.js, например), то, по возможности, для экспериментов создавайте отдельный поток, который будет работать на выделенном ядре процессора.

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

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

Подытоживая, хочу сказать, что приведённые в статье фрагменты кода могут использоваться не только для парсинга текстовых файлов в PHP, но и отлично подойдут для других форматов, например, для разбора CSV файлов дампа базы данных MySQL.

Пишите ваши отзывы, как положительные, так и отрицательные в комментариях под статьёй — мне необходимо любое ваше мнение для дальнейшего развития :-)

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

До новых встреч! :-)

Определяем время работы скрипта PHP

vremya-vypolneniya-skripta-phpДоброго времени суток, коллеги! :-)

Сегодня я решил затронуть такую тему, как время выполнения скрипта PHP и его определение.

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

Особенно часто за таким занятием можно застукать разработчиков, занимающихся рефакторингом кода и оптимизацией существующих алгоритмов, когда время выполнения PHP скрипта является ключевым фактором при выборе конечного варианта.

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

Поэтому я и решил написать данную коротенькую заметку, в которой решил изложить порядок действий в аналогичной ситуации.

Сперва мы рассмотрим сам алгоритм определения времени исполнения PHP скрипта, а затем я приведу код, с помощью которого он будет реализовываться.

Время выполнения PHP скрипта — алгоритм определения

Порядок наших действий будет предельно прост:

  1. определяем текущее серверное время в PHP коде перед выполнением действий, прописанных в скрипте;
  2. после того, как скрипт выполнится, снова узнаём серверное время;
  3. вычисляем средствами PHP разницу времени между завершением выполнения скрипта и его запуском.

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

Время работы PHP скрипта — реализация алгоритма

Для вывода текущего времени в PHP коде я решил воспользоваться стандартной PHP функцией microtime(), которая возвращает текущую метку времени в Unix формате с микросекундами.

Зачем такая точность?

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

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

Для демонстрации своих теоретических повествований я написал простенький скриптик, который вычисляет время прогона пустого цикла с 30 000 000 итераций (решил взять побольше для наглядности):

<?php

$start = microtime(true);

for ($i = 0; $i &lt;= 30000000; $i++)
{
    //ничего не делаем
}

echo 'Скрипт был выполнен за ' . (microtime(true) - $start) . ' секунд';

Как сказано в официальной документации PHP, по умолчанию microtime() возвращает строку в формате «msec sec», где sec — количество секунд с начала эпохи Unix (1 января 1970 0:00:00 GMT), а msec — это количество микросекунд, прошедших после sec.

Функция PHP microtime() имеет всего один параметр get_as_float, при указании которому значения true можно получить текущее время PHP в секундах, прошедших с начала эпохи Unix с точностью до микросекунд.

Поскольку мне нужно было именно текущее время, а не количество секунд с начала эпохи Unix, то я воспользовался данным параметром, что можно видеть в моём коде.

В итоге, с помощью функции echo(), на экран вывелось следующее сообщение: Скрипт был выполнен за 1.3156361579895 секунд.

Чтобы определить, что данная методика работает верно, я решил задать фиксированное время выполнения скрипта с помощью функции sleep(), которая делает задержку выполнения скрипта на указанное количество секунд.

В итоге, следующая конструкция вернула сообщение Скрипт был выполнен за 2.0000510215759 секунд:

<?php

$start = microtime(true);

sleep(2);

echo 'Скрипт был выполнен за ' . (microtime(true) - $start) . ' секунд';

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

Если они будут всё-таки раздражать вас или вашего заказчика, то можете воспользоваться хаком в виде банального округления до сотых или тысячных долей с помощью PHP функции round(), задействовав её следующим образом:

round(microtime(true) - $start, 2);

Результатом выполнения данного куска кода для вышеприведённого примера станет значение в кругленькие 2 секунды, что устроит самых искушённых перфекционистов :-)

На этом сегодняшняя информация о том, как можно определить время выполнения скрипта PHP, подходит к концу.

Пишите свои отзывы в комментариях и задавайте интересующие вас вопросы в пабликах проекта в социальных сетях.

Всем удачи и до новых встреч! :-)

Работа с MySQL в OpenServer: ключевые особенности

openserver-mysqlПриветствую вас, друзья! :-)

Сегодня у нас на повестке дня снова любимая многими (и мной, в том числе) WAMP сборка OpenServer и MySQL, который входит в её комплект.

С данным ПО, а также его особенностями, я впервые познакомил читателей данного блога в одной из своих первых статей, посвящённой программам для создания сайтов.

Идея о создании сегодняшней статьи появилась у меня во время написания публикаций о работе с MySQL в консоли, при работе с которой у OpenServer есть свои тонкости.

Кроме того, на практике достаточно часто появляются ситуации, когда нужно изменить настройки MySQL сервера и произвести отладку операций с базой по логам. В таких случаях при работе с OpenServer у начинающих пользователей обычно возникает много вопросов (как у меня в своё время).

Поэтому сегодня вас будут ждать ответы на них :-)

А также я кратенько пройдусь по инструментам для работы с БД MySQL в OpenServer, которые предоставляют удобный графический интерфейс для манипулирования данными, и краем слова затрону работу с MySQL в консоли OpenServer.

Одним словом, сегодня вас ждёт обзор полного цикла работы с MySQL при использовании OpenServer.

Поехали :-)

Выбор версии MySQL в OpenServer

Особенностью OpenServer является то, что в его комплект входит не только множество различных серверных компонентов, но и различные их версии.

Это, нужно сказать, весьма удобно, т.к. в некоторых случаях нужно использовать устаревшее ПО для локального разворачивания legacy проектов (очень-очень старых), которые нужно саппортить.

И в то же время, для старта новых проектов необходимо будет использовать всё свеженькое :-)

Вот тогда-то нам как раз и пригодится переключение версий MySQL, чтобы была возможность работать с различными проектами при использовании одного дистрибутива OpenServer, а не устанавливать под каждый отдельный.

Итак, чтобы выбрать необходимую версию MySQL в OpenServer, после запуска программы нажимаем на значок в трее и выбираем пункт главного меню Настройки:

openserver-nastrojki-mysql

После этого на экране появится следующее окно, в котором нужно будет перейти на вкладку Модули:

openserver-mysql-vybor-versii

И здесь в выпадающем списке со значениями поля MySQL/MariaDB выбираем необходимую версию MySQL либо MariaDB, которая, как известно, является форком (от англ. fork — ответвление) MySQL, работа с которой ничем не отличается от своего родителя.

Даже инструменты одинаковые :-)

После выбора версии на экране появится окно о перезагрузке OpenServer, которая нужна для того, чтобы изменения вступили в силу.

Перезапускаемся и можно работать с новой версией.

В данном меню, помимо выбора необходимой версии MySQL, можно, кстати, и вовсе отключить использование данной СУБД при работе с OpenServer. Как это сделано, например, с PostreSQL в OpenServer по умолчанию.

Данное действие рекомендуется при использовании других СУБД для исключения возможных взаимных  конфликтов при их одновременной работе и снижения нагрузки на сервер в целом.

Важным моментом при использовании нескольких версий MySQL и прочих серверных компонентов, входящих в состав OpenServer, одновременно является необходимость конфигурирования каждой версии отдельно.

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

А также база данных, созданная при использовании MySQL 5.7, например, не будет доступна при работе с MySQL 5.5.

Поэтому, прошу учесть данный факт и не удивляться сбросу ваших настроек и пропаже БД. Однако, не волнуйтесь, ваши данные не пропали ,tccktlyj.

При выборе в качестве текущей версии MySQL той, которую вы тщательно настраивали и для которой создавали ваши базы, всё вернётся обратно :-)

Настройки логов MySQL в OpenServer

Достаточно часто при поиске различных багов, да и просто для отслеживания операций с БД, нужен доступ к файлам логов MySQL сервера.

Просмотреть логи MySQL, работающего в составе OpenServer, можно двумя способами: через интерфейс OpenServer и путём открытия файлов логов, хранящихся на жёстком диске.

Для первого способа нужно открыть знакомое меню управления OpenServer кликом любой кнопкой мыши на значке OpenServer в трее и выбрать пункт Просмотр логов, после чего на экране появится следующее диалоговое окно:

openserver-mysql-logi-servera

По умолчанию OpenServer ведёт запись только ошибок и событий на самом сервере MySQL, что можно увидеть на скриншоте выше.

Однако, что же делать, если нужен список SQL запросов к базам данных, расположенных на сервере?

Благо, что OpenServer предоставляет возможность расширенного логгирования, при активации которой запросы к БД будут писаться в отдельный лог.

Чтобы включить ведение логов запросов к серверу MySQL в OpenServer, нужно произвести знакомые уже нам сегодня действия: Меню управления OpenServer -> Настройки -> Модули.

И возле выпадающего списка со значениями поля MySQL/MariaDB устанавливаем галочку вести лог запросов:

openserver-mysql-rasshirennoe-loggirovanie

После установки галочки нужно сохранить настройки и подтвердить перезагрузку сервера, в результате чего у нас в окне с логами OpenServer добавляется ещё одна вкладочка с названием MySQL запросы:

openserver-mysql-logi-zaprosov

От себя хочу добавить, что решение разработчиков разделить логгирование MySQL данным образом весьма мудрое и удобное.

Во-первых, позволяет разгрузить сервер от записи ненужных в большинстве случаев логов (поэтому, собственно говоря, логи запросов и не пишутся по умолчанию). А, во-вторых, запись логов в отдельные файлы позволяет рассортировать хранимую в них информацию по назначению.

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

Тогда инструмент просмотра логов OpenServer становится бесполезным, т.к. никаких средств поиска он не предоставляет, а просматривать все записи в поисках нужно — занятие очень долгое и бесперспективное.

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

Файлы логов OpenServer, в том числе и MySQL, расположены в директории директория_установки_openserver/userdata/logs, которая в моём случае выглядит вот так:

openserver-mysql-logi-v-kataloge

На скриншоте я отметил файлы логов моей текущей версии MySQL: состояния сервера и запросов к нему. Также здесь доступны все остальные логи, ведущиеся OpenServer.

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

Настройка MySQL в OpenServer

О выборе необходимой версии MySQL для работы и записи логов в OpenServer мы поговорили. Ещё одним моментом, который достаточно часто встречается на практике, является необходимость настройки MySQL в OpenServer для корректной работы и выполняемых ею функций на определённых проектах.

Настройка MySQL заключается в добавлении/удалении и изменении существующих параметров конфигурации, содержащихся в специальных файлах — конфигах.

Чтобы получить доступ к конфигам MySQL, достаточно запустить знакомое меню управления OpenServer, выбрать пункт Дополнительно, а в выпадающем списке выбрать Конфигурация.

После этого появится ещё одно меню, в котором будут содержаться ярлыки для доступа к файлам конфигурации текущих модулей OpenServer, выбранных на вкладке Настройка, где мы меняли версию MySQL:

openserver-mysql-nastrojki-komponenta

При выборе ярлыка конфига MySQL откроется соответствующий файл в текстовом редакторе, установленном на вашем ПК в качестве основного.

Если же вам потребуется доступ к самому файлу конфигурации MySQL, то вы можете найти его в директории директория_установки_openserver/userdata/config, в которой расположены конфиги всех модулей OpenServer, причём, для каждой версии компонента конфиг отдельный.

При работе с конфигами серверных компонентов стоит учитывать, что для сокращения их текста и удобства использования в их тексте встречаются специальные переменные OpenServer, с полным списком и значениями которых вы можете ознакомиться здесь — https://ospanel.io/docs/#rabota-s-path

А также имейте ввиду, что после любых изменений в файлах настроек MySQL в OpenServer, для вступления их в силу нужно будет после сохранения файла перезапустить сервер.

Инструменты для работы с MySQL в OpenServer

О выборе версий MySQL в OpenServer и их настройке мы поговорили. Теперь самое время перейти к работе с базами данных, пользователями и прочими объектами, создающимися на сервере MySQL.

А для этого в комплекте OpenServer существует целый набор инструментов, обладающих графическим интерфейсом. Поэтому, если вы не являетесь трушным кодером, но, тем не менее, вам нужно будет создать базу MySQL в OpenServer или поменять пароль пользователя, то использование графических редакторов — это самый лёгкий и простой способ сделать задуманное.

Ну, и консоль OpenServer никто не отменял для работы с командной строкой MySQL.

Визуальные инструменты представлены различными утилитами, доступ к которым можно получить из меню OpenServer, при выборе пункта Дополнительные:

openserver-mysql-graficheskie-instrumenty

На скриншоте выше я выделил утилиты для работы с MySQL, которые содержатся в OpenServer по умолчанию.

Первые две предназначены исключительно для работы с MySQL базами данных, а последняя является универсальной (через неё можно работать в различными СУБД).

Следовательно, при отключении использования модуля MySQL в OpenServer, phpMyAdmin и MySQL менеджер исчезнут из  данного списка вовсе, а SQLite менеджер останется, но работать с MySQL сервером через него будет невозможно.

Кратко рассмотрим каждый инструмент и особенности работы с ним в OpenServer.

phpMyAdmin

Знакомая многим утилита, написанная на языке PHP для администрирования исключительно MySQL серверов, которой предпочитают пользоваться как новички, так и профессионалы. Предоставляет визуальный интерфейс для работы с сервером MySQL, через который очень легко управлять базами, пользователями и их правами.

После запуска из меню OpenServer phpMyAdmin запустится либо в открытом окне вашего браузера, либо в отдельном окне.

Честно говоря, я затрудняюсь ответить, от чего это зависит. На одном ПК у меня phpMyAdmin из комплекта OpenServer запускается в открытом окне, а на другом — в отдельном.

После успешного запуска phpMyAdmin  будет выглядеть так:

openserver-mysql-phpmyadmin-privetstvie

Это стартовый экран, на котором нужно ввести имя пользователя MySQL и его пароль для подключения к серверу. По умолчанию (если кто не в курсе) админская учётка root/пустой_пароль.

Вводим, входим, работаем :-)

openserver-mysql-phpmyadmin-interfejs

Я не буду сейчас приводить полный перечень возможностей phpMyAdmin, т.к. для этого есть специализированные публикации и видеопособия, которых уже полно в Интернете. Если вы совсем новичок, то можете воспользоваться следующим видео в качестве отправной точки:

По поводу особенностей работы с phpMyAdmin в OpenServer могу отметить возможное возникновение следующей ошибки, с которой я столкнулся при переключении версий MySQL:

Ошибка

SQL запрос: SET lc_messages = 'ru_RU';

Ответ MySQL: #1193 - Unknown system variable 'lc_messages'

Причиной её возникновения стал выбор версии MySQL 5.1, в которой, как выяснилось после изучения статей в Интернете, отсутствует системная переменная lc_messages, установку которой phpMyAdmin пытается произвести.

Она появилась в MySQL 5.5, при установке которой, по идее, проблема должна была исчезнуть… Однако, ничего подобного, к моему великому удивлению, не произошло :-)

После изменения версии MySQL и перезапуска сервера ошибка продолжала раздражать своим наличием.

Причина оказалась в банальном кэше браузера, при очистке которого phpMyAdmin заработал в штатном режиме.

Если же мои рекомендации в вашем случае не помогут, то можете воспользоваться этим советом — https://github.com/phpmyadmin/phpmyadmin/issues/12822.

phpMyAdmin — штука удобная для работы с локальным MySQL сервером.

Однако, иногда бывают ситуации, когда нужно подключаться к различным серверам MySQL, устанавливать специализированное ПО либо сложно, либо вообще невозможно (например, в компаниях с большими требованиями к сетевой и информационной безопасности).

Благо, что для таких случаев в комплекте OpenServer есть другие инструменты для работы с различными серверами MySQL.

MySQL менеджер

При выборе пункта меню OpenServer MySQL менеджер запускается программа HeidiSQL, с детальным описанием которой можете здесь — https://www.heidisql.com/

Не знаю, почему его переименовали, видимо, для упрощённого понимания пользователей, что их ждёт после запуска :-)

Данной утилитой я сам активно пользуюсь на своей основной работе, чтобы не устанавливать различное дополнительное ПО. Запустить её можно из того же пункта меню OpenServer, что и phpMyAdmin.

Запуск HeidiSQL немного отличается от phpMyAdmin по той причине, что это desktop программа, а не веб-приложение, поэтому оно всегда будет открываться в отдельном окне.

После запуска вы увидите на экране форму подключения к серверу MySQL, которая выглядит следующим образом:

openserver-mysql-menedzher-soedinenie

Для демонстрации возможностей я сделал тестовое подключение к локальному MySQL серверу, после выбора которого откроется данное окно:

openserver-mysql-menedzher-interfejs

Оно уже представляет из себя, собственно говоря, панель администратора для работы с сервером MySQL, в которой можно управлять базами данных, их таблицами, индексами, триггерами и прочими сущностями.

Для примера на скриншоте выше я создал тестовую БД и открыл меню управления ею, где выбрал создание таблицы.

В принципе, достаточно удобно. Многим, возможно, понравится даже больше привычного phpMyAdmin — это уже дело вкуса :-)

Но лично я использую MySQL менеджер OpenServer только для удалённых подключений. С локальным сервером предпочитаю всё-таки больше первый вариант.

SQLite менеджер

Ещё один графический клиент для работы с MySQL в OpenServer. Под данным названием, как и в предыдущем случае, скрывается утилита с совершенно другим названием — Adminer, с детальным описанием которой можете познакомиться здесь — https://www.adminer.org.

Возможно, старожилам Интернетов данная утилита будет знакома ещё по названию phpMinAdmin :-)

Создатели OpenServer решили переименовать её в SQLite менеджер, скорее всего, из соображений, что данная утилита единственная из всего комплекта OpenServer, которая позволяет работать с СУБД SQLite, которая всё ещё пользуется определённым спросом в узких кругах.

Запуск данной утилиты очень похож на phpMyAdmin и так же непредсказуем: она может открыться как в открытом окне браузера, так и оказаться в отдельном.

На экране сперва вы увидите форму соединения, которая выглядит так:

openserver-mysql-sqlite-menedzher-avtorizaciya

По данной форме сразу видно большое преимущество Adminer над phpMyAdmin, т.к. он позволяет подключаться не только к локальному серверу MySQL, но и к удалённым, а также он поддерживает работу не только с MySQL, но и с другими СУБД, среди которых:

  1. PostgreSQL
  2. SQLite
  3. MS SQL
  4. Oracle
  5. Firebird
  6. SimpleDB
  7. Elasticsearch
  8. MongoDB

Список очень солидный, должен сказать :-) Кроме этих преимуществ у данной программы есть ещё и возможность легко и просто менять скины, которые оформлены обычными CSS файлами, следовательно, править их может любой желающий, который хоть немного обладает знаниями данного языка.

Вот так выглядит панель управления сервером MySQL в Adminer после подключения к нему с использованием default скина:

openserver-mysql-sqlite-menedzher-rabota-s-serverom

Да, согласен, выглядит простовато, но зато и работает быстрее phpMyAdmin, с которым очень любят сравнивать своё произведение создатели экс-phpMinAdmin. Но опять же, это при настройках по умолчанию.

Как я уже и говорил, всё это решается сменой скинов.

Работа с MySQL в консоли OpenServer

Инструменты, предоставляющие графический интерфейс для работы с MySQL, и которые входят в комплект OpenServer, мы с вами рассмотрели.

Однако, бывают случаи, когда их использование не совсем удобно.

Например, при импорте базы данных MySQL большого размера, которую весьма затруднительно залить через графические утилиты, тот же самый phpMyAdmin, который постоянно прерывает процесс при достижении внутренних лимитов ПО и языка PHP, на котором инструмент разработан.

Чтобы начать работать с командной строкой MySQL в консоли сервера, можно воспользоваться как консолью Windows, так и консолью, входящей в состав OpenServer, которая находится в одном меню с графическими инструментами для работы с MySQL:

openserver-konsol-zapusk-komandnoj-stroki-mysql

Либо можете воспользоваться ещё какой-либо другой (например, встроенной в IDE).

Если вы не устанавливали MySQL на компьютер глобально и не создавали соответствующий сервис, который можно запустить из консоли, то можете воспользоваться командными строками MySQL дистрибутивов, имеющихся на OpenServer.

Для этого в консоли переходим в каталог с необходимым дистрибутивом MySQL из поставки OpenServer с помощью следующей команды:


cd директория_установки_openserver/modules/database/MySQL-5.7-x64/bin

Директорию установки OpenServer и дистрибутив MySQL пропишите актуальные в вашем конкретном случае.

После этого можно пользоваться командной строкой MySQL с помощью одноимённой утилиты mysql, а также другими, входящими в комплект дистрибутива.

Протестить возможность их успешного запуска можете командой, проверяющей версию MySQL:


mysql -V

Со списком остальных команд консоли MySQL вы можете в статье по предоставленной ссылке.

На этом сегодняшняя публикация о работе с MySQL в OpenServer подходит к концу. Я постарался осветить все основные моменты, которые могут возникнуть в процессе работы, а что у меня из этого вышло — решать вам.

В завершение хочу добавить, что Максим Архипов, разработав OpenServer, сделал действительно большое дело, сэкономив литры кофе и часы времени для сна разработчикам.

Поэтому, если вы пользуетесь OpenServer, то отвечайте ему взаимностью, делая пожертвования, которые являются единственным средством финансирования проекта, т.к. распространяется он абсолютно бесплатно.

P.S. не жалейте денег, они обязательно к вам вернутся и даже в бОльшей степени, если вы потратите их с чистым сердцем. Это я уже проверил на себе :-)

Из пожертвованных мною 300 рублей 200 мне вернулись через пару дней в виде таких же добровольных пожертвований одного из посетителей данного блога за мою помощь ему в вопросах, связанных с Laravel.

И ещё… Пишите ваши отзывы в комментариях: что понравилось, что нет, о чём хотели бы прочитать ещё. Я всегда открыт для ваших предложений :-)

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

Всем удачи и до новых встреч! :-)

Перевод WordPress на HTTPS: 2 способа

perekhod-wordpress-na-httpsПриветствую вас, друзья! :-)

Я уже достаточно рассказал о том, что такое HTTPS и особенностях использования данного протокола, а также о том, что такое SSL сертификат, как его выбрать и какими они вообще бывают.

В предыдущих статьях я детально рассмотрел основные этапы установки SSL сертификата на сайт и переезда на HTTPS в целом, некоторые из которых обладают существенными нюансами в зависимости от платформы, на которой разработан ваш ресурс.

Решить данный обзор тонкостей я решил с самой массовой и популярной CMS на сегодняшний день — с WordPress.

Поэтому сегодня будет рассмотрен конкретно переход WordPress на HTTPS, а также перечень необходимых мер и инструментов, которые понадобятся нам в процессе.

Как перевести WordPress на HTTPS: вступление

Перед тем, как мы начнём, пару слов о том, с чем я буду работать в данной статье для демонстрации своих действий.

В предыдущей статье я рассказывал о том, как создать поддомен сайта, в рамках которой был зарегистрирован поддомен данного сайта ssl.cccp-blog.com, задумывавшийся изначально как раз как площадка для экспериментов с установкой и настройкой SSL сертификатов на сайт (отсюда и такое название).

Поскольку WordPress оказался первой платформой, с которой я решил начать свои эксперименты, то на данный домен я установил самую последнюю версию чистого движка, которая на данный момент 4.9.1.

В качестве графического шаблона я решил использовать стандартную тему Twenty Seventeen.

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

Теперь можно приступать непосредственно к переходу WordPress с HTTP на HTTPS, что мы сделаем сегодня двумя способами: с помощью плагина и без него.

Итак, начнём с самого простого варианта настроек HTTPS для WordPress сайта, который подойдёт абсолютному большинству и потребует минимум знаний — с установки плагинов, которые всё сделают за нас :-)

Перевод WordPress на HTTPS с помощью плагина

Для настройки HTTPS на WordPress сайте существует масса готовых решений в виде плагинов. С некоторыми из них я вас уже знакомил в статье о мерах по безопасности WordPress сайтов.

Сегодня же наглядно продемонстрирую использование одного из них для установки SSL сертификата на WordPress сайт с дальнейшей настройкой защищённого соединения.

Я решил остановиться на Really Simple SSL. Выбор мой был основан на статистике данного WordPress HTTPS плагина: более 600 000 скачиваний и оценка 5 из 5 на основании 333 оценок пользователей.

Ознакомиться с полным описанием решения, а также скачать его вы можете здесь — https://ru.wordpress.org/plugins/really-simple-ssl/

Разработчики утверждают, что плагин определяет SSL сертификат, установленный на сервере, в имени которого был указан текущий сайт. А затем он подключает его и делает перенаправление запросов с HTTP адресов на HTTPS.

Причём, всё это происходит путём нажатия на одну-единственную кнопку в течении нескольких секунд.

Чтобы убедиться, что это на самом деле так, для начала заходим в админку сайта и устанавливаем плагин Really Simple SSL любым известным вам способом. Более подробно о том, как можно сделать установку плагинов WordPress, написано в статье по указанной ссылке.

После установки активируем плагин, после чего на экране у нас появится следующее сообщение:

wordpress-redirekt-na-https

Здесь, как видите, разработчики говорят о необходимости изменения хардкодных ссылок в тексте сайта WordPress с HTTP на HTTPS.

В частности, в CSS и JavaScript файлах, но они могут встречаться и в других местах, например, в тексте статей, который хранится в базе данных.

Чтобы туда добраться, есть два способа: использовать сторонние утилиты и скрипты для работы с БД или командную строку WordPress, которая доступна после установки утилиты WP-CLI.

Если вам по душе первый способ, то могу порекомендовать PHP скрипт Search Replace DB, который предоставляет графический интерфейс для работы с БД и поиска в ней информации с дальнейшей заменой.

Если же вы трушный кодер и любите консоль, то в WP-CLI вам потребуется следующая команда:

wp search-replace "//ваш_сайт.com" "https://ваш_сайт.com"

В прочем, всё это не обязательно делать прямо сейчас и вполне можно отложить на потом. А пока вернёмся к настройкам нашего WordPress HTTPS плагина и сообщению об их активации.

После нажатия на кнопку с надписью Go ahead, activate SSL! в информационном окне плагин произвёл на сайте необходимые настройки для активации соединения по HTTPS. В частности, он добавил в wp-config.php следующий код в самое начало файла:

//Begin Really Simple SSL Load balancing fix
$server_opts = array("HTTP_CLOUDFRONT_FORWARDED_PROTO" => "https", "HTTP_CF_VISITOR"=>"https", "HTTP_X_FORWARDED_PROTO"=>"https", "HTTP_X_FORWARDED_SSL"=>"on", "HTTP_X_FORWARDED_SSL"=>"1");

foreach( $server_opts as $option => $value ) {
    if ( (isset($_ENV["HTTPS"]) && ( "on" == $_ENV["HTTPS"] )) || (isset( $_SERVER[ $option ] ) && ( strpos( $_SERVER[ $option ], $value ) !== false )) ) {
        $_SERVER[ "HTTPS" ] = "on";

        break;
    }
}
//END Really Simple SSL

Т.е. он установил глобальную серверную переменную HTTPS в «on» для дальнейших проверок в коде на предмет, передаёт ли сайт информацию по HTTPS или нет. Также плагин поменял адрес сайта с учётом нового протокола.

На этом наша работа подошла к концу :-) Т.е. для активации перевода WordPress на HTTPS нам действительно потребовалось нажать лишь одну-единственную кнопку.

После этого я решил подробно изучить настройки Really Simple SSL в админке WordPress, которые выглядят следующим образом:

pereadresaciya-https-wordpress

Как видите, вся конфигурационная панель состоит из трёх вкладок: Конфигурация, Настройка и Отладка. На первой из них, которая открывается по умолчанию, содержатся индикаторы состояния различных настроек HTTPS на WordPress сайте.

Здесь же вы увидите сообщения о критических ошибках, если таковые будут найдены.

Вкладка «Настройка» имеет следующий вид:

kak-perevesti-wordpress-na-https

Здесь расположены все основные настройки HTTPS соединения с сайтом, осуществляемые данным плагином. Стоит сказать, что они, как и само решение, невероятно просты и понятны.

По умолчанию включены опции автоматического устранения ошибок «смешанного содержимого», которые могут возникать при наличии на страницах сайта ссылок одновременно на HTTP и HTTPS адреса.

Также установлен редирект с HTTP на HTTPS на WordPress уровне и JavaScript. Как видите, плагин позволяет выполнить перенаправление различными способами.

На практике достаточно WordPress редиректа на HTTPS, JavaScript сами разработчики рекомендуют использовать в самую последнюю очередь, если остальные варианты перенаправлений не будут работать.

И это весьма логично, т.к. WordPress переадресация на HTTPS в JS коде будет медленнее остальных и будет содержаться в клиентском коде, загружаемом в браузер ваших пользователей, где может быть изменён.

Разработчики Really Simple SSL рекомендую использовать редирект с HTTP на HTTPS на уровне веб-сервера Apache, который производится при установке соответствующей галочки в настройках.

При этом плагин добавит следующий код в .htaccess файл вашего сайта:

# BEGIN rlrssslReallySimpleSSL rsssl_version[2.5.23]

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>

# END rlrssslReallySimpleSSL

Также на данной странице настроек плагина имеется поле Stop editing the .htaccess file, в котором нужно поставить галочку, если вы захотите отредактировать код, добавляемый плагином в .htaccess, чтобы ваши изменения не перезаписались значениями по умолчанию.

И ещё здесь имеется поле Отладка, при установлении галочки в которое вы сможете получить лог действий, выполняемых плагином. Лог можно увидеть на соседней вкладке настроек с одноименным названием, которая выглядит так:

ustanovka-wordpress-https

После того, как наш WordPress сайт был настроен для работы по HTTPS протоколу с помощью данного плагина, в панели администратора WordPress у нас появится следующее информационное сообщение:

wordpress-https-plugin

В нём говорится о том, что нужно произвести необходимые настройки в Google Analytics и Google Webmaster, суть которых заключается в добавлении нового адреса сайта для индексации его содержимого.

О том, как это сделать, можете узнать из инструкции от разработчика плагина Really Simple SSL. Или же воспользоваться официальной инструкцией от Google.

То же самое нужно сделать и в других инструментах аналитики, которыми вы пользуетесь: LiveInternet, Яндекс.Метрика и т.д.

После этого заходим на сайт – и, о чудо, он уже работает по HTTPS, о чём сигнализирует зелёный замочек в браузере. Причём, он присутствует не только возле URL главной страницы, но и на любой другой, которая раньше была доступна только по HTTP.

Даже если вбить в адресную строку браузера прямой URL страницы сайта, содержащий протокол HTTP, произойдёт мгновенное перенаправление запроса на HTTPS адрес.

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

Чтобы убедиться, что переход WordPress на HTTPS произошёл и успешно завершился, я для уверенности просмотрел SSL сертификат, использующийся сайтом для работы по HTTPS протоколу, в браузере (пользуюсь Google Chrome):

kak-ustanovit-ssl-sertifikat-na-sajt-wordpress

Всё верно, данные сертификата отобразились корректно (на данный момент в сертификате содержится только дата оформления и регистратор).

На этом переезд WordPress на HTTPS с помощью плагина Really Simple SSL торжественно объявляю закрытым :-)

Переход WordPress на HTTPS без плагинов

Однако, среди пользователей и разработчиков WordPress сайтов есть определённая категория лиц, которая люто презирает использование плагинов, предпочитая делать всё своими руками путём изменения кода сайта.

К таковым отношусь и я :-) Поэтому после успешного перехода WordPress на HTTPS с помощью плагина, который был описан выше, я решил удалить его и повторить успех уже без него, чем сейчас с вами и поделюсь.

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

Самый простой способ это сделать — через панель администратора. Заходим в Настройки > Общие и меняем в адресе сайта протокол HTTP на HTTPS:

wordpress-https-nastrojka

Данный шаг нужен для того, чтобы корректно открывались ссылки на страницы сайта, указанные в относительном формате.

Кстати! Если где-либо на вашем сайте имеются ссылки в абсолютном формате, прописанные через HTTP протокол, замените их на HTTPS-аналоги.

Также изменить адрес сайта и его главной страницы можно путём изменения файла wp-config.php, добавив в него следующие директивы:

define('WP_HOME', 'https://имя_сайта');
define('WP_SITEURL', 'https://имя_сайта');

Также в этот же файл необходимо будет добавить следующий код:

define ('FORCE_SSL_ADMIN', true);

Данная константа необходима для того, чтобы заставить все логины и все сеансы администратора выполняться через SSL. Размещать её следует перед тем, как подключается файл wp-settings.php в коде wp-config.php.

Также в редактируемом нами файле при использовании предыдущей конструкции нужно будет добавить следующий код:

if (strpos ($ _ SERVER ['HTTP_X_FORWARDED_PROTO'], 'https')! == false) {
    $ _SERVER [ 'HTTPS'] = 'on';
}

Примерно то же самое добавлялось и при переходе WordPress на HTTPS с помощью плагина Really Simple SSL. А также о данном действии упоминается в руководстве для разработчиков WordPress по управлению сайтом через SSL.

Как там объясняется, если WordPress размещен за обратным прокси-сервером, который предоставляет SSL, но сам размещен без SSL, FORCE_SSL_ADMIN сначала отправит любые запросы в бесконечный цикл переадресации.

Чтобы этого избежать, нужно настроить WordPress для распознавания заголовка HTTP_X_FORWARDED_PROTO (при условии, что вы правильно настроили обратный прокси для установки этого заголовка).

На этом действия в wp-config.php закончены, равно как и на самом WordPress сайте.

Для следующего шага нам потребуется правка конфигурационных файлов веб-серверов Apache или Nginx, через которые наш сайт запускается. Нужно будет прописать правила для 301 редиректа запросов c HTTP на HTTPS адреса.

Для Apache можете смело взять код, который добавляется плагином Really Simple SSL в .htaccess, приведённый мною ранее.

Для Nginx воспользуйтесь кодом, приведённом в статье о переезде на HTTPS, где помимо данного кода вы найдёте подробную инструкцию, работающую для всех сайтов без исключения, а также обзор последствий перехода сайта на HTTPS и способов их нейтрализации.

На этом лично мои действия касательно того, как перейти на HTTPS на ВордПресс, поскольку сайт был новый, закончились. Если же вы будете устанавливать SSL сертификат на WordPress сайт с историей и имеющий большой объём трафика из поисковых систем, то вам потребуется произвести ещё некоторые манипуляции, чтобы не потерять своих пользователей и позиции.

Как этого добиться, подробно описано в публикации с пошаговой инструкцией по переезду на HTTPS, ссылку на которую я приводил ранее в тексте.

На моём же тестовом сайте ssl.cccp-blog.com, как я уже сказал, все действия по установке HTTPS на WordPress ограничились двумя пунктами, чего вполне достаточно для исправной работы сайта, в чём вы сами можете убедиться, перейдя на него.

Как видите, процесс установки SSL сертификата на WordPress сайт достаточно прост и займёт у вас от силы пару минут. Причём, это касается как использования плагина, как и произведения действий без него.

Напоследок, традиционно, если вы всё-таки далеки от IT-шных терминов и не горите желанием в них вникать, рекомендую вам воспользоваться плагином и сэкономить свои нервы и время. Если же вы начинающий или опытный разработчик, то raw code — ваш вариант :-)

Не только скилл поднимите, но и получите навыки, которые помогут вам при переводе сайтов, разработанных на других платформах, на HTTPS. А как это сделать более детально для OpenCart и моего любимого Laravel, я, думаю, напишу в дальнейших публикациях.

Поэтому рекомендую вам подписаться на уведомления проекта, чтобы быть в курсе выхода нового материала, напоминания о чём будут приходить вам на электронную почту.

На этом сегодняшняя статья подошла к концу. Если она вам понравилась, делитесь ей со своими друзьями с помощью кнопочек социальных сетей под статьёй и ставьте оценки звёздочками.

Также не забывайте писать в комментариях о том, что понравилось, не понравилось и о том, что я, может быть, забыл упомянуть.

Очень рассчитываю на качественный фидбэк :-)

До новых встреч!

Как установить SSL сертификат: пошаговая инструкция

ustanovka-ssl-sertifikataПриветствую вас, друзья! :-)

В сегодняшней статье будет рассмотрена установка SSL сертификата. Мы поговорим о том, как создать SSL сертификат самому и подключить его к сайту для осуществления обмена информацией с пользователями по защищённому протоколу HTTPS.

Сразу скажу, что установить SSL сертификат на сайт можно двумя путями: через интерфейс панели управления сервером и с помощью ручного копирования файлов сертификата с последующими настройками веб-сервера (Apache или Nginx) в случае, если ваш хостинг не имеет графической панели управления.

Информация по установке SSL сертификата будет представлена в виде пошаговой инструкции, при составлении которой я воспользовался первым способом и своим хостингом TheHost, к панели управления которого (используется ISPManager) у меня есть доступ.

TheHost позволяет как устанавливать SSL сертификаты, приобретённые у него, так и выполнять подключение SSL сертификата, приобретённого у других поставщиков.

Также в панели управления хостингом есть возможность сделать бесплатный SSL сертификат от Let’s Encrypt и самоподписанный с последующей их установкой.

Все эти варианты мы сегодня и рассмотрим, т.к. на практике случаются разные ситуации, для которых бывают нужны различные типы SSL сертификатов безопасности.

Поехали :-)

Как установить SSL сертификат на сайт: этапы

Надеюсь, на данный момент вы уже определились с тем, что такое SSL сертификат и какой он бывает.

Если говорить о том, как подключить SSL сертификат к сайту, то весь процесс состоит из нескольких этапов:

  1. Генерация SSL сертификата. Заключается в создании самоподписанного сертификата на сервере самостоятельно либо в формировании запроса на выпуск данного документа в центр сертификации (CA).
  2. Установка SSL сертификата на хостинг.
  3. Подключение SSL сертификата к сайту.

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

Итак, рассмотрим каждый этап подробнее, начиная с создания SSL сертификата.

Создание SSL сертификата

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

Для этого регистрируемся на сайте thehost.ua, после чего вам на электронную почту придёт письмо с учётными данными пользователя, а также ссылкой на кабинет пользователя и панель управления хостингом.

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

Как заказать SSL сертификата на хостинге?

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

Во-первых, сгенерировать SSL сертификат данного типа сможет даже ребёнок: не нужно скачивать и запускать какие-то утилиты, а также вникать в тонкости того, как установить SSL сертификат на сервер.

Всё, что от вас потребуется — просто ввести нужную информацию о сайте и свои персональные данные. Создание и установка SSL сертификата на сайт произойдёт автоматически.

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

Официальные регистраторы, насколько я знаю, таким покупателей не балуют.

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

И не дай Бог вам забыть это сделать — пользователи ваш сайт вообще не увидят, а только лишь сообщение об угрозе безопасности на весь экран браузера.

Чтобы сделать заказ, сперва нам нужно зайти в кабинет пользователя через сайт thehost.ua либо по ссылке, содержащейся в письме, сгенерированном при регистрации. После того, как войдёте в систему, выберите пункт бокового меню «SSL сертификаты» и нажмите кнопку «Заказать» вверху страницы.

После проделанных действий на экране появится диалоговое окно, которое выглядит так:

generaciya-ssl-sertifikata-na-hostinge

Здесь нам нужно выбрать тип SSL сертификата, который вы хотите купить и срок его действия. Цена услуги, естественно, будет зависеть от этих двух параметров.

Более подробно о доступных SSL сертификатах, которые можно заказать через TheHost, можете прочитать здесь — https://thehost.ua/services/ssl

Сразу скажу, что у данного провайдера цены на сертификат безопасности SSL начинаются от 7$ за год использования, чего я не встречал больше ни у кого на данный момент.

В зависимости от того, какой тариф вы выберете, у вас могут присутствовать или отсутствовать некоторые из приведённых далее шагов. Имейте ввиду!

После выбора необходимого тарифа нажимаем Далее и переходим к следующему шагу создания SSL сертификата:

kak-sdelat-ssl-sertifikat-dlya-sajta

Он представляет из себя формирование запроса в сертификационный центр, необходимого для того, чтобы получить SSL сертификат.

Запрос должен быть в виде файла с вашими зашифрованными персональными данными с расширением csr.

Если вы его уже сгенерировали (а о том, как это сделать прямо в ISPManager админки TheHost, я расскажу вам дальше), то на данном шаге просто введите его содержимое.

Для этого нужно выбрать для пункта «Способ ввода CSR» значение «Ввод имеющегося CSR», которое выбрано по умолчанию.

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

Для этого выберите в качестве способа ввода CSR в выпадающем списке значение «Генерация CSR и Private key».

При этом данное диалоговое окно примет следующий вид:

kak-sozdat-ssl-sertifikat

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

О  том, какие данные следует вводить и откуда их брать, вы можете прочитать в статье о том, что такое HTTPS.

Нажимаем «Далее», и на следующем экране, если вы генерировали запрос, вы увидите следующую информацию:

sozdanie-sertifikata-ssl

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

Рекомендуется его сохранить в файлике на компьютере для большей безопасности, чтобы никто не мог получить к нему доступ при взломе TheHost, например :-)

Либо же можно сохранить его в системе, чтобы не вводить на дальнейших шагах, чем я и воспользовался.

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

На следующем шаге от нас снова требуется ввод контактной информации администратора и технической поддержки, с которыми могут связаться представители CA для подтверждения информации, введённой в заявке на выпуск SSL сертификата:

kak-ustanovit-ssl-sertifikat-na-sajt

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

sgenerirovat-ssl-sertifikat

Следующим этапом является ввод email, на который будет высылаться ссылка для подтверждения генерации SSL сертификата:

ustanovka-ssl-sertifikata-na-hosting

Если у вас нет готового email, присутствующего среди вариантов выпадающего списка, то заведите его.

В случае же, если вы не подтвердите запрос, сертификат вы не получите, равно как можно будет не рассчитывать на компенсацию потраченных на его выпуск денег.

Что вполне справедливо, т.к. TheHost сам сертификат не выпускает, а заказывает его у официальных сертификационных центров.

Ну, и на финальном этапе от вас потребуется выбрать способ оплаты и срок продления SSL сертификата, на который он будет автоматически выпускаться при истечении своей действительности:

kak-podklyuchit-ssl-sertifikat-k-sajtu

Нажимаем на Готово и всё, что теперь остаётся — это дождаться запроса подтверждения выпуска SSL сертификата из центра сертификации и самого сертификата.

После того, как он будет у вас на руках, останется только подключить его к сайту. Но об этом мы поговорим немного позже, когда я рассмотрю все способы создания SSL сертификатов у TheHost, которые, как я уже говорил ранее, могут быть разных видов.

Создание самоподписанного SSL сертификата

Итак, как сделать заказ генерации SSL сертификата у официальных центров сертификации, я вам показал.

Однако, бывают ситуации, когда нужны и другие виды сертификатов. Например, для тестирования настроек движка сайта для HTTPS передачи данных на локальном сервере и тестовом домене.

В таком случае вполне подойдёт бесплатный самоподписанный SSL сертификат, который создать у TheHost можно за считанные секунды.

Для этого заходим в ISPManager по ссылке из письма, пришедшего при регистрации на thehost.ua, либо в панель управления сервером можно попасть прямо из кабинета пользователя следующим способом:

kak-poluchit-besplatnyj-ssl-sertifikat-letsencrypt

Если вам плохо видно изображённое на картинке, то для перевода в ISPManager из кабинета пользователя нужно выбрать пункт меню «Хостинг», выбрать необходимый сервер (может быть несколько в одной учётке юзера) и нажать на кнопку «На сервер», которая становится доступной после выбора сервера.

Находясь в ISPManager, выбираем пункт меню SSL сертификаты и нажимаем на кнопку «Создать в самом» верху страницы.

В появившемся диалоговом окне выбираем для поля Тип сертификата значение «самоподписанный», после чего окно примет следующий вид:

sozdat-ssl-sertifikat-samomu-besplatno

Вводим необходимую информацию, аналогичную той, которую мы указывали при оформлении SSL сертификата в CA, после чего нажимаем «ОК».

Сертификат появится в списке существующих SSL сертификатов.

Обратите внимание, что преимуществом самоподписанного SSL сертификата является его бесплатность и практически неограниченный срок действия.

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

Поэтому я настоятельно рекомендую использовать коммерческие, выпускаемые официальными сертифицирующими центрами.

Подключение SSL сертификата, оформленного в другом месте

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

Сделать это можно в том же диалоговом окне, которое использовалось для создания самоподписанного SSL сертификата.

Только для добавления на сервер TheHost существующего документа нужно будет в поле «Тип сертификата» выбрать значение «существующий», после чего всё диалоговое окно примет следующий вид:

kak-ustanovit-ssl-sertifikat-na-server

Вводим информацию, содержащуюся в вашем готовом SSL сертификате для домена, в соответствующие поля и нажимаем «ОК».

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

Создание запроса SSL сертификата у CA

Ну, и ещё одной возможностью, доступной в данном диалоговом окне создания SSL сертификата, является генерация запроса на выпуск данного документа в центре сертификации.

Данная возможность вам может пригодиться, как уже говорилось ранее, при заказе SSL сертификата не через своего хостинг провайдера, а через других, в том числе и при обращении в CA
напрямую.

Сгенерировать запрос на выпуск SSL сертификата для домена можно прямо у себя на рабочем компьютере с помощью специальных утилит.

Наиболее распространённой является OpenSSL, которая доступна как под Linux, так и под Windows благодаря CygWin или использованию других эмуляторов консоли Linux (та же самая командная строка Git поддерживает Linux команды или утилита PuTTY).

Также есть масса онлайн генераторов запросов на выпуск SSL сертификата. Вот наиболее популярные из них:

  • https://www.rapidsslonline.com/ssl-tools/csr-generator.php
  • https://csrgenerator.com/
  • https://www.ssl.com/online-csr-and-key-generator/

Также, данные генераторы предоставляют все официальные сертифицирующие центры и многие хостинг провайдеры.

Есть такой и у TheHost, который доступен в данном окне.

Чтобы его запустить, выбираем в поле «Тип ключа» значение «Запрос», после чего диалоговое окно примет следующий вид:

kak-sozdat-zapros-ssl-sertifikata

Вводим необходимую информацию и нажимаем ОК. После этого на сервере TheHost сгенерируются файлы csr и key, которые вы сможете в дальнейшем использовать для выпуска сертификата.

Чтобы можно было использовать их содержимое, вам нужно будет выбрать запись с типом «Запрос» в списке всех SSL сертификатов в панели управления хостингом TheHost и нажать кнопку «Скачать» в самом верху экрана, после чего вам на компьютер будет загружен архив с указанными файлами.

Открывайте их обычным текстовым редактором и копируйте код запросов при оформлении SSL сертификатов как через TheHost, так и у других регистраторов.

Как получить бесплатный SSL сертификат Lets Encrypt?

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

Речь идёт о генерации бесплатного SSL сертификата LetsEncrypt, создать который можно за считанные секунды.

Среди его преимуществ можно выделить не только то, что за его оформление вам не придётся платить, но и то, что процедура его выпуска самая быстрая из всех указанных (по крайней мере, у TheHost), т.к. при генерации не придётся указывать абсолютно никакой дополнительной информации, кроме доменного имени сайта, для которого документ будет выпускаться.

Из минусов можно отметить только то, что он выпускается лишь на 3 месяца, после чего его нужно будет продлевать.

Итак, чтобы создать SSL сертификат от Lets Encrypt, заходим на страницу «SSL сертификаты» в ISPManager и нажимаем на кнопку «Lets Encrypt», после чего откроется следующее диалоговое окно:

sozdanie-besplatnogo-ssl-sertifikata-letsencrypt

Выбираем из списка домен, для которого сертификат будет выпускаться, и нажимаем «ОК».

После этого, без всяких лишних вопросов, сертификат добавится в список. Если просмотреть информацию, содержащуюся в нём (нужно выбрать сертификат и нажать на кнопку «Информация»), то можно увидеть следующее:

nastrojka-ssl-sertifikata

Как видите, для всех LetsEncrypt SSL сертификатов TheHost указывает абсолютно идентичную информацию, упрощая и ускоряя процедуру их выпуска.

При желании вы можете произвести настройку SSL сертификата и изменить содержащуюся в нём информацию на данном этапе. Кстати, настоятельно рекомендую это сделать, т.к. этот шаг повысит ваше доверие у ваших пользователей, которые решат просмотреть данные сертификата.

Отсутствие персональных данных владельца в нём может серьёзно насторожить их, а для некоторых может даже послужить сигналом отказа от использования данного сайта.

Установка SSL сертификата на хостинг

Итак, создание SSL сертификата, я надеюсь, прошло у вас успешно. Теперь всё, что осталось сделать для успешной передачи данных по HTTPS, — это подключить SSL сертификат к сайту, для которого он оформлялся.

В качестве наглядного примера я решил продемонстрировать подключение SSL сертификата к своему тестовому сайту, для которого с этой целью был специально зарегистрирован поддомен — ssl.cccp-blog.com. О том, как создать поддомен сайта в ISPManager на примере TheHost вы можете прочитать в статье по указанной ссылке.

Итак, для подключения SSL сертификата к сайту в панели управления хостингом ISPManager открываем пункт меню «WWW домены», выбираем необходимый и нажимаем на кнопку «Изменить», которая становится доступной в самом верху страницы.

После этого на экране появляется следующее диалоговое окно:

dobavit-ssl-sertifikat-na-sajt

Чтобы установить SSL сертификат на выбранный домен, нам нужно поставить галочку в поле «SSL» и выбрать из выпадающего списка имя нужного документа.

Вот и всё. SSL сертификат на сайт установлен. Сами могли убедиться, насколько это просто и быстро благодаря TheHost и ISPManager, в частности.

Да, пусть он выглядит неказисто, но со своими задачами справляется на отлично :-)

Теперь нам останется только произвести настройки движка сайта, чтобы он корректно работал по новому HTTPS протоколу. Среди них будут редиректы с HTTP на HTTPS, настройка зеркал, правки карты сайта и robots.txt, а также много другое.

Но мы поговорим об этом в следующих статьях, т.к. каждая платформа требует индивидуального подхода.

В завершение обзора настроек сайта в ISPManager, связанных с SSL, хочу обратить ваше внимание на поле «Только SSL» в диалоговом окне, изображённом на скриншоте выше. С помощью него возможно сделать редиректы с HTTP на HTTPS для URL сайта на уровне веб сервера Nginx.

Установив галочку в данном поле, в файл конфигурации веб сервера Nginx на хостинге добавится следующий код:

if ($ssl_protocol = "") {
    rewrite ^ https://$server_name$request_uri? permanent;
}

Можете взять данный способ организации редиректов с HTTP на HTTPS себе на заметку, особенно, если вы не пользуетесь услугами shared хостингов и панелями управления хостингом, в частности, а редирект настроить нужно.

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

Проверка правильности установки SSL сертификата

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

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

Чтобы получить полный список проблем перехода на HTTPS и просканировать свой сайт на их наличие, я рекомендую воспользоваться следующими сервисами:

  1. https://www.ssllabs.com/ssltest
  2. https://www.digicert.com/help

В качестве вывода хотелось бы сказать, что в ходе чтения статьи вы сами заметили, насколько хостинг провайдер и панель управления хостингом упрощает жизнь при заказе, установке и настройке SSL сертификатов. Особенно вы могли это ощутить, если когда-либо устанавливали HTTPS соединение для сайта на сервере вручную, не располагающего панелью управления.

А это, надо сказать, неплохая мотивация пользоваться первым типом хостеров, где от пользователя не требуется много времени и знаний.

Особенно ценен данный аргумент для людей, которые никогда не были связаны с веб-программированием и созданием сайтов, но установка SSL сертификата на их сайты необходима.

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

Ну, а если вы ещё только выбираете такового, то хочу порекомендовать TheHost, инструкция по созданию и установке SSL сертификата в панели управления которого и была представлена в данной статье.

На этом всё. До новых встреч! :-)

Как сделать поддомен сайта: пошаговая инструкция

kak-sozdat-poddomen-sajtaДоброго времени суток! :-)

Сегодняшняя статья будет посвящена тому, как создать поддомен сайта на хостинге.

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

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

Так что представленный далее алгоритм будет полезен вам не только потому, что позволяет понять общие принципы создания субдоменов, а также ознакомиться с их возможными настройками, но и будет полезен, если ваш хостинг также использует ISPManager для администрирования сервера.

А данная ситуация, стоит сказать, — не редкость, т.к. данное ПО весьма распространено благодаря своей низкой цене и широким возможностям.

Кстати, если вы до сих пор выбираете хостинг провайдера, то рекомендую обратить внимание на TheHost — пользуюсь его услугами уже в течении 2 лет и за всё это время проблем не возникало: сайт стабильно доступен, техподдержка работает оперативно, а цены, пожалуй, самые низкие на рынке.

Поехали!

Как сделать поддомен на сайте — инструкция

Сразу скажу, что процесс регистрации поддомена сайта недолгий и, благодаря наличию панели администрирования, займёт максимум минут 10.

Суть добавления поддомена в ISPManager ничем не отличается от создания обычных доменов. Единственный нюанс заключается в том, что доменное имя поддомена должно содержать имя основного домена, что логично.

Распишу все действия пошагово.

Шаг 1

Заходим в панель управления сервером, в нашем случае, ISPManager, адрес которой будет содержаться в письме, пришедшее вам после регистрации на thehost.ua и заказа услуги (хотя бы бесплатного хостинга с целью ознакомления с кабинетом пользователя).

Выглядит она внешне, конечно, неказисто, но в использовании удобна и понятна.

Шаг 2

Выбираем пункт меню WWW домены и вверху открывшейся страницы нажимаем на кнопку «Создать»:
sozdanie-poddomena-ispmanager

После этого у нас откроется окно, содержащее настройки домена.

Шаг 3

Выглядит оно следующим образом:

kak-sdelat-poddomen-sajta-nastrojki-v-ispmanager

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

Также можно вручную указывать каталог, в котором сайт будет размещаться на сервере.

По умолчанию же он создаётся в корневой папке www, где размещаются все сайты после создания. Т.е. поддомены будут располагаться на одном уровне с основными доменами.

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

После ввода необходимых настроек нажимаем ОК.

Шаг 4

В итоге, на сервере создался каталог с дефолтным набором файлов, состоящим из заглушки и заготовки файлов robots.txt и .htaccess, а также доменное имя поддомена добавилось в список всех WWW доменов.

Через некоторое время после создания сайт будет доступен в браузере. Данная пауза вызвана временем обновления глобальной базы DNS, в которой содержатся все сайты, доступные через Интернет. Может пройти до 24 часов.

Ну, и после, всё, что останется для запуска сайта на поддомене — это подключиться к серверу по FTP или SSH (доступен на определённых тарифных планах) и залить файлы сайта в созданный каталог, удалив заглушку и прочие ненужные стандартные файлы.

Как создать поддомен в ISPManager — нюансы

Описанный выше способ позволяет сделать поддомены на домене, который полностью готов к использованию. Однако, у нас нет никакой возможности управлять его DNS записями (назначать почтовые, NS сервера и многие другие).

Если у вас возникнет такая необходимость в дальнейшем, то создать DNS запись для существующего WWW домена в ISPManager можно следующим образом:

kak-sozdat-poddomen-sajta-na-hostinge

Как видите на скриншоте, для этого необходимо зайти в ISPManager и выбрать пункт меню Доменные имена (DNS). После этого нажимаем на кнопку «Создать» вверху страницы и вводим необходимую информацию в появившемся окне.

На скриншоте представлен пример моей конфигурации для поддомена ssl.cccp-blog.com, который создавал в ходе написания данной статьи.

Как видите, здесь же можно автоматически создавать и WWW домен, который мы делали ранее. Для того, чтобы зарегистрировать поддомен, достаточно лишь поставить галочку в поле Создать WWW домен.

Поскольку в нашем случае WWW домен уже добавлен, я оставил данное поле пустым.

Нажимаем «ОК» — и доменная DNS запись создана.

После того, как она будет доступна в списке, доступ к DNS данным можно получить следующим образом:

kak-sdelat-poddomen-sajta-upravlenie-dns-zapisyami

После того, как вы нажмёте на кнопку Записи, перед вами откроется страница со списком всех DNS записей, доступных для выбранного домена, которая выглядит так:

kak-sozdat-poddomen-sajta-dns-zapisi

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

Также через интерфейс ISPManager возможно настроить создание поддоменов сайта автоматически. Данную опцию можно выбрать при настройке WWW домена, скрин с которыми был представлен в статье ранее.

Благодаря этой опции у нас появится возможность делать динамические поддомены без манипуляций в ISPManager.

Там присутствовал пункт Авто поддомены, у которого значения были оформлены в виде выпадающего списка. По умолчанию выбрано значение «Отключены», но также доступны «В отдельной директории» и «В поддиректории WWW домена».

При выборе необходимого значения создать поддомен сайта можно будет путём добавления соответствующего каталога прямо на сервере. Сделали папку — и динамический поддомен готов. Круто, правда?

Однако, в данной ситуации, у нас не будет доступа к настройкам DNS записей поддомена и прочих, которые позволяет производить ISPManager в своём интерфейсе.

Собственно говоря, поэтому я и отключил создание автоматических поддоменов в ISPManager для своего сайта ssl.cccp-blog.com.

Кстати, заливать файлы на сервер можно не только через привычные FTP клиенты, входящие в джентельменский набор программ для создания сайтов, но и через интерфейс самого ISPManager:

sozdanie-poddomena-fajlovyj-manager

На скриншоте выше представлено содержимое моего тестового поддомена сайта ssl.cccp-blog.com, в который я решил установить чистую версию WordPress для дальнейших экспериментов.

А они продолжатся уже в следующей статье, в которой я буду устанавливать SSL сертификат на WordPress сайт.

Касательно функционала файлового менеджера ISPManager, то он позволяет добавлять, править и удалять файлы на сервере, а также заливать новые файлы и скачивать существующие в формате архива.

Удобная штука, чтобы быстро и просто сделать бэкап файлов сайта.

Индексация поддоменов

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

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

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

Настройки индексирования поддоменов проще всего производить с помощью robots.txt.

На многих хостингах, при создании нового сайта через панель администрирования (ISPManager, VestaCP), помимо HTML заглушки, зачастую добавляется ещё и robots.txt со следующим содержимым:

User-agent: *
Allow: /

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

User-agent: *
Disallow: /

Также не лишним будет добавить следующую конструкцию в head секцию HTML кода страниц, которые вы хотите запретить индексировать:

<meta name="robots" content="noindex, nofollow">

Данный тэг позволяет дополнительно сообщить роботам поисковых систем о том, что содержимое данной страницы не стоит индексировать.

Даже если вы преследуете противоположную цель: открыть все страницы для индексации сайта, расположенного на поддомене, вам также придётся залезть в HTML код для лучшей индексации и выдачи правильных версий сайта при поисковых запросах.

При добавлении поддомена сайта с мобильной версией нужно будет в HTML коде страниц мобильной версии добавить каноническую ссылку на соответствующую страницу основной версии:

<link rel="canonical" href="//www.site-main.com/page.html">

А на странице основного сайта нужно будет добавить следующий код для указания мобильной версии контента:

<link rel="alternate" href="//m.site-main.com/page.html">

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

На страницу с локализованным контентом добавляем каноническую ссылку на страницу основного сайта:

<link rel="canonical" href="//www.site-main.com/page.html">

А на основном добавляем следующий код для указания версии данной страницы на определённо языке.

Например, для указания английской версии страницы на основном сайте нужно будет добавить следующую конструкцию в head секцию HTML кода страницы:

<link rel="alternate" hreflang="en-US" href="//en.site-main.com/page.html">

Следовательно, при наличии нескольких региональных версий сайта нужно будет добавлять ссылки на каждую из них в коде основного.

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

Вот, что говорит сам Google по данному поводу:

Эти атрибуты помогают роботу Googlebot найти ваш контент, а нашим алгоритмам – определить взаимосвязь между обычными и мобильными страницами вашего сайта. Когда вы используете разные URL для одного и того же контента в различных форматах, атрибуты сообщают системе, что эти два URL содержат одинаковый контент и их следует считать одним объектом, а не двумя. Если обычная и мобильная версии страницы интерпретируются как независимые объекты, то в результатах Поиска на ПК могут присутствовать оба URL. В таком случае их рейтинг будет ниже, чем если бы роботу Google было известно об их взаимосвязи.

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

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

Пишите ваши вопросы, а также отзывы в комментариях ниже. Также, если статья вам понравилась, вы всегда можете сказать «Спасибо» с помощью формы под статьёй и поделиться ей со своими друзьями в социальных сетях.

На этом у меня всё.

До новых встреч! :-)

Что такое поддомен сайта: 5 примеров

chto-takoe-poddomenДоброго времени суток! :-)

Сегодняшняя статья будет посвящена поддоменам. Мы поговорим о том, что такое поддомен сайта и в каких ситуациях он может применяться.

Сразу скажу, что создание поддоменов — процесс очень простой и абсолютно бесплатный. А на большинстве хостингов регистрировать их можно неограниченное количество (на VPS так уж точно).

Поэтому иногда использование поддоменов даже предпочтительнее регистрации новых доменных имён сайтов.

А вот насчёт минусов поддоменов… Об этом мы сегодня подробно и поговорим, рассмотрев попутно что такое поддомен сайта вообще, какие у него есть особенности и где его создание может быть полезным и вредным.

Поехали! :-)

Что такое поддомен сайта?

Думаю, что о том, что такое домен, вы в курсе? Нет, речь сейчас пойдёт не о владениях королей и феодалов в Средние века :-)

Речь пойдёт о доменных именах сайтов, которые служат для идентификации ресурсов в сети Интернет. Доменные имена всех существующих сайтов составляют общее пространство имён Интернета, которое работает благодаря DNS (система доменных имён).

DNS позволяет узнавать имя хоста (сайта) по его IP, информацию о маршрутизации почты и т.д.

Доменные имена сайтов состоят из нескольких доменов.

К примеру, доменное имя сайта example.com состоит из доменов com и example, разделённые точкой. В этой ситуации com будет доменом первого уровня, а example — второго уровня.

Т.е. example будет поддоменом домена com.

Таким образом, поддомен (субдомен, дочерний домен) — это домен, который является частью домена более высокого уровня.

Согласно Wikipedia, максимальное количество уровней поддоменов — 127, и каждый из них может содержать 63 символа, пока общая длина доменного имени не достигнет длины в 255 символов.

Маленькая ремарка. Первый слева домен доменного имени сайта называют именем сайта, а всё, что справа — доменной зоной. Возвращаясь к нашему примеру, example — это имя сайта, а com — доменная зона

Что такое субдомен в общем, думаю, понятно. Что же будет являться поддоменом сайта?

Поддомен сайта — это отдельный сайт, доменное имя которого содержит доменное имя основного сайта. Т.е. доменное имя основного сайта будет являться доменной зоной его поддомена.

Возвращаясь к нашему примеру, сайт с доменным именем new.example.com будет поддоменом сайта example.com. Разбирая его, как мы делали это раньше, new будет именем сайта и доменом третьего уровня, а example.com — доменной зоной.

Доменное имя основного сайта будет являться доменной зоной его поддомена… Что-то слишком часто встречается слово «домен» в этой фразе.

Это раздражает не только людей при чтении, но и поисковые системы при ранжировании страниц таких сайтов в результатах поиска.

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

Нужны ли поддомены тогда вообще и где они могу пригодиться? Давайте порассуждаем… :-)

Для чего нужны поддомены?

Итак, зачем нужны поддомены и в каких ситуациях их лучше использовать, если поисковики такие ресурсы не жалуют?

1. Тестовый сайт

Создание субдоменов может быть вам полезно в ситуациях, когда необходимо протестировать какой-либо функционал в «полубоевых» условиях, т.е. на реальном проекте (production, продакшене, проде), но без нанесения ему вреда.

В таких ситуациях создают препрод окружение, представляющее собой копию основного сайта, и размещают его на поддомене. Чаще всего, это test.site.com или dev.site.comstg.site.com, когда тестовых окружений несколько (DEV и STAGE).

2. Тренировочный сайт

Иногда сделать поддомен на сайте может быть отличной идеей, когда вам нужно просто с чем-то потренироваться.

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

Согласитесь, что специально регистрировать новое доменное имя за деньги ради таких целей было бы глупо.

3. Внутренний ресурс

Создание поддомена может стать хорошим выходом при проектировании сайта, который вы будете использовать для каких-то внутренних нужд, не создавая отдельные доменные имена.

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

Делать отдельный сайт на отдельном доменном имени в данном случае не рекомендуется, т.к. придётся долго объяснять пользователям, какое отношение новый ресурс имеет к основному (если вы, конечно, не хотите скрыть эту связь намеренно).

Если же в его URL будет присутствовать указание основного сайта, то вопросы о связи отпадут.

4. Мобильная версия сайта

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

Все вы, наверное, обращали внимание на то, что при входе на различные крупные ресурсы с мобильного телефона у вас в браузере отображается не его URL, а нечто подобное: m.site.commobi.site.commobile.site.com.

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

Но при SEO продвижении сайта нужно будет учитывать некоторые нюансы, т.к. продвигаться будут, по сути, два разных сайта.

5. Региональная версия сайта

Наряду с мобильными версиями сайтов поддомены активно используются при создании различных региональных версий сайта.

Например, ru.site.comua.site.comkz.site.com и т.д. Наличие таких поддоменов может привлечь больше трафика на сайт благодаря большему числу страниц в поисковом индексе.

Может сложиться такая ситуация, что весь ТОП-10 поисковой выдачи будет состоять из страниц основного сайта и его поддоменов. Тогда пользователь гарантированно попадёт к вам :-)

Нужен ли поддомен при SEO продвижении?

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

Да даже те профессиональные SEO оптимизаторы, статьи которых я изучал, не могут дать однозначный ответ.

Одни говорят, что, благодаря созданию поддоменов можно иметь больше страниц в поисковом индексе и в перспективе занять весь ТОП-10.

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

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

Особенно, учитывая нелюбовь поисковикам к поддоменам в общем.

Но все SEO-шники в своих советах сходятся в одном — экспериментировать :-)

Собственно говоря, на этом принципе и построено SEO в общем, т.к. поисковики секретов своего ранжирования не выдают.

Иначе ими легко можно было бы пользоваться в конкурентной борьбе, пренебрегая качеством контента, а разработчикам ПС придумывать новые и новые факторы, что весьма трудоёмко.

Так что, если у вас опыт экспериментов с поддоменами для SEO продвижения сайтов — не ленитесь делиться им в комментариях со всеми для улучшения кармы :-)

Надеюсь, в данной статье мне удалось ответить на вопрос о том, что такое поддомен сайта и где он может пригодится, а также какое влияние он может оказать на позиции основного сайта в поисковой выдаче.

Пишите ваши отзывы, предлагайте новые темы для статей и делитесь информацией со своими друзьями в социальных сетях.

На этом всё.

Удачи и до новых встреч! :-)

Переезд на HTTPS: инструкция, проблемы и рекомендации

perekhod-na-httpsПриветствую вас, друзья!

Сегодня я продолжу тему, начатую мною в предыдущих статьях и посвящённую теме HTTPS и SSL сертификатов, которая активно обсуждается в сети последние года три.

Ровно с тех пор, когда Google заявил о новых критериях ранжирования сайтов в зависимости от протокола связи, по которому осуществляется обмен информацией с пользователями.

В частности, сайтам с HTTPS обещались более высокие позиции в данной поисковой системе.

Тогда же начался массовый переход на HTTPS существующих сайтов, который и продолжается по сей день.

Однако, данный процесс несёт не только пользу, как может показаться, но и массу проблем, особенно неподготовленным пользователям. Об этом свидетельствует неспешные темпы перевода сайтов на HTTPS, подкреплённые статистикой: всего около 30% современных сайтов работают по протоколу HTTPS.

Если преимуществам данного протокола была посвящена моя статья о том, что такое HTTPS, то в данной я решил рассмотреть, какими проблемами чреват переезд на HTTPS существующих сайтов.

Также я уделю внимание их причинам и способам нейтрализации. А в конце вас ждёт инструкция по переезду с HTTP на HTTPS и рекомендации по поводу того, как и когда делать это с минимальным риском.

Поехали :-)

Переход на HTTPS — проблемы

Прошу прощения, что начинаю с неприятного. Но надо же вас как-то замотивировать читать инструкцию по переезду на HTTPS :-)

А возможные проблемы — самый лучший мотиватор делать всё аккуратно и внимательно, как показывает практика. Поэтому обязательно ознакомьтесь с данным блоком информации.

А именно с того, к чему может привести неграмотный переезд сайта на HTTPS.

1. Недоступность сайта

Бывают такие случаи, когда после перехода на HTTPS сайт просто перестал открываться. Такое явление может возникнуть из-за большого количества редиректов с HTTP на HTTPS и их зацикленности.

При возникновении любый проблем с доступностью после перевода сайта на HTTPS изучайте сообщения в браузере и немедленно сообщайте о них технической поддержке своего хостинг-провайдера. Если там находятся квалифицированные специалисты, то в 80% случаев они вам помогут.

2. Снижение трафика

В сети полно грустных историй вебмастеров, у которых на сайтах после перехода на HTTPS упали позиции или даже некоторые страницы выпали из поискового индекса.

Причин может быть много:

  • Отсутствие 301 редиректов с HTTP адресов на HTTPS.
  • Часть страниц может быть на HTTP, а часть на HTTPS (смешанное содержимое от англ. mixed content). Ещё одной причиной считать содержимое сайта смешанным является наличие HTTP ссылок на страницах, работающих по HTTPS протоколу.
  • Ссылки в sitemap могут быть с учётом HTTP.
  • После перехода на HTTPS новый адрес сайта не был добавлен в кабинетах вебмастера Google и Яндекс.
  • Версия сайта на HTTPS не была отмечена как основная, а старый сайт не был помечен как зеркало. Из-за этого позиции могут понижаться вследствие дублирования контента и разбавления ссылочной массы между двумя доменами.

3. Неправильная работа сайта

Может проявиться в том, что скрипты будут не грузиться вообще или некоторые картинки будут отсутствовать. Причина заключается в HTTP ссылках на статические ресурсы после полного переезда сайта на HTTPS.

4. Потеря статистики посещаемости

После перехода на HTTPS может возникнуть ситуация, что ваши партнёры, рефералами (referrals, affiliates) которых вы являетесь, перестанут видеть трафик с вашего сайта через популярные сервисы аналитики: Google Analytics, Яндекс. Метрика и другие.

Особенно эта проблема может стать актуальной для людей, зарабатывающих на своих сайтах путём размещения баннеров и ссылок, получая доход за переходы и действия, произведённые пользователями при переходе по ним.

Таким образом, после переезда сайта на HTTPS из-за данной проблемы вы просто можете потерять свои деньги, а ваш рекламодатель увидит следующую картину переходов с вашего сайта:

kak-perevesti-sajt-na-https-i-ne-poteryat-trafik

Причиной данной проблемы является то, что переход с вашего защищённого HTTPS сайта на обычную HTTP страницу, которая может быть у вашего партнёра, воспринимается сервисами аналитики как прямой переход на сайт партнёра.

Поэтому ваш сайт может просто выпасть из данной цепочки.

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

А решения?… Что делать, шеф? :-)

Именно с этой целью я и составил следующую пошаговую инструкцию как перенести сайт на HTTPS, при выполнении которой вы убережёте себя и свой ресурс от описанных траблов, а также от негативной реакции на них ваших пользователей и поисковиков.

Как перевести сайт на HTTPS — инструкция

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

1. Установка SSL сертификата на сервер

Переезд сайта на HTTPS начинается с покупки и установки SSL сертификата.

Тут всё просто: выбираем подходящий сертификат, покупаем его, устанавливаем на сервер и подключаем к своему сайту.

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

2. Настройка движка сайта

После установки SSL сертификата, для корректной работы по новому протоколу в коде самого сайта и его настройках нужно будет произвести ещё кое-какие изменения.

Первым делом, нужно будет указать, что URL сайта отныне содержит не HTTP, а HTTPS протокол. Такие настройки требуются в большинстве CMS для создания правильных внутренних ссылок, которые являются относительными.

Также важно будет проверить, чтобы существующие страницы сайта корректно открывались по URL с учётом HTTPS протокола.

3. Сообщить поисковикам об изменениях

После этого нужно сообщить поисковикам о том, что сайт перешёл на HTTPS протокол. Для индексации новых URL страниц c учётом HTTPS протокола, необходимо сообщить об их наличии поисковым роботам с помощью так называемых «аддурилок»:

  • Яндекс: https://webmaster.yandex.ru/addurl.xml
  • Google: https://www.google.com/webmasters/tools/submit-url
  • Bing: https://www.bing.com/toolbox/submit-site-url

4. Изменение главного зеркала

У Яндекса и других поисковых систем есть такое понятие, как «зеркало». Зеркалами считаются копии сайтов, среди которых есть главное зеркало – сайт, страницы которого как раз присутствуют в поисковой выдаче.

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

Главное зеркало сайта устанавливается вручную в кабинетах вебмастеров Google, Яндекс и Bing. При переносе сайта на HTTPS главным зеркалом сайта должна быть именно HTTPS версия. Также указать главное зеркало можно с помощью robots.txt, прописав в нём (или изменил) директиву Host, которая должна выглядеть так:

Host: https://site.com

А также главное зеркало сайта можно указать с помощью 301 редиректа, которые всё равно будут необходимы для переноса веса с HTTP URL страниц на HTTPS.

5. Изменение внутренних ссылок

Параллельно с добавлением HTTPS адресов страниц в аддурилки и настройкой главного зеркала необходимо проверить внутренние ссылки на сайте. Причём, это должны быть не только перекрёстные ссылки внутри статей, но и URL статических файлов (картинок, JS и CSS файлов).

Если ссылки прописаны в абсолютном виде, то нужно будет заменить в них протокол HTTP на HTTPS.

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

Могут быть как относительно протокола в следующем виде:

//site.ru/page.html

Так и относительно корня сайта:

/page.html

Лучше делать изменение внутренних ссылок при помощи специальных скриптов, которые помогут найти и заменить ссылки как в коде сайта, так и в БД, автоматически.

Если же их использование покажется вам слишком сложным, то можете изменить все ссылки вручную. Главное, при этом не забыть про контент, который может находиться в базах данных, внутри JavaScript скриптов, файлах CSS стилей и правилах редиректа.

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

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

Стоит также учесть, что при использовании сторонних библиотек по CDN или иным другим способом, когда в коде сайта располагается ссылка на них, нужно также заменить их с учётом HTTPS протокола. Либо заменить абсолютные HTTP адреса относительными.

Если сделать это будет невозможно, то от таких ресурсов лучше отказаться совсем или скачать их и вызывать с собственного сервера уже по HTTPS протоколу, естественно, что будет предпочтительно даже с технической точки зрения, т.к. скорость их подключения будет выше, и вы не будете зависеть от наличия Интернет соединения.

6. Установка 301 редиректов с HTTP на HTTPS адреса страниц

Сразу скажу, что редирект потребуется для всех существующих страниц сайта и запросов без исключения, чтобы у поисковых систем не было даже повода придраться.

Сделать это можно при помощи специальных плагинов и пакетов (для того же WordPress HTTPS плагинов существует уйма). Либо даже с помощью средств языков программирования.

Но самым быстрым и простым вариантом является организация 301 редиректа на уровне веб сервера с помощью специальных директив в их конфигурационных файлах.

Если ваш сайт работает на Apache сервере, то добавьте в файл .htaccess, который должен располагаться в корне сайта (или создайте его) следующий код:

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
    RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
    RewriteRule ^ https://%1%{REQUEST_URI} [R=301,L]
</IfModule>

Если же вы используете Nginx, то вам потребуется следующая конструкция:

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name example.com www.example.com;
    return 301 https://$server_name$request_uri;
}

Яндекс рекомендует устанавливать 301 редиректы после полной склейки зеркал, т.к. при установке редиректов страницы могут исключаться из поисковой выдачи.

7. Изменение внешних ссылок

Если вас ресурс существует достаточно долго, то, скорее всего, в Интернете можно отыскать ссылки на него с других ресурсов. Будь то обычные посты в социальных сетях или покупные ссылки, которыми вы увеличивали свой ТИЦ за деньги.

Естественно, что все они прописаны с учётом HTTP протокола, который было бы хорошо изменить на HTTPS. Но если у вас нет возможности это сделать, то сильно не огорчайтесь, т.к. при склейке доменов ссылки на любое зеркало сайта учитываются поисковиками для главного зеркала.

Таким образом, старые ссылки будут продолжать работать, передавая веса и ТИЦ.

8. Проверка канонических ссылок

Если вы используете на своём сайте канонические ссылки для исключения дублирования контента (работают для поисковиков как и 301 редирект), то необходимо на них всех поменять url с HTTP на HTTPS:

<link rel="canonical" href="https://site.com/url">

Напомню, что чаще всего такие конструкции располагаются в секции head HTML кода страницы. Однако, могут присутствовать и в других местах, например, на элементах пагинации, которые сами, в свою очередь, могут быть оформлены следующим образом:

<link rel="prev" href="https://site.com?page=1">
<link rel="next" href="https://site.com?page=2">

Если ссылки у них будут указаны также с учётом HTTP протокола, то их также нужно будет перевести с HTTP на HTTPS.

9. Правки на мультиязычных сайтах и в пагинации

Если на вашем сайте имеется мультиязычность, т.е. у страниц есть варианты на нескольких языках с возможностью их переключения в интерфейсе, то, скорее всего, в HTML коде у вас будет присутствовать следующая конструкция:

<link rel="alternate" hreflang="ru" href="https://site.com/">

Если таковая присутствует, то необходимо будет перевести страницу на HTTPS, т.е. изменить её URL с учётом данного протокола.

Также на вашем сайте, даже без вашего ведома, могут использоваться и другие тэги link, на значение адресов ссылок в которых также нужно будет обратить пристальное внимание.

10. Коррективы sitemap.xml

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

В принципе, если в ней будут URL, указанные через HTTP, то благодаря правильно настроенным 301 редиректам роботы всё равно попадут на итоговую страницу, но это приведёт к наличию у вас на сайте большого числа редиректов, что не останется без внимания поисковиков и снизит скорость загрузки контента.

Также в robots.txt нужно поменять ссылку на саму sitemap.xml с учётом нового протокола HTTPS:

Sitemap: https://site.com/sitemap.xml

11. Сохраняем реферальный трафик

Чтобы не стать невидимкой для Google Analytics и прочих сервисов аналитики, используемых вашими партнёрами, о чём я говорил в начале статьи, понадобится ещё одно действие.

Оно заключается в добавлении мета тега referer, с помощью которого задаётся содержимое заголовка Referer HTTP запроса, отправляемого пользователем вашего сайта через браузер. В идеале там должен содержаться URL сайта, на котором находился юзер при отправке запроса.

По умолчанию, при передаче запросов браузеры руководствуются реферальной политикой No Referrer When Downgrade, которая подразумевает передачу реферальных данных (ссылки на ресурс, с которого запрос был инициирован) только с HTTPS на HTTPS ресурс.

При передаче с HTTPS на HTTP заголовок не будет содержать никаких данных и запрос будет считаться прямым, т.е. когда пользователь ввёл URL сайта вашего партнёра прямо в браузере.

Сразу хочу уточнить, что в значении Referer заголовка будет находиться URL без параметров.

Итак, чтобы изменить данное поведение, нужно в HTML коде необходимых страниц (лучше всего, конечно, сделать это для всего сайта) разместить следующую конструкцию в секции head:

<meta name="referrer" content="значение_параметра">,

Наиболее часто используемыми на практике являются следующие значения параметров:

  • no-referrer — реферальные данные не будут передаваться;
  • no-referrer-when-downgrade — значение по умолчанию: ссылка источника будет передаваться только сайтам, поддерживающим HTTPS протокол, как и на вашем; сайтам, работающим по HTTP, ничего не будет передаваться;
  • origin — реферальные данные будут передаваться не зависимо от протокола и при переходе как с вашего основного сайта, так и с его поддоменов;
  • origin-when-crossorigin — при внутренних запросах, т.е. когда переход на URL произошёл пользователем с этого же сайта, будет передаваться полный адрес страницы; в случае же запроса с другого сайта заголовок будет пуст;
  • unsafe-url — реферальные данные будут передаваться в любом случае: и при внутренних запросах, и при перекрёстных;

Со списком всех политик безопасности и их описанием (правда, на английском) вы можете познакомиться здесь — https://www.w3.org/TR/referrer-policy/#referrer-policies

В большинстве случаев, для корректной передачи реферальных данных без угроз безопасности ресурса вам пригодится следующий вариант:

<meta name="referrer" content="origin">

После произведения действий, описанных в данной инструкции по правильному переходу на HTTPS сайтов с HTTP, всё, что вам останется — ждать. Ждать полной переиндексации сайта и замещения страниц из поиска с HTTP урлами на HTTPS аналоги.

К сожалению, даже если вы всё сделаете верно, стоит готовиться к кратковременному снижению трафика, т.к. 301 редиректы передают от 85% до 99% ссылочного веса. Трафик может восстанавливаться несколько месяцев.

Также не удивляйтесь тому, что при переходе на HTTPS пропал ТИЦ или данный показатель значительно снизился.

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

Переезд на HTTPS — снова проблемы…

Аффтар жжот :-) Только привёл инструкцию, как избежать проседания трафика и прочих проблем переезда сайта на HTTPS — и снова здрасьте… Какие ещё проблемы?

К сожалению, список трудностей, которые могут возникнуть при переходе с HTTPS на HTTP, не ограничивается перечнем, приведённым в начале.

Я не описал их сразу не потому, что забыл о части и вспомнил только сейчас, а по той причине, что не все они зависят от правильности действий при переводе сайта.

Некоторые из них вызваны особенностями самого защищённого протокола HTTPS, о чём я и захотел поговорить с вами насполедок.

1. Частичная недоступность

Обычно проявляется следующим сообщением об ошибке HTTPS подключения к сайту в браузере:

oshibka-prosrochennogo-sertifikata-pri-perehode-na-https

Причина: В принципе, ничего страшного в данном явлении нет, т.к. сообщение появляется при использовании самоподписанного SSL сертификата или когда истёк срок действия сертификата.

Но пользователи, в большинстве своём, — люди простые :-) Просто берут и закрывают сайт в поисках «безопасной» альтернативы.

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

Решение: Своевременно оплачивайте сертификат или просто переоформляйте его при использовании бесплатного. Многие хостинги, кстати, предоставляют своим клиентам скрипты для автоматического переоформления бесплатных сертификатов от Let’s Encrypt.

Также, данное сообщение возможно в случае установки чужого сертификата, выданного на другой домен. Ну, тут уж, товарищи хакеры, ничего не останется, как отказаться от такого и купить себе персональный.

Кстати! Такая ситуация может возникнуть ещё и тогда, когда недобросовестный регистратор подсунул вам «левый» сертификат. Поэтому при возникновении данных проблем обязательно сообщитетем,  у кого вы купили ваш SSL сертификат.

2. Страницы сайта стали дольше загружаться

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

Причина: Заключается в наличии операций по шифрованию и дешифровке трафика при передаче по протоколу HTTPS.

Решение: К сожалению, бороться с этим не получится, да и бессмысленно, т.к. это нюансы технологии. Как вариант – заняться переоптимизацией сайта там, где это возможно (организовать серверное кэширование, минимизировать размер картинок и других статических файлов – html/css/js).

3. Потеря статистики социальных сигналов (репосты, лайки и т.д.)

Переезд на HTTPS сулит и ещё одну проблему, которая заключается в обнулении счётчиков лайкнувших и зарепостивших вас пользователей. Мелочь, вроде бы. Но, в некоторых случаях, данный нюанс может создать серьёзные проблемы для бизнеса.

Причина: Это происходит из-за того, что статистика считается для конкретного домена. Поскольку сайт при переходе с HTTP на HTTPS, фактически, изменил свой url, то вся статистика будет утрачена и начнёт считаться заново.

Решение: К сожалению, с этим ничего нельзя сделать, пока разработчики социальных сетей не внесут в свои продукты соответствующие изменения. А пока они этого не сделали, вы можете воспользоваться плагинами. Например, для WordPress существует замечательный плагин от WarfarePlugins, позволяющий сохранить статистику социальных сигналов при переходе сайта на HTTPS.

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

Минусов у него всего два: плагин на английском и он платный, но цена не заоблачна и составляет единоразовые 30$. В принципе, вы заплатите эти же деньги или даже больше, если будете обращаться к фрилансерам с подобной просьбой.

Как перейти на HTTPS — рекомендации

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

Однако, есть способы минимизировать этот эффект и сделать так, что ваш бизнес понесёт при этом незначительные потери.

Для этого есть несколько рекомендаций.

1. Переход в период снижения посещаемости

Правильным решением будет производить переход с HTTP на HTTPS в сезон затишья, когда трафик ресурса минимален. Таким образом, если падение позиций сайта в поисковой выдаче и произойдёт, то снижение трафика на фоне всеобщего спада будет практически незаметно.

А если вдруг ресурс будет некоторое время вообще недоступен, то вы потеряете меньше клиентов, чем в период продаж.

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

Однако, всё равно, для каждой тематики и ресурса он свой, поэтому анализируйте свой годовой трафик, чтобы вычислить подходящее время для перевода сайта на https.

2. Использование сервисов для мониторинга ошибок перехода на HTTPS

В самом начале статьи были рассмотрены проблемы, возникающие при переезде сайтов на HTTPS, а также некоторые их причины. Даже если проблему вы и сможете самостоятельно определить, то проработать абсолютно все причины её возникновения вручную будет весьма долго и затруднительно для неопытных пользователей.

Поэтому я советую анализировать сайт с использованием специальных сервисов незамедлительно после установки SSL сертификата на сервер, настройки движка сайта и 301 редиректов. Таким образом, вы сможете узнать о возникших проблемах при переходе с HTTP на HTTPS раньше Яндекса и Google, что позволит вам избежать проседания трафика.

Одним из таких сервисов является Serpstat, который предоставляет следующую аналитику ошибок SSL сертификата и HTTPS соединения в целом:

proverka-ustanovki-ssl-sertifikata-i-oshibok-perevoda-sajta-na-https

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

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

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

3. Настройка HTTPS соединения на копии сайта

Поскольку неправильный перенос сайта на HTTPS чреват многими проблемами, то я, как веб разработчик, хочу дать чисто профессиональный совет :-)

Он заключается в тестировании изменений, а в данной случае, настройке HTTPS соединения, на локальном веб-сервере или копии сайта на одном тестовом поддомене сайта, а не в «продакшене».

Это немного растянет процесс переезда на HTTPS по времени, но зато у вас будет 100% гарантия того, что после переноса сайта на основной домен поисковые роботы сразу будут индексировать контент правильно.

Не будет такого, что вы установили на основной сайт SSL сертификат, сообщили поисковикам об изменениях, а потом начали заниматься редиректами и изменением внутренних ссылок.

В процессе вас ещё что-то отвлекло… И, в итоге, когда вы доделаете всю работу, у вас есть все шансы обнаружить в кабинетах вебмастеров Google, Яндекс и Bing кучу ошибок, из-за которых позиции вашего сайта в выдаче уже начали падать.

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

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

Единственное, в случае работы с копией сайта, приведённая ранее инструкция будет слегка отличаться.

Сперва я рекомендовал бы скопировать сайт и подключить к нему SSL сертификат на сервере. Затем я бы откорректировал все внутренние ссылки и сделал бы 301 редиректы. Исправил бы robots.txt и добавил бы канонические тэги.

После этого, когда я бы убедился, что всё в порядке, я добавил бы сертификат на основной сервер и подключил бы его к доменному имени сайта с переносом файлов сайта с тестового домена на основной.

Спрашивается: а что делать, если сертификат был куплен на одно доменное имя? Как его использовать на тестовом поддомене?

Всё просто: купленый сертификат устанавливаем на сервере, где будет размещаться основной сайт, а также подключаем его к основному домену. Для тестового можно использовать бесплатный SSL сертификат от Let’s Encrypt либо самоподписанный.

Ну, а если вы купили Wildcard сертификат или вообще мультидоменный, то проблем с этим нюансом у вас не будет в принципе.

Как видите, проблем может возникнуть масса. Особенно у «матёрых» сайтов с большой посещаемостью и историей, которые сегодня активно переходят на HTTPS.

Но, если вы только собираетесь создавать сайт и лишь «прощупываете почву» по поводу HTTPS и SSL сертификатов, то я бы однозначно рекомендовал бы устанавливать их с самого старта проекта, чтобы избежать трудностей перевода в будущем :-)

И вот, почему…

Перевод сайта на HTTPS — выводы

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

Дело даже не в возросшем уровне киберпреступности, а в том, что компания Google, являющаяся владельцем крупнейшего в мире одноимённого поисковика, постоянно стимулирует вебмастеров делать перевод с HTTP на HTTPS своих ресурсов на данный протокол.

Последним новшеством стала отметка сайтов, работающих по HTTP протоколу, как небезопасных, в Google Chrome, начиная с 29 января 2017 года и 56 версии браузера.

А, учитывая, что сегодня Google Chrome используют более 55% всех пользователей Интернет, то существует большая вероятность, что те из них, кто ничего не знает о данной особенности браузера и HTTPS протоколе в целом, просто уйдут с вашего сайта в поисках «безопасного».

Правда, данные санкции касаются не всех сайтов, а только тех, где имеются формы для ввода информации пользователем.

Блогов, похоже, это не коснётся, т.к. данный сайт отображается в Google Chrome 59 в штатном режиме без всяких предупреждений.

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

И чем раньше вы его сделаете, тем лучше.

Тем более, что временная потеря трафика на сайте — это не обязательное последствие перевода сайта на HTTPS. Поисковые системы и их алгоритмы — вещи непредсказуемые, о чём неоднократно заявляли их инженеры.

Поэтому вполне возможна ситуация, когда переезд сайта на HTTPS с HTTP  приведёт к росту посещаемости практически с первых дней, как это произошло на этом сайте:

uvelichenie-trafika-posle-pereezda-na-https

Главное следовать изложенной в статье пошаговой инструкции как перевести сайт на HTTPS и руководствоваться рекомендациями в процессе.

Пишите свои отзывы в комментариях, делитесь своим опытом переезда на HTTPS и указывайте мне на мои ошибки. Это тоже нужно :-)

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

Всем удачи и до новых встреч!

Импорт базы данных MySQL в консоли

import-bazy-dannyh-mysqlДоброго времени суток, коллеги :-)

Сегодня я продолжу знакомить вас с работой с MySQL в консоли и командной строкой MySQL.

Я уже написал статьи о том, как производить основные действия с данными MySQL через консоль и делать бэкап базы MySQL, а также экспорт хранимой в ней информации.

Логическим продолжением этого повествования будет восстановление БД и хранящейся в ней информации с помощью операций импорта базы данных MySQL. И, что немаловажно, мы продолжим делать это с помощью инструмента всех трушных разработчиков — через консоль.

Если же вам нужна инструкция по импорту базы через phpMyAdmin, то вы можете найти её в статье о переносе WordPress на хостинг. В текущей статье я не горю желанием описывать её ещё раз, тем более, что сегодняшний материал будет посвящён исключительно импорту базы MySQL через консоль.

Но, перед тем, как мы приступим к обзору способов и инструментов, немного философии на тему «Что такое импорт базы данных MySQL, каким он бывает и как его лучше всего делать?».

Потерпите 😉

Импорт базы данных MySQL: что и зачем?

Итак, импорт, как и экспорт БД MySQL, бывает двух видов информации, хранящейся в базе:

  1. структуры базы, её таблиц и хранимых в них данных (в простонародье именуемых дампом БД);
  2. просто данных, хранящихся в таблице либо собранных с помощью SELECT запросов.

В данной статье будут рассмотрены оба варианта.

Для восстановления из дампа MySQL базы данных с её структурой и всей хранимой информацией, как уже было сказано, нужен файл дампа БД, который представляет из себя текстовый файл с любым расширением (предварительно может быть запакован в архив для уменьшения размера), содержащий SQL команды для создания самой базы и таблиц, а также наполнения их информацией.

Следовательно, для того, чтобы восстановить MySQL базу из дампа, требуется выполнение содержащихся в файле команд.

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

Для этих целей подойдёт и обычный txt файл, данные в котором будут разделены, либо файлы, создаваемые в специальных табличных редакторах (Microsoft Office Excel, OpenOffice и т.д.), имеющих отличное расширение: xls, csv, odt и др.

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

Добавление данных в MySQL: инструменты

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

Перечислю их, начиная с самых низкоуровневых, заканчивая высокоуровневыми (с точки зрения применения всяческих оболочек и надстроек):

  1. Консоль сервера и командная строка MySQL;
  2. Скрипты, написанные на языках программирования, позволяющие делать запись данных в MySQL с помощью языковых средств;
  3. Готовые программы, предоставляющие визуальный интерфейс для работы с БД (тот же самый phpMyAdmin, MySQL WorkBench, MySQL Manager и др.).

Думаю, что порядок расположения инструментов не вызовет ни у кого вопросов, т.к. средства языков программирования, как правило, работают на базе команд консоли MySQL, а программы базируются на скриптах или же работают с MySQL командной строкой напрямую.

Так или иначе, во главе всего лежит консоль, а остальные инструменты, по сути, являются её эмуляторами.

Поэтому использование консоли при импорте данных в MySQL позволяет обойти различного рода ограничения, устанавливаемые настройками языков программирования на Web сервере и самих программ (которые, кстати, не всегда возможно изменить).

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

Думаю, все, кто хоть раз пытался загрузить дамп в MySQL БД большого размера через phpMyAdmin, понимают, о чём я говорю.

Зачастую именно эти лимиты являются причинами ошибок при импорте базы данных MySQL, которые при использовании консоли вы никогда не увидите.

Они, конечно, не константны, и их можно изменить, но это дополнительная головная боль, которая для рядовых пользователей, кстати, может оказаться нерешаемой.

Надеюсь, что я замотивировал вас делать импорт базы данных MySQL через консоль (причём, как её структуры, так и отдельно данных).

И на этой позитивной ноте мы переходим к долгожданной практике и рассмотрим способы и команды для консольного переноса данных в базу.

Как восстановить MySQL базу из дампа через консоль?

Итак, для того, чтобы развернуть дамп MySQL из консоли есть два пути:

  1. с помощью команды в командной строке MySQL;
  2. в самой консоли сервера.

Начнём по порядку.

Итак, чтобы импортировать дамп базы данных MySQL в существующее хранилище через командную строку MySQL, нам сначала нужно её запустить и выбрать нужную базу данных, в которую мы будем заливать наш дамп.

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

После того, как вы сделаете указанное, вводим в MySQL Shell следующую команду:

source путь_и_имя_файла_дампа;

Всё, что нам останется — это изучать сообщения в консоли о ходе выполнения операций, содержащихся в дампе.

Без предварительного переключения на нужную базу данных после соединения с сервером MySQL в консоли дамп можно импортировать следующей командой:

mysql -u имя_пользователя -p имя_базы_данных &lt; путь_и_имя_файла_дампа

Вот и всё. Главное — дождаться окончания импорта, если файл очень большой. Об окончании заливки дампа можно судить по тому, когда консоль сервера будет снова доступна.

Собственно говоря, в этом и заключается недостаток данного способа по сравнению с предыдущим, т.к. в первом есть возможность наблюдать за операциями, производимыми с БД во время импорта, а во втором — нет.

Если файл дампа будет запакован в архив, то при загрузке нужно будет его попутно распаковывать.

В Linux это можно сделать следующим образом:

gunzip < [имя_файла_архива.sql.gz] | mysql -u [user] -p[password] [databasename]

В Windows стандартной утилиты для распаковки архива в консоли нет, поэтому её нужно будет установить дополнительно.

Как видите, импорт дампа MySQL через консоль – операция весьма простая, которая выполняется одной командой. Так что для выполнения данной процедуры не обязательно быть разработчиком.

Если вдруг вы не знаете, как запустить консоль сервера, то можете найти эту информацию в статье о командной строке MySQL, ссылку на которую я уже располагал ранее.

Кстати, описанными способами возможен также и импорт таблицы MySQL, а не целой базы. В этом случае в заливаемом вами дампе должны присутствовать операции её создания и наполнения данными.

Загрузка данных в MySQL базу из файла в консоли

О восстановлении БД MySQL из дампа в консоли мы поговорили. Теперь самое время разобраться с тем, как аналогичным образом можно импортировать данные из файлов, в том числе из xls и csv в MySQL базу.

Для данной задачи у нас снова есть те же два инструмента, что и в предыдущем случае: командная строка MySQL и консоль сервера.

Снова начнём обзор по порядку.

Итак, для импорта файла в MySQL командной строке мы снова запускаем её и переходим на БД, в которую будут загружаться данные.

А далее прописываем в консоли следующую SQL команду:

LOAD DATA INFILE 'путь_и_имя_файла_дампа'
INTO TABLE `таблица_базы_данных`
COLUMNS TERMINATED BY ',' ENCLOSED BY '\"'
LINES TERMINATED BY '\n';

Не забудьте, что, если сервер MySQL был запущен с опцией —secure-file-priv (что часто бывает при использовании MySQL дистрибутивов, входящих в WAMP/MAMP сборки), то имя файла нужно указывать с учётом системной переменной secure_file_priv.

О том, как узнать её значение и изменить его, подробно написано в статье об экспорте базы данных MySQL.

Для того, чтобы сделать импорт базы данных MySQL в консоли сервера, не заходя в MySQL Shell, нам пригодится утилита mysqlimport, входящая в состав дистрибутива MySQL, и следующий её вызов:

mysqlimport –u имя_пользователя –p имя_базы_данных имя_и_путь_к_файлу_импорта

Данная утилита является аналогом SQL команды LOAD DATA INFILE, только для командной строки. Но, спрашивается, почему тогда среди параметров её вызова не указана таблица, в которую будут загружаться данные из файла?

Дело в том, что у mysqlimport просто физически нет данного параметра. Вместо этого имя таблицы, в которую будут загружаться данные, должно присутствовать в имени импортируемого файла.

Т.е. если вы захотите сделать импорт из Excel таблицы в MySQL таблицу users, то ваш файл должен называться users.xls.

Расширение у импортируемого файла, как уже говорилось, может быть любым.

С помощью mysqlimport также можно загружать сразу несколько файлов xls или csv в MySQL. Чтобы данные попали по назначению, названия файлов и таблиц БД, как и в предыдущем примере, также должны совпадать.

Если вдруг в импортируемом файле столбцы идут не в той же последовательности, что и колонки таблицы БД, то для уточнения их порядка нужно использовать опцию —columns в следующем виде:

mysqlimport –u имя_пользователя –p имя_базы_данных --columns столбец1, столбец2, … имя_и_путь_к_файлу_импорта

Естественно, что в своих примерах я не рассмотрел полный список параметров mysqlimport, т.к. некоторые из них весьма специфичны и на практике используются крайне редко.

Если захотите ознакомиться с ними самостоятельно, то полный их список доступен здесь — https://dev.mysql.com/doc/refman/5.7/en/mysqlimport.html

Особенности загрузки данных в MySQL базу из дампа

Если хотите, чтобы процесс импорта большой базы MySQL проходил быстрее, то необходимо создавать дамп БД с использованием специальных опций команды mysqldump, о которых я писал в своей предыдущей статье об экспорте БД MySQL, ссылку на которую размещал в тексте ранее.

У самих команд импорта баз данных MySQL таких опций, к сожалению, нет.

Единственное, для увеличения скорости при загрузке большого дампа БД можете использовать следующую фишку.

1. Открываем файл дампа (желательно в файловых менеджерах, т.к. обычные редакторы могут просто загнуться от больших файлов).

2. Прописываем в начале файла следующие строки:

SET foreign_key_checks = 0;
SET UNIQUE_CHECKS = 0;
SET AUTOCOMMIT = 0;

Обратите внимание! Может быть они уже есть или закомментированы (многие программы, с помощью которых делают дампы, могут добавлять их автоматически)

3. В конце файла прописываем обратные действия:

SET foreign_key_checks = 1;
SET UNIQUE_CHECKS = 1;
SET AUTOCOMMIT = 1;

Кстати, данные команды помогут не только ускорить процесс импорта, но и сделать его возможным.

Дело в том, что, если вы хоть раз заглядывали в файл дампа для импорта БД MySQL, то могли заметить, что операция задания структуры загружаемых таблиц выглядит так:

DROP TABLE IF EXISTS `clients`;
CREATE TABLE `clients` (
…
);

Т.е. выполняется поиск в БД таблицы с таким же именем, как и у импортируемой, и если таковая найдена, то она удаляется и создаётся заново.

И если вдруг существующая таблица будет связана внешними ключами с другими, то вся загрузка провалится.

Поэтому отключение проверки существования внешних ключей и прочих – это ещё и отличная гарантия успешного выполнения процесса импорта базы данных MySQL.

Особенности импорта csv в MySQL БД и других файлов

При загрузке данных в MySQL БД из текстовых файлов может также потребоваться отключение внешних ключей.

Причём, в отличие от предыдущей ситуации, в данном случае прописать директивы в файл не получится, т.к. SQL команды в нём не будут восприниматься и выполняться.

В предыдущей статье об экспорте базы MySQL я уже упоминал о том, как это сделать с помощью следующей операции в командной строке MySQL:

SET FOREIGN_KEY_CHECKS=0;

Однако, там я не упомянул, что системная переменная MySQL FOREIGN_KEY_CHECKS имеет два значение: глобальное и сессионное (для текущей сессии).

Глобальное значение переменных MySQL действует при выполнении любых действий на сервере MySQL вплоть до его перезапуска. Тогда значение переменных будут сброшены и им будет присвоено значения по умолчанию.

Сессионное значение системной переменной MySQL устанавливается только на время сеанса работы пользователя с сервером MySQL. Сеанс или сессия начинается при подключении клиента к серверу, при котором ему присваивается уникальный connection id, и заканчивается при отключении от сервера, которое может произойти в любой момент (например, по таймауту).

Почему я об этом решил вспомнить?

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

В консоли всё так же выдавалось сообщение об ошибке, вызываемой наличием в таблице внешних ключей.

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

SET SESSION имя_переменной = значение_переменной;
SET @@session.имя_переменной = значение_переменной;
SET @@имя_переменной = значение_переменной;

В приведённых командах переменная явно помечается как сессионная.

А, поскольку, я выполнял загрузку csv файла в MySQL таблицу через консоль сервера, без прямого подключения к серверу MySQL, то сеанс и не был создан, в рамках которого работало бы моё сессионное значение переменной.

В итоге я установил глобальное значение FOREIGN_KEY_CHECKS, и импорт успешно выполнился.

Сделать это можно одним из перечисленных способов:

SET GLOBAL имя_переменной = значение_переменной;
SET @@global.имя_переменной = значение_переменной;

После изменения значений для проверки того, что изменения вступили в силу, не лишним будет просмотреть значения переменной. Для вывода сессионного и глобального значений одновременно пользуйтесь следующей командой:

SELECT @@GLOBAL.foreign_key_checks, @@SESSION.foreign_key_checks;

На этом сегодняшняя статья, посвящённая импорту базы данных MySQL, подошла к концу. Делитесь своими впечатлениями и собственными наработками в комментариях. Думаю, что многим будет интересен ваш опыт.

Если публикация вам понравилась — вы всегда можете поделиться ею со своими друзьями в социальных сетях и сказать спасибо автору с помощью формы под статьёй.

До новых встреч! :-)

Делаем дамп базы MySQL и экспорт данных в консоли

damp-bazy-mysqlПриветствую вас, друзья! :-)

Сегодня я решил продолжить разговор о работе с MySQL в консоли и уделить внимание процедуре экспорта базы данных MySQL.

В статье я расскажу о том, как сделать дамп базы MySQL, а также производить выгрузку данных из MySQL в Excel файл и csv формат.

Мы рассмотрим различные варианты выборки информации из базы данных сайта: создание дампа одной и нескольких БД, экспорте данных из отдельных таблиц и результатов произвольных SELECT запросов.

А также поговорим о том, как сделать вывод данных из MySQL базы в консоли сервера и командной строке MySQL.

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

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

А, во-вторых, я уже вкратце сам рассматривал процесс вывода информации из MySQL базы в SQL файл в одной из своих статей, где рассказывал об установке WordPress на хостинг.

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

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

На этом вступительная часть окончена и мы переходим к обзору консольных команд для создания дампа базы MySQL, которые я решил рассортировать по объёму сохраняемых данных: начиная от экспорта всей БД, заканчивая отдельными таблицами и результатами произвольных запросов.

Создание дампа базы MySQL через консоль

Хочу в самом начале сделать небольшое уточнение.

Дамп базы — это файл с набором SQL команд, который при запуске позволяет создавать базы данных и таблицы, а также наполнять их информацией. Дамп нужен тем, кто хочет скачать базу данных MySQL с целью её копирования на другой сервер или в рамках существующего.

Также, если кто-то не в курсе, бэкап базы данных MySQL — это, по сути, её дамп, сделанный в определённый период времени, который позволяет восстановить структуру и данные базы при необходимости.

Экспорт данных — это просто извлечение информации из таблиц в текстовом виде для дальнейшей работы с текстовом или графическом редакторах.

Следовательно, команды для данных действий будут немного разные.

Для создания дампа БД у MySQL есть встроенная утилита под названием mysqldump, которую нужно использовать за пределами командной строки MySQL в консоли сервера или другой оболочке.

Итак, для самого простого и распространённого варианта — экспорта данных конкретной БД в консоли MySQL для переноса её на другой сервер или внутреннего копирования нужно выполнить следующую команду:

mysqldump -u имя_пользователя -p имя_базы_данных > путь_и_имя_файла_дампа

Данная утилита может создавать дампы базы MySQL только в виде файлов с SQL командами, поэтому какое бы вы расширение для своего файла не выбрали — в любом случае его содержимое будет одинаковым. И не забудьте перед экспортом информации из MySQL проверить права на запись у директории, в которой он будет располагаться, чтобы создание файла было возможно.

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

mysqldump -u имя_пользователя -p --all-databases > путь_и_имя_файла_дампа

Для создания дампа лишь для нескольких конкретных баз данных вам понадобится вызов mysqldump со следующими параметрами:

mysqldump -u имя_пользователя -p --databases имя_базы_данных1, имя_базы_данных2, ... > путь_и_имя_файла_дампа

В итоге, в каждом случае вы получите дамп базы MySQL, содержащий команды для создания структуры содержащихся таблиц (поля, их типы, индексы, ключи и т.д.), а также операции наполнения их данными.

Данный вариант годится только для восстановления и копирования баз данных целиком.

О том, как делать бэкапы определённых таблиц MySQL и получать их данные в читаемом виде, речь пойдёт дальше.

Делаем дамп таблицы MySQL и экспорт данных

Для создания дампа определённых таблиц MySQL базы данных нам понадобится всё та же утилита mysqldump, вызываемая со следующими параметрами:

mysqldump -u имя_пользователя -p имя_базы_данных имя_таблицы1, имя_таблицы2, ... > путь_и_имя_файла_дампа

Ещё при вызове mysqldump можно указывать требуемые таблицы в качестве значения параметра —tables, при использовании которого параметр —databases будет игнорироваться:

mysqldump -u имя_пользователя -p --databases имя_базы_данных1, имя_базы_данных2 --tables имя_таблицы1, имя_таблицы2, ... > путь_и_имя_файла_дампа

Приведённый пример выведет на экран следующую ошибку:

mysqldump: Got error: 1049: Unknown database 'имя_базы_данных1,' when selecting the database

Как видите, будет использоваться только самая последняя БД из списка указанных. В принципе, такое поведение вполне логично, т.к. во всех БД указанных таблиц может не оказаться.

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

А что, если нужно получить просто хранимую в них информацию и, желательно, в читаемом виде, чтобы можно было её отправить менеджеру и просмотреть в обычном текстовом или табличном редакторе? У MySQL есть средства и для этого.

Достичь задуманного нам поможет вариант вызова утилиты mysql из консоли с определёнными параметрами:

mysql -u имя_пользователя -p имя_базы_данных -e "SELECT * FROM имя_таблицы"

Данная команда позволит нам выполнить запрос к требуемой БД и вывести результат в консоль, не заходя в командную строку MySQL.

Ну, а для того, чтобы не выводить данные в консоль, а записать их в файл, нужно дополнить команду следующим образом:

mysql -u имя_пользователя -p -e "SELECT * FROM имя_таблицы" > путь_и_имя_файла

Благодаря данным конструкциям мы можем не только получить данные, хранящиеся во всех полях таблицы, но и в конкретных. Для этого достаточно вместо символа wildcards (*) прописать через запятую требуемые.

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

Если же захотите экспортировать данные из MySQL базы в xls или csv формате, чтобы полученный файл корректно отображался в табличных редакторах, то о том, как это сделать будет рассказано немного позже :-)

Создание бэкапов и вывод данных из MySQL базы с помощью запросов

О том, как сделать дамп базы данных MySQL — одной и нескольких, а также отдельных их таблиц, мы поговорили. Но иногда на практике бывают случаи, когда нужно экспортировать набор данных, не ограниченный одной таблицей. Либо нужно выбрать лишь некоторые данные из таблицы.

Особенно часто с таким сталкиваются разработчики корпоративных проектов, когда менеджеры просят их предоставить всякие статистические данные. Либо когда нужно сделать бэкап определённой части таблицы для её быстрого восстановления.

Для бэкапа нам понадобится всё та же утилита mysqldump, которую нужно будет вызвать в таком виде:

mysqldump -u имя_пользователя -p имя_базы_данных имя_таблицы --where "уточняющий_запрос" > путь_и_имя_файла_дампа

В результате мы получим файл с SQL командами для создания таблицы со всей его структурой, которая после создания будет наполняться информацией, выбираемой с помощью уточняющего запроса.

Если нам будет нужно просто получить данные, хранящиеся в одной или нескольких таблицах, то нам потребуется модификация команды, используемой в предыдущем случае при выборке всех данных таблицы, только с некоторыми уточнениями:

mysql -u имя_пользователя -p -e "SELECT * FROM имя_таблицы WHERE уточняющий_запрос" > путь_и_имя_файла

Как вы понимаете, помимо различных уточнений, указываемых в запросе с помощью директивы WHERE, можно использовать и прочие SQL конструкции: JOIN, UNION и т.д.

Статистику собрать получится какую угодно :-)

То же самое действие возможно произвести также при работе в командной строке MySQL с помощью следующей команды:

SELECT * FROM таблица_базы_данных WHERE уточняющий_запрос INTO OUTFILE 'путь_и_имя_файла';

Данная команда как раз и предназначена для создания файлов с результатами выборки. Причём, результаты можно не только экспортировать в файлы, но и записывать в переменные, а также выводимые данные можно форматировать различными способами.

Если перечисленное — ваш случай, то с полным списком параметров и вариантов вызова данной команды вы можете ознакомиться здесь — https://dev.mysql.com/doc/refman/5.7/en/select-into.html

Далее речь как раз пойдёт о корректном выводе данных MySQL в xls и csv форматы с помощью данной команды. А с musqldump в рамках данной статьи мы прощаемся.

В завершение своего краткого экскурса по mysqldump хочу привести вариант вызова команды со списком параметров для создания оптимизированного дампа базы MySQL и таблиц, восстановление БД и отдельных таблиц из которого будет занимать меньше времени, чем при обычном вызове:

mysqldump -u имя_пользователя -h хост_или_IP_сервера_MySQL -p --no-autocommit --opt имя_базы_данных > путь_и_имя_файла_дампа;

Ради эксперимента я использовал данный вариант для того, чтобы сделать дамп базы MySQL размером в 143 Мб. Последующее восстановление заняло 59 секунд времени против 1 минуты и 3 секунд, когда БД восстанавливалась из дампа, сделанного вызовом mysqldump без специальных параметров.

Согласен, что это мелочь. Но это только в случае данного объёма данных. Если использовать данную методику при создании дампа размером более 1Гб, то разница будет более существенной.

Если вы столкнётесь с такой ситуацией, то не забудьте ещё предварительно запаковать дамп базы MySQL в архив. Лучше всего tar.gz. Тогда восстановление займёт ещё меньше времени.

Экспорт данных из MySQL в Excel и csv файлы

Я не зря объединил информацию о выводе информации из MySQL в эти два формата в одном блоке, т.к. они очень похожи, используются примерно одинаково (для структурирования информации в виде таблиц) и команды для экспорта будут вызываться одни и те же.

Как известно, единственным существенным различием между данными форматами является то, что расширение xls и xlsx имеют файлы, создаваемые в программе Microsoft Office Excel, которая работает только под Windows, а csv файлы являются более универсальными и операции с ними возможны во многих редакторах.

Это не значит, что xls нигде, кроме Microsoft Office Excel, не откроется. Тот же OpenOffice подтверждает обратное.

Но для такой возможности данная поддержка должна присутствовать в программном продукте. csv же файлы доступны для чтения даже в обыкновенном текстовом редакторе типа «Блокнот», только такая форма будет не совсем читабельной.

Начну с того, что экспортировать в xls или csv можно только результаты SQL запросов, работать с которыми мы с вами научились ранее, т.к. всю базу данных в один файл будет невозможно вывести за одну операцию.

Во-первых, это не оптимально, т.к. такой файл вряд ли откроется при больших объёмах хранящейся в БД информации. А, во-вторых, непонятно, как разбивать внутри файла информацию по таблицам и полям.

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

Если вы вдруг знаете, как можно экспортировать информацию из всей MySQL БД сразу в один или несколько xls файлов в консоли, то напишите об этом в комментариях. Думаю, почитать об этом будет полезно многим.

Итак, если мы говорим о том, как сделать экспорт данных из MySQL в xls и csv, то сделать это можно прямо в консоли сервера через утилиту mysql либо в командной строке MySQL, работой с которой я знакомил вас в предыдущей своей статье.

Начнём по порядку.

Экспортировать данные из MySQL базы данных в csv и xls форматы прямо в консоли сервера можно следующими командами.

На Linux системах:

mysql -u имя_пользователя -d имя_базы_данных -p -e "SELECT * FROM таблица_БД;" | sed "s/'/\'/;s/\t/\",\"/g;s/^/\"/;s/$/\"/;s/\n//g" > путь_и_имя_файла.csv

В принципе, при крайней необходимости можете сделать данной командой и экспорт данных MySQL в Excel файл. Но я, если честно, на практике данным не занимался и что выйдет в итоге — без понятия, т.к. работаю сейчас под Windows. Если будете пользоваться данной командой под Linux — напишите в комментариях, пожалуйста, о результатах вашей работы. Думаю, информация будет интересна всем.

На Windows:

Экспорт данных из MySQL таблиц в csv приведённой выше командой в данном случае, к сожалению, не удастся, т.к. у Windows, в отличие от Linux, нет встроенной консольной команды для работы с потоками, какой является sed в Linux.

Установить её, конечно, можно, но слишком много хлопот. Ещё, как вариант, можете использовать CygWin — эмулятор консоли Linux для Windows систем.

Хорошо, если она у вас уже установлена. В противном случае экспорт данных из БД MySQL выбранным способом принесёт нам слишком много хлопот.

Зато извлечение информации в xls файл прост как 5 копеек :-) Запустить его очень просто следующим способом, который я опробовал лично:

mysql -u имя_пользователя -d имя_базы_данных -p -e "SELECT * FROM таблица_БД;" > путь_и_имя_файла.xls

Открылся данный файл в Microsoft Office Excel вообще без всяких проблем. Единственное, при открытии на экран вывелось сообщение с предупреждением о том, что действительный формат открываемого файла отличается от указываемого его расширения.

Но при подтверждении действия документ открылся без трудностей — вся информация была разбита по ячейкам в том виде, в каком она хранилась в самой таблице.

Не знаю, возможно, при произведении каких-либо специфических действий в Microsoft Office Excel и возникнут проблемы в дальнейшем, я так глубоко не копался. При обычном просмотре данных, по крайней мере, я ничего необычного не встретил.

Если у вас в процессе использования экспортированного из MySQL xls файла возникнут какие-то проблемы либо в данной программе, либо в других, то дайте мне знать, пожалуйста, в комментариях.

Описанным выше путём можно экспортировать содержимое БД MySQL и в csv файл, в принципе. Но тогда данные из разных полей таблицы будут записаны скопом, без разделителей, что может плохо отображаться в различных программах для работы с таблицами, в которых обычно с csv файлами и работают.

OpenOffice, кстати, всё равно :-) Он автоматически разграничил информацию, полученную способом, которым мы экспортировали содержимое базы MySQL в xls. Не знаю, как он это делает — но рекомендую пользоваться :-)

Ну, а тот же самый Microsoft Office Excel отобразил всю информацию, соответствующую одной записи в таблице, записав её в одну ячейку без каких-либо разделителей. Думаю, что подобным образом поступят и другие редакторы таблиц.

Поэтому при экспорте базы данных MySQL в csv файлы нужно делать это, разделяя информацию специальными символами, воспринимаемыми редакторами.

И тут я плавно подошёл ко второму способу экспорта MySQL данных в csv и xls, который заключается в использовании командной строки MySQL.

Итак, для того, чтобы экспортировать данные MySQL в csv файл данным способом, нам нужна следующая команда:

SELECT * FROM таблица_базы_данных
INTO OUTFILE 'путь_и_имя_файла.csv'
FIELDS TERMINATED BY ',' ENCLOSED BY '"'
LINES TERMINATED BY '\n';

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

Данная команда также отлично подходит и для экспорта данных MySQL в xls файл для корректного отображения в Microsoft Office Excel. Только в этом случае разделители нам не нужны, т.к. они будут мешать в разбиении информации по ячейкам:

SELECT * FROM таблица_базы_данных INTO OUTFILE 'путь_и_имя_файла.xls';

Однако, на практике не всё так просто, как я описал. Во время выполнения команды вы можете столкнутся со следующей ошибкой в консоли, препятствующей выполнению экспорта:

ERROR 1290 (HY000): The MySQL server is running with the --secure-file-priv option so it cannot execute this statement

Она вызвана тем, что ваш MySQL сервер был запущен с опцией —secure-file-priv. Лично я столкнулся с данной проблемой из-за того, что для работы в консоли пользуюсь дистрибутивом MySQL, входящим в комплект WAMP OpenServer, который, в свою очередь запускает MySQL сервер данным образом.

Здесь есть два способа решения проблемы:

  • Изменить параметры запуска MySQL сервера
  • Изменить путь к конечному файлу экспорта MySQL

Первый способ мне показался слишком сложным, т.к. пришлось бы копаться в конфигурации OpenServer, которая не мною была написана со всеми вытекающими из этого обстоятельствами :-) Поэтому я решил пойти вторым путём. Если вы столкнулись с подобной проблемой — повторяйте за мной.

Сперва нужно зайти в командную строку MySQL и выполнить одну из следующих команд:


SHOW VARIABLES LIKE "secure_file_priv";
SELECT @@GLOBAL.secure_file_priv;

Результатом выполнения обеих будет значение глобальной переменной MySQL secure_file_priv, которая содержит путь к каталогу, через который могут осуществляться операции экспорта и импорта данных MySQL (в будущем ссылка на статью об импорте данных).

Т.е. при использовании команд LOAD DATA и SELECT … INTO OUTFILE экспортируемые и импортируемые файлы могут располагаться только внутри данного каталога.

В моём случае у данной переменной было вообще установлено значение NULL, т.к. я, как уже говорил, пользуюсь для работы в консоли утилитами MySQL из дистрибутива, входящего в OpenServer. Данное значение указывало на то, что операции экспорта данных MySQL и импорта с помощью указанных команд были вообще закрыты.

Как потом выяснилось, это распространённая ситуация в случае использования коробочных WAMP и MAMP серверов.

К сожалению, привычными методами изменения значений глобальных переменных MySQL в моём случае воспользоваться не удалось:

SET имя_переменной = значение;

В результате я увидел в консоли лишь следующую ошибку:

ERROR 1238 (HY000) at line 1: Variable 'secure_file_priv' is a read only variable</strong>.

В итоге, чтобы изменить значение переменной secure_file_priv и открыть операции экспорта и импорта, мне потребовалось зайти в файл конфигурации MySQL mysql.ini, который расположен в корневой директории дистрибутива MySQL, или к нему можно получить доступ иным способом, если MySQL входит в комплект вашего WAMP/LAMP/MAMP сборки сервера.

Вам, кстати, если захотите изменить путь к буферному каталогу обмена файлами, нужно будет сделать то же самое.

В моём случае в конфиге данная переменная уже существовала, только в закомментированном виде:

secure-file-priv = "%dprogdir%\\userdata\\temp"

Если у вас её не будет, то пропишите её с нуля в секции [mysqld] (по крайней мере, у меня она располагалась там).

Я её раскомментил и решил использовать в том виде, в каком она была прописана. Т.е. при экспорте данных из MySQL и их импорте обратно файлы у меня теперь будут храниться в каталоге c:\openserver\userdata\temp\.

После изменения конфига (любого, кстати), не забывайте перезапускать ваш сервер либо отдельную службу, настройки которой вы правили, если есть такая возможность, чтобы изменения вступили в силу!

Для уверенности, после перезапуска MySQL сервера ещё раз выводим на экран переменную secure_file_priv и копируем её значение в буфер обмена.

А теперь нам нужно вызвать команду, что и в начале, только перед названием файла, в который будет сохраняться информация из БД MySQL, прописать путь, хранимый в изменяемой нами переменной в следующем виде:

SELECT * FROM таблица_базы_данных INTO OUTFILE 'значение_secure_file_priv\имя_файла.csv';

После этого экспорт данных из MySQL в моём случае заработал.

Важный момент! Если вы работаете с MySQL под Windows, то не забывайте при указании пути к файлу поменять «\» на «/», иначе ошибка с —secure-file-priv всё равно продолжит выводиться.

На этом статья о том, как сделать дамп базы MySQL и её таблиц, а также сделать вывод данных из MySQL таблиц в различные форматы, подходит к концу. Пишите в комментариях свои отзывы и делитесь со всеми своими вариантами скриптов, которыми вы пользуетесь на практике чаще всего.

Если статья вам понравилась — вы можете поблагодарить автора репостом статьи в социальные сети или финансово с помощью формы ниже, чтобы была возможность элементарной оплаты хостинга.

Всем удачи и до новых встреч! :-)

the_posts_pagination(array( 'mid_size' => 3, 'prev_text' => __('« Предыдущая'), 'next_text' => __('Следующая »') ));