Установка и настройка веб-сервера iis + php + mysql

Содержание:

Работа с заголовками в PHP

В PHP есть все возможности для взаимодействия с протоколом HTTP:

  • Получение тела запроса;
  • Получение заголовков запроса;
  • Добавление/изменение заголовков ответа;
  • Управление телом ответа.

Разберём всё по порядку.

Получение тела запроса

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

В PHP-сценарии все данные отправленной формы будут доступны в специальном массиве . Более подробно об этом написано в следующей главе, посвящённой формам.

Получение заголовков запроса

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

Пример, как получить предыдущую страницу, с которой перешёл пользователь:

Добавление/изменение заголовков ответа

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

  • Кэширование;
  • Переадресация пользователя;
  • Установка cookies;
  • Отправка файлов;
  • Передача дополнительной информации браузеру.

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

За переадресацию отвечает заголовок с именем , а через двоеточие задаётся значение — адрес страницы для перехода.

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

Управление телом ответа

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

Структура URL адресов в админке

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

И сразу рассмотрим простой пример:

Итак, мы видим, что модулем здесь является products, а действием, к примеру, add. Что теперь с этим делать?

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

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

Перепишем пример, написанный нами в единой точке входа, под новую схему URL:

Итак, мы берём 1-ый фрагмент URL и проверяем, существует ли в папке pages файл с таким названием.

Т.е. при переходе на страницу /test/test2 скрипт проверит существование файла /pages/test.php. Если файл есть — PHP выполнит этот файл, в противном случае выполнится файл /pages/404.php.

Как видите, при таком подходе нам больше не нужно прописывать соответствие URL-адресов и PHP-файлов. PHP сам будет искать нужный файл в папке pages по первому фрагменту URL.

Теперь осталось только создать файл pages/products.php. Сделаем небольшую заготовку:

Вот так выглядит обработка действий. Мы смотрим на второй фрагмент URL и ищем обработчик этого действия. Для каждого действия (add, update, delete) нужно прописать отдельный блок elseif.

Внутри обработчика add мы смотрим на то, каким методом пришёл запрос, GET или POST. Если GET — отображаем форму, если POST — добавляем товар.

Если вам не нравится вложенная проверка метода, можно сделать иначе. В файле index.php сохраним метод в отдельную переменную:

products.php

Готово. Да, если вам не нравится, что в коде 2 раза встречается одно и то же действие, только с разными методами, можете использовать немного упрощённую схему URL-адресов из фреймворка Laravel:

Добавление префикса /admin/ в URL

Немного изменим код index.php:

Теперь при запросе страницы /admin/products PHP будет искать файл с названием не products.php, а admin_products.php.

Переименуйте файл и не забудьте заменить в нём все $segments на $segments, поскольку в $segments теперь лежит модуль, а в $segments действие.

Проксирование

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

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

1. На другой сервер

Пример внутреннего перенаправления http-запроса на другой веб-сервер:


location / {
            proxy_pass $scheme://192.168.0.15:8080/;
            proxy_redirect     off;
            proxy_set_header   Host             $host;
            proxy_set_header   X-Real-IP        $remote_addr;
            proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
}

* в данном случае, принимать запросы от браузера и отвечать на них будет NGINX, а сама обработка будет выполняться на сервере с IP-адресом 192.168.0.15 на порту 8080.

Использование NGINX в качестве http-прокси:

server {
        …
        server_name site1.ru www.site1.ru;
        location / {
            proxy_pass http://192.168.1.21/;
            proxy_redirect     off;
            proxy_set_header   Host             $host;
            proxy_set_header   X-Real-IP        $remote_addr;
            proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
        }
}
server {
        …
        server_name site2.ru www.site2.ru;
        location / {
            proxy_pass http://192.168.1.22/;
            proxy_redirect     off;
            proxy_set_header   Host             $host;
            proxy_set_header   X-Real-IP        $remote_addr;
            proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
        }
}

* в данном примере запросы на site1.ru будут перекинуты на сервер 192.168.1.21, а запросы на site2.ru — 192.168.1.22.

HTTP proxy с авторизацией (если удаленный веб-сервер требует аутентификации):

server {
    …
    location / {
        proxy_pass http://10.10.10.10/page/;
        proxy_set_header Authorization «Basic dGVzdDp0ZXN0»;
        …
    }
}

* где 10.10.10.10/page — страница, на которую будут перекинуты запросы; dGVzdDp0ZXN0 — логин:пароль test:test, закодированные в формате base64.

2. Часть url на другой сервер

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

server {
    …
    location  ~ ^/page1/(.*)$ {
        proxy_pass   $scheme://10.10.10.10/$1;
    }
}

* и так, в данном примере при обращении по адресу site.ru/page1/<что-то еще>, nginx сделает внутренний запрос на сервер 10.10.10.10 по адресу 10.10.10.10/<что-то еще> и вернет готовый ответ.

3. На другой сайт

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

server {
    …
    location / {
        proxy_pass https://www.dmosk.ru;
        proxy_set_header   Host             www.dmosk.ru;
        proxy_set_header   X-Real-IP        $remote_addr;
        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
    }
}

* в данном случае мы при обращении к нашему серверу будем попадать на сайт https://www.dmosk.ru

Обратите внимание, что в proxy_set_header мы передаем хосту его имя — в противном случае, как правило, другой сервер вернет ошибку. Также мы не указываем proxy_redirect, иначе, nginx будет переводить запросы на реальный сайт (отправлять инструкции браузеру перейти на него), а не тот, что мы используем за http-прокси

4. Редиректы при проксировании

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

server {
    listen 80;
    server_name dmosk.local www.dmosk.local;
    location / {
        proxy_pass https://www.dmosk.ru;
        proxy_set_header   Host             www.dmosk.ru;
        proxy_set_header   X-Real-IP        $remote_addr;
        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
        proxy_redirect https://www.dmosk.ru/url1 http://dmosk.local/url2;
        proxy_redirect https://www.dmosk.ru/ http://dmosk.local/;
    }
}

* в конкретном случае мы проксируем запросы http://dmosk.local на сайт www.dmosk.ru, но если он вернет инструкцию для редиректа https://www.dmosk.ru/url1, в браузере он должен быть заменен на http://dmosk.local/url2. А также любое перенаправление для https://www.dmosk.ru/ будет заменено на http://dmosk.local/.

Другие настройки (CGI, Python, Node.js)

Инструкция по настройке сервисов находится в соответствующем разделе .

Директивы SSI (Server Side Includes) по умолчанию обрабатываются в файлах с расширением .shtml (например, index.shtml). Чтобы SSI обрабатывались и в других файлах, необходимо в файле .htaccess указать типы этих файлов:

Вместо «.ssi .html» укажите расширения файлов, в которых должны обрабатываться директивы SSI. Использовать в одном и том же файле PHP и SSI одновременно не рекомендуется.

Для выполнения скриптов CGI в какой-либо папке необходимо настроить веб-сервер соответствующим образом с помощью файла .htaccess. В папке, в которой должны выполняться скрипты CGI, создайте файл .htaccess вида:

Вместо «.cgi .pl» укажите список расширений, которые должны обрабатываться как скрипты. С помощью Файлового менеджера или FTP-клиента установите файлам скриптов права на выполнение (755).

Проектам на языке Python необходим файл .htaccess с таким содержанием:

Чтобы обрабатывать скрипты Node.js, укажите в .htaccess следующие директивы:

Замените example.com на основное имя вашего сайта, а login на логин вашего аккаунта.

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

Параметры запроса

Мы привыкли, что на нашем сайте каждый PHP-сценарий отвечает за одну страницу. Посетитель сайта вводит в адресную строку путь, который состоит из имени домена и имени PHP-сценария. Например, так: .
Но как быть, если одна страница должна показывать разную информацию?

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

Из чего состоит URI

URI — это уникальный идентификатор ресурса. Ресурс в нашем случае — это полный путь до страницы сайта. И вот как может выглядеть ресурс для показа погоды за конкретный день:

Разберем, из чего состоит этот URI.
Во-первых, здесь есть имя домена: .
Затем идёт имя сценария:
А всё что идёт после — это параметры запроса.

Параметры запроса — это как бы дополнительные атрибуты адреса страницы. Они отделяются от имени страницы знаком запроса. В примере выше параметр запроса только один: date=2017-10-30.
Имя этого параметра:, значение: .
Параметров запроса может быть несколько, тогда они разделяются знаком амперсанда:

В примере выше указывается два аргумента: дата и единица измерения температуры.

Параметры запроса как внешние переменные

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

Получение параметров запроса

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

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

В этом задании вы сможете потренироваться использовать .

Формирование URI с параметрами запроса

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

Здесь мы использовали две функции:

  • — получает имя текущего сценария;
  • — преобразует ассоциативный массив в строку запроса.

Изменение кода статуса ответа и комментария статуса

В примерах выше статусом ответа был 200, и комментарий «OK».

Мы можем указать абсолютно любой статус ответа в диапазоне 100-599. Если указать статус 5xx, то веб-браузеры, поисковые системы и все остальные будут думать, что на сервере возникла ошибка — хотя на самом деле, никакой ошибки нет и наше сообщение успешно доставлено и успешно получен ответ.

Для демонстрации попробуем следующий код в нашем файле headers.php:

<?php

header("HTTP/1.1 599 Damn, dude, you broke everything!");

$headers = apache_request_headers();
if (isset($headers)) {
	header ('HackWare: I got your message: ' . $headers);
}

Откроем эту страницу в веб-браузере: http://localhost/headers.php

Как будто бы всё сломано и на сервере проблемы.

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

curl -v -H 'Hackware: Hello! How are you?' localhost/headers.php

Как можно увидеть, наше сообщение доставлено и процитировано в ответе.

Строка со статусом ответа включает три элемента:

  • номер HTTP версии (например, HTTP/1.1)
  • номер статуса ответа (любые цифры от 100 до 599 — если использовать другие цифры, то можно получить «настоящий» статус 5xx)
  • комментарий (например, для кода 200 комментарием является «OK») — здесь может быть что угодно

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

<?php

$headers = apache_request_headers();
if (isset($headers)) {
	header('HTTP/1.1 599 ' . 'I got your message: ' . $headers);
}

Отправляем в заголовке произвольную строку:

curl -v -H 'Hackware: Hello! How are you?' localhost/headers.php

И получаем её в строке статуса:

Я хотел ещё поменять строку с версией «HTTP/1.1», но средствами cURL/PHP это, видимо, сделать невозможно. В принципе, можно подключиться к Ncat и отправить какую угодно строку статуса ответа, чтобы посмотреть, как на это прореагирует HTTP клиент (но скорее всего, просто напишет, что-то в духе «получен неверный ответ»).

Установите и настройте Apache HTTPD

Apache HTTPD или просто «апач» чаще всего используется для обработки запросов и отправки сформированных скриптами ответов по протоколам HTTP и HTTPS

2.1. Загрузите архив с последней версией Apache HTTPD для 64–разрядной Windows: httpd-2.4.38-win64-VC15.zip. На всякий случай, проверьте на официальном сайте Apache Lounge нет ли версии новее: apachelounge.com/download.

Официальная сборка Apache под Windows не выпускается, сборки готовят отдельные организации, самой активной из которых является Apache Lounge. Сам Apache работает по HTTP и в Windows трудится как фоновый процесс, а в Linux — как демон (англ. daemon), откуда и название HTTPD. Существует Apache и под 32-битные версии Windows, для них необходима версия Win32, а не Win64. Указанные в имени файла VC15, VC14 и VC11 говорят о версии Visual Studio, которой скомпилирован Apache. Выберете самую последнюю версию и установите свежие вспомогательные файлы Visual Studio с официального сайта Microsoft: VC_redist.x64.exe.

2.2. Распакуйте архив и перенесите содержимое папки Apache24 в папку D:\web\apache.

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

2.3. Откройте файл D:\web\apache\conf\httpd.conf. Поиском по файлу найдите и измените значение на . Найдите и измените значения и на .

У Apache несколько файлов с настройками, все они находятся в папке conf (от слова configuration, «конфигурация» в переводе с английского). Основные настройки задаются в файле httpd.conf. Параметр ServerRoot задает корневую папку самой программы Apache, а DocumentRoot и Directory задают корневую папку хоста, то есть ту папку, в которой хранятся файлы сайта. Номера строк с параметрами могут меняться в новых версиях Apache, поэтому я их не привожу, поищите параметры по документам. Чтобы открыть окошко поиска в вашем текстовом редакторе, нажмите Ctrl + F.

2.4. В том же файле httpd.conf найдите, раскомментируйте и измените значение на .

Параметр ServerName задаёт доменное имя, по которому хост (иначе говоря, сайт) будет откликаться. Так повелось, что домен внутри компьютера называют localhost и этот домен соответствует IP–адресу 127.0.0.1. Для обращения к сайту можно использовать как доменное имя, так и IP–адрес. Порт под номером 80 используется в вебе для протокола HTTP без шифрования. Комментарии в файле конфигурации Apache предваряются октоторпом (символом решетки), сервер будет игнорировать такие строки.

2.5. В том же файле httpd.conf найдите и измените значение параметра ErrorLog на , а также значение CustomLog на common. Сохраните файл httpd.conf с перезаписью.

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

2.6. Установите Apache через командную строку. Откройте командную строку (или выполните команду cmd в PowerShell) от имени администратора и выполните команду .

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

2.7. Запустите «Диспетчер задач» Windows, перейдите на вкладку «Службы». Найдите Apache2.4 в списке служб, вызовите контекстное меню: так вы сможете запустить, остановить или перезапустить сервер. Запустите сервер.

В файлах сервера Apache для Windows также есть программа Apache Monitor, графический интерфейс, смысл которого ровно такой же: запускать, останавливать и перезапускать службу Apache2.4. Но в последней версии Windows 10 сильно проще попасть в список служб, поэтому смысла пользоваться Apache Monitor больше нет.

2.8. Откройте браузер и наберите адрес http://localhost/ или http://127.0.0.1/ — вы должны увидеть надпись Hello world.

Браузер обратится с запросом по 80 порту к тому же компьютеру, на который он установлен, и будет ждать ответа. Если установка Apache прошла без ошибок, но в ответе нет надписи Hello world — проверьте есть ли в каталоге D:/web/www файл index.html и еще раз пройдитесь по всем пунктам. Если все прошло успешно и в ответ вы получили файл index.html, то поздравляю, вы уже можете дополнять его кодом на HTML, CSS и JavaScript и обращаться к файлам по имени хоста.

2.0. Обновить Apache легко. Переименуйте папку D:\web\apache в apache_old, распакуйте новую версию Apache в D:\web\apache, перенесите httpd.conf из папки apache_old в папку apache. Если все работает — удалите apache_old.

Настройка перенаправлений

Настройки необходимо вносить в файлах конфигураций виртуальных доменов. В Linux на основе RPM (CentOS, Red Hat), как правило, они расположены в директории /etc/nginx/conf.d/. В Linux на основе Deb (Ubuntu, Debian) — в директории /etc/nginx/sites-enabled/. Во FreeBSD все в одном файле — /usr/local/etc/nginx/nginx.conf.

Саму настройку на перенаправление в NGINX можно прописать несколькими способами.

1. Первый:

rewrite ^ https://$host$request_uri? <флаг>;

* $host — имя хоста из запроса, если отсутствует — имя в поле «Host» заголовка, если тоже отсутствует — имя сервера; $request_uri — первоначальный запрос с аргументами (все, что идет после доменного имени).
** где флаги могут быть следующие:

  • permanent — перенаправление с кодом 301.
  • redirect — перенаправить с кодом 302.
  • last — закончить обработку с переходом в новый location.
  • break — закончить обработку и остаться в текущем location.

2. Второй: 

return <код> https://$host$request_uri;

* где коды могут использоваться любые, но чаще всего — 301, 302, 404.

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

После внесения изменений, необходимо проверить их корректность:

nginx -t

И для их применения перезапустить веб-сервер:

systemctl restart nginx

service nginx restart

* в первом примере перезапуск выполняется на новых системах Linux. Второй пример — на устаревших или FreeBSD.

Проверяя редиректы в браузере, следует учесть, что настройки могут кэшироваться. Для обновления кэша используйте комбинацию Ctrl + F5. Если и это не помогает, закрывайте вкладку и открывайте новую.

AMPPS Server

AMPSS is a powerful combination of WAMP, LAMP and MAMP stacks. In a way, it is a stack of stacks.

AMPSS offers many programs such as Apache, Mysql, MongoDB, PHP, Perl, Python and Softaculous auto-installer. In addition to AMP, AMPSS also offer SS, that is Softaculous Softwares.

Hence, a developer can choose the program that suits his Project.

Be it Windows, Linux or Mac OS, this Solution Stack could run on every Operating System. One function of AMPPS is allowing you to use the one-click installer of Softaculous.

This PHP server saves you valuable time as you don’t have to install or test software anymore.

You can spend your time developing and testing your projects.

The size of AMPPS is big, but when we see the amount of usefulness it brings to the table, the size does not seem to be a bug anymore.

If you are a developer that requires a lot of tools to start a project, AMPSS is the best PHP Server for you.

Отличия между 301 и 302 редиректами:

В чем принципиальная разница между ответом с кодом 301 и 302? Для обычного посетителя сайта разницы нет. А вот для поискового робота разница огромная.

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

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

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

Получение полного URL в PHP

Для получения полного URL вместе с имеющимися GET-параметрами, пригодится следующий код:

 $url = ((!empty($_SERVER'HTTPS'])) ? 'https'  'http') . '://' . $_SERVER'HTTP_HOST' . $_SERVER'REQUEST_URI'];
echo $url;

Что здесь что? В первую очередь, осуществляется проверка, какой именно протокол передачи данных задействуется: https или http. В случае, если значение $_SERVER не является пустым, речь идёт о протоколе https, в обратном случае — http.

На втором этапе выполняется присоединение двоеточия и двух слэшев, имени домена и остальной части URL.

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

Если протокол получать не требуется, код на PHP можно немного сократить:

Смотрим на результат и видим, что протокол отсутствует:

Настраиваем редиректы для SEO

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

При настройке 301 редиректов помните о двух правилах:

  1. Избегайте нескольких последовательных перенаправлений — они увеличивают нагрузку на сервер и снижают скорость работы сайта.
  2. Располагайте редиректы от частных к глобальным. Например, сначала переадресация с одной страницы на другую, затем общий редирект на страницы со слешем. Это правило работает не в 100% случаев, поэтому с размещением директив нужно экспериментировать.

1. Настраиваем постраничные 301 редиректы

Это потребуется в следующих случаях:

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

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

  • — адрес страницы от корня, без протокола и домена. Например, .
  • — полный адрес страницы перенаправления, включая протокол и домен. Например, .

2. Избавляемся от дублей

Каждая страница сайта должна быть доступна только по одному адресу. Для этого должны быть настроены:

  • редирект на страницы со слешем в конце URL или наоборот;
  • главное зеркало — основной адрес сайта в поиске.

Сделать это можно при помощи модуля . В его составе используются специальные команды — директивы сложного перенаправления. Первой командой всегда идет включение преобразования URL:

Переадресация на слеш или наоборот

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

Код 301 редиректа на страницы без слеша:

3. Настраиваем главное зеркало

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

Редирект на HTTPS

Определять, с «www» или без будет главное зеркало, можно несколькими способами:

  • добавить сайт в Яндекс.Вебмастер в двух вариантах, в консоли отобразится информация, какой URL поисковик считает главным зеркалом;
  • проанализировать выдачу и посмотреть, каких страниц сайта больше в индексе;
  • для нового ресурса не имеет значения, с «www» или без будет адрес, выбор за вами.

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

Редирект с без www на www

4. Перенаправляем с одного домена на другой

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

Воспользуйтесь одним из вариантов кода:

или

Не забудьте поменять в коде «mysite1» и «mysite2» на старый и новый домен соответственно.

Настройки веб-серверов в Панели управления

В настройках базового веб-сервера вы можете изменять все директивы PHP, значение графы Changeable для которых соответствует PHP_INI_PERDIR или PHP_INI_ALL. Эти настройки будут иметь силу на всех сайтах, которые работают на этом веб-сервере.

Управлять абсолютно всеми параметрами PHP вы можете на расширенном веб-сервере, редактируя php.ini через его настройки.

Чтобы установить индивидуальные параметры PHP для отдельного сайта, используйте файл .htaccess. Через него можно управлять всеми параметрами, доступными для изменения на базовом веб-сервере – примеры самых востребованных перечислены ниже.

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

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

Директория в пути расположения файла должна существовать, а если ее нет — обязательно создайте папку вручную. Файл журнала будет создан при появлении первой ошибки.

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

Вместо 512M укажите желаемый размер ограничения

Обратите внимание, что символ «M» (латинская M) указывается слитно со значением. Уточнить максимальное значение оперативной памяти, доступное по тарифу, можно в

Чтобы увеличить время выполнения скриптов (в секундах), добавьте следующую директиву в .htaccess:

Вместо 300 укажите желаемый размер ограничения

Обратите внимание, что выполнение скрипта более чем в 10 минут (600 секунд) завершится ошибкой с кодом 504

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

Вместо 200M укажите желаемый размер ограничения

Обратите внимание, что символ «M» (заглавная латинская M) указывается слитно со значением

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

Вместо 15000 укажите необходимый размер ограничения, который требует CMS сайта.

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

Вместо «windows-1251» подставьте подходящую кодировку, например, UTF-8. Проверить, в какой именно кодировке написан сайт, можно через инструменты используемого браузера. Если сайт не обрел корректный вид, обратитесь за помощью в службу технической поддержки.

Чтобы заставить интерпретатор PHP обрабатывать файлы с произвольным расширением, (например, .phtml), добавьте в файл .htaccess следующую строку:

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

По умолчанию время хранения сессий — 1440 секунд (24 минуты). Для изменения этого значения добавьте в .htaccess следующие директивы:

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

Альтернативные механизмы хранения и очистки сессий:

  1. Указывать вложенность директорий хранения сессий с помощью аргумента N в session.save_path и очищать старые сессии собственными скриптами ( в документации PHP).
  2. Реализовать собственный механизм хранения сессий (например, в MySQL) и установить его с помощью функции session_set_save_handler.

Настраиваем отображение сайта

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

10. Заменяем индексный файл

Индексный файл — тот, что открывается по умолчанию при обращении к определенному каталогу. Обычно они называются: index.html, index.htm, index.php, index.phtml, index.shtml, default.htm, default.html.

Вот как это выглядит в структуре каталога:

Чтобы заменить этот файл на любой другой, размещаете в каталоге .htaccess и добавляете эту команду:

Вместо «hello.html» вписывайте адрес желаемого файла.

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

11. Добавляем или убираем html в конце URL

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

Чтобы убрать .html:

Этими же директивами можно добавить/убрать расширение php.

12. Настраиваем кодировку

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

  • UTF-8 — универсальная
  • Windows-1251 — кириллица
  • Windows-1250 — для Центральной Европы
  • Windows-1252 — для Западной Европы
  • KOI8-R — кириллица (КОИ8-Р)

Чаще всего используют UTF-8 и Windows-1251.

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

Пример директивы, которая задает для файла кодировку UTF-8:

А такая команда означает, что все загружаемые на сервер файлы будут преобразованы в Windows-1251:

В примерах приведены разные кодировки, но в рамках одного сайта кодировки в этих директивах должны совпадать.

13. Создаем кастомные страницы ошибок

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

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

Зачем это нужно? Например, чтобы не потерять пользователя на странице 404, а дать ему возможность перейти в другие разделы сайта:

Why using PHP Server Stacks?

If you are a budding developer, you don’t know how frustrating it is to install a Web Server. 

It does not end at web servers, developers also have to install PHP, MariaDB, and sometimes Pearl, Ruby and other programming languages.

You can download them separately, and then install them to a same directory. And then you have to activate each of them before running the local host.

Else, you can easily download a PHP server, that is already stacked with the PHP, a database, OS, and a web server. They are a one-click installer of various useful programs that a developer needs to create an environment for web app deployment.

However, there are various type of PHP servers, depending on the requirements of the developer.

Let’s look at them in detail.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector