Глобальный массив $_server в php

Содержание:

Развертывание отдельного сайта
Регистрация
Получение полного URL в PHP
Заголовки Last-Modified и Content-Length
3.1 Content-Type: application/x-www-form-urlencoded.
Модификация URL в htaccess
Структура URL адресов в админке
- Добавление префикса /admin/ в URL
Установка и настройка WordPress на сервер Linux
Настраиваем редиректы для SEO
Проксирование
Общие правила работы с .htaccess
Настройка HTTP-сервера Apache
- 2. Создание тестовой страницы
- 3. Конфигурация Apache-сервера
AMPPS Server
Установка IIS

Развертывание отдельного сайта

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

Открываем Диспетчер серверов — кликаем по Средства — Диспетчер служб IIS:

Находим раздел сайты — кликаем правой кнопкой мыши по Добавить веб-сайт…:

Заполняем данные для нового сайта:

* где:

Имя сайта — произвольно имя будущего сайта.
Физический путь — путь до папки на сервере, где будут расположены файлы сайта.
Тип — тип соединения (http или https). Для первого запуска обойдемся http. При необходимости, его можно всегда поменять или использовать оба типа одновременно.
IP-адрес — если на сервере много IP-адресов, то мы можем выбрать конкретный, на котором будет работать сайт.
Порт — сетевой порт, на котором будет работать сайт. Как правило, это 80 для http или 443 для https.
Имя узла — доменное имя сайта, при обращении по которому должен открываться создаваемый сайт.

После заходим в каталог с сайтом (в нашем примере, это C:\inetpub\wwwroot\php) и создадим в нем файл index.html со следующим содержимым:

<h1>Hello from PHP site</h1>

Открываем браузер и переходим на созданный сайт, например, как в нашей инструкции — http://php.dmosk.ru. Мы должны увидеть страницу с написанным нами текстом:

Тестовый сайт создан.

Регистрация

Php суперглобальные переменные — $_server

Чтобы зарегистрироваться на Seosprint, выполните следующие действия:

1. На главной странице почтовика (Seosprint.net) щёлкните кнопку «Регистрация».

2. Заполните открывшуюся форму:

«Как вас зовут?»: ваше имя (можно использовать псевдоним);
«Укажите… e-mail»: введите адрес действующего почтового ящика (не используйте временный email!);
«… номер мобильного»: укажите номер телефона с международным кодом (для РФ — «+7», для Украины — «+380»);
«ID вашего реферера» — идентификатор пользователя, который пригласил вас работать на сайт.

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

3. Введите капчу: перепечатайте в нижнее поле символьный код с картинки.

4. На странице «Завершение регистрации» проверьте свою анкету. Если вы регистрировались без ID реферера, в нижней строке отобразится сообщение «Вы пришли самостоятельно… ».

5. Удерживая клавишу «Ctrl», кликните левой кнопкой по иконкам «Правила проекта… » и «Условия предоставления… ». Документы откроются в новых вкладках. Внимательно ознакомьтесь с ними.

6. Вернитесь на исходную вкладку. Чтобы завершить регистрацию на Seosprint, ответьте на контрольные вопросы. Щелчком мыши включите кнопки возле правильных ответов.

На скриншоте указаны правильные ответы

7. Нажмите «Зарегистрироваться».

После создания учётной записи сервис вышлет вам на телефон СМС-сообщение с паролем для входа на сайт и ПИН-код для выполнения платёжных операций (пополнение/вывод). Запишите их или сохраните в отдельный текстовый файл.

Получение полного 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 можно немного сократить:

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

Заголовки Last-Modified и Content-Length

Как отсортировать массив ассоциативных массивов по значению заданного ключа в php?

Заголовки Last-Modified и Content-Length сообщаю когда документ был изменён последний раз и его размер. Поисковые роботы и браузеры отправляют в запросе заголовок If-Modified-Since, на который веб-сервер
может либо выдать новую страницу либо 304 Not Modified.
Для статических файлов эти параметры определяются легко.

Content-Type: image/png
Content-Length: 5922
Last-Modified: Mon, 27 Jan 2020 10:48:16 GMT

Сложнее с динамическими файлами, например с php. ETag взаимосвязан с датой последней модификации и размером содержимого

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

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

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

Может изменяться сам код php-файла, а данные и html-код которые он выдаёт могут не измениться. В этом случае неправильно говорить, что Last-Modified изменился.
Но для простоты можно считать, что любое изменение файла ведёт к изменению Last-Modified.
Для данных мы должны ориентироваться на дату изменения данных в строке таблицы. Эта задача может быть нетривиальной для страниц, где отображается множество данных из разных таблиц.
Но если страница отображает одну сущность, например, конкретную новость, статью, счёт, платёж, то там дата последней модификации известна. Для страниц,
где собирается множество данных из разных таблиц нужно иметь таблицу в которой lastmodified соответствующей строки будет обновляться триггером.

Можно ориентироваться на хеш от выдаваемых данных. Если хеш md5 изменился, то меняем Last-Modified. Эту задачу лучше всего поручить проксирующему серверу Nginx.

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

curl -I —header ‘If-Modified-Since: Mon, 30 Apr 2029 18:13:12 GMT’ https://itsoft.ru
curl -I —header ‘If-None-Match: «a49f2da878be351c6c73a1ec0524d8ea»‘ https://itsoft.ru
curl -I —header ‘Accept-Encoding: gzip’ https://itsoft.ru

3.1 Content-Type: application/x-www-form-urlencoded.

Пишем запрос, аналогичный нашему запросу GET для передачи логина и пароля, который был рассмотрен в предыдущей главе:

POST http://www.site.ru/news.html HTTP/1.0\r\n
Host: www.site.ru\r\n
Referer: http://www.site.ru/index.html\r\n
Cookie: income=1\r\n
Content-Type: application/x-www-form-urlencoded\r\n
Content-Length: 35\r\n
\r\n
login=Petya%20Vasechkin&password=qq

Здесь мы видим пример использования Content-Type и Content-Length полей заголовка. Content-Length говорит, сколько байт будет занимать область данных, которая отделяется от заголовка еще одним переводом строки \r\n. А вот параметры, которые раньше для запроса GET помещались в Request-URI, теперь находятся в Entity-Body. Видно, что они формируются точно также, просто надо написать их после заголовка. Хочу отметить еще один важный момент, ничто не мешает, одновременно с набором параметров в Entity-Body, помещать параметры с другими именами в Request-URI, например:

POST http://www.site.ru/news.html?type=user HTTP/1.0\r\n
.....
\r\n
login=Petya%20Vasechkin&password=qq

Модификация URL в htaccess

Наиболее часто htaccess используется для модификации URL во время выполнения или редиректов. За эту функциональность отвечает модуль mod_rewrite и обычно он активирован в большинстве конфигураций Apache.

Модификация URL в htacces выполняется с помощью трех директив, это RewriteBase, которая указывает префикс адреса, RewriteCond проверяет соответствие, и RewriteRule — изменяет URL в соответствии с регулярным выражением если все правила соответствия подходят.

Сначала нужно включить Mod_Rewrite, на случай если модуль еще не активен:

Укажем, что в качестве префикса для URL нужно использовать корень:

И будем автоматически заменять URL адреса с index.html на index.php, обратите внимание, что исходный URL — это путь к запрашиваемому файлу относительно расположения файла htaccess:

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

^ — начало строки;
$ — конец строки;
. — любой символ;
* — любое количество любых символов;
? — один определенный символ;
— последовательность символов, например, от 0 до 9;
| — символ или, выбирается или одна группа, или другая;
() — иcпользуется для выбора групп символов.

В регулярных выражениях htaccess также можно использовать переменные с данными, полученными из заголовков запроса, например:

%{HTTP_USER_AGENT} — поле User-Agent, которое передает браузер пользователя;
%{REMOTE_ADDR} — IP адрес пользователя;
%{REQUEST_URI} — запрашиваемый URI;
%{QUERY_STRING} — параметры запроса после знака ?.

Директива RewriteCond дает еще больше гибкости, вы можете выбрать к каким адресам стоит применять модификацию, например, будем переопределять данные только для версии с www:

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

Структура 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 действие.

Установка и настройка WordPress на сервер Linux

1. Размещение файлов дистрибутива WP

Загружаем архив на сервер в каталог “/var/www/sites/” и распаковываем, файлы будут извлечены в папку “wordpress”.

Копируем содержимое папки “/var/www/sites/wordpress/” в корневую директорию сайта “/var/www/sites/site1/”

Так как копирование файлов выполнялось из консоли с root-правами еще раз изменяем владельца каталога “/var/www/sites/”, включая содержимое на virtual. Это нужно для восстановления полного доступа при подключении через ftp-клиент.

2. Создание базы данных для WordPress

Входим в PHPMyAdmin и нажимаем “Создать БД”. Указываем произвольное имя базы данных, в нашем случае “wordpress_db” и нажимаем кнопку “Создать”.

Выделяем в левой части окна созданную БД и нажимаем кнопку “Привилегии”

Далее нажимаем “Добавить учетную запись пользователя”.

В открывшемся окне вводим логин и пароль (wpservice / Qwe123), помечаем опцию “Предоставить все привилегии в базе данных wordpress_db” и нажимаем кнопку “Вперед”

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

3. Конфигурация WP на сервере под Linux

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

Открываем файл “wp-config.php” и вводим параметры подключения к базе данных, созданной на предыдущем шаге и сохраняем изменения.

4. Установка CMS WordPress

Заполняем предложенные поля и нажимаем “Установить WordPress” Имя пользователя и пароль указываем произвольные, в нашем случае логин — wpadmin, пароль — Qwe123

Эти учетные данные будут использоваться для входа в WordPress.

На главной странице сайта будет отображаться один из шаблонов WordPress

Настройка завершена.

Данные для входа в WordPress:

http:///wp-login.php
Логин: wpadmin
Пароль: Qwe123

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

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

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

Избегайте нескольких последовательных перенаправлений — они увеличивают нагрузку на сервер и снижают скорость работы сайта.
Располагайте редиректы от частных к глобальным. Например, сначала переадресация с одной страницы на другую, затем общий редирект на страницы со слешем. Это правило работает не в 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» на старый и новый домен соответственно.

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

Проксирование, в отличие от редиректа, не передает инструкции браузеру перейти на другой 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/.

Общие правила работы с .htaccess

Всегда делайте резервную копию файла перед внесением изменений, чтобы оперативно «откатить» их.
Вносите изменения пошагово, добавляйте по одному правилу и оценивайте, как оно сработало.
Если размещаете несколько файлов .htaccess в разных каталогах, прописывайте в дочерних только новые директивы, которые актуальны для конкретного каталога, остальные унаследуются от родительского каталога или файла в корневой папке.
Очищайте кэш браузера: Ctrl + F5, в Safari: Ctrl + R, в Mac OS: Cmd + R.
Если возникает ошибка 500, проверьте синтаксис правила (нет ли опечатки). Можно воспользоваться сервисами проверки файла .htaccess онлайн, например таким. Если ошибок не найдено, значит в главном конфигурационном файле такой тип директивы запрещен, придется обратиться за консультацией к программисту и хостинг-провайдеру.
В директивах .htaccess кириллические символы не допускаются. Если необходимо указать адрес кириллического домена (мойсайт.рф), воспользуйтесь любым whois-сервисом, чтобы узнать его написание по методу punycode. Например, адрес «сайт.рф» будет выглядеть как «xn--80aswg.xn--p1ai/$1».
Слишком большое количество директив в .htaccess может снизить работоспособность сайта. Старайтесь использовать файл только в том случае, если другим путем задачу решить нельзя.
Если нет времени подробно изучать особенности директив, воспользуйтесь генератором .htaccess.

Настройка HTTP-сервера Apache

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

2. Создание тестовой страницы

По умолчанию корневым каталогом для размещения сайта является директория “/var/www/html”, именно там находится страница приветствия. Создадим отдельную директорию “/var/www/sites” для размещения виртуальных хостов и вложенную папку “/var/www/sites/site1” с индексной страницей тестового сайта.

В результате файл “/var/www/sites/site1/index.html” будет содержать одну html-строку:

3. Конфигурация Apache-сервера

Конфигурационные файлы сайтов находятся в каталоге “/etc/apache2/sites-available/”. Создадим конфигурационный файл для нового виртуального хоста взяв за основу конфигурацию по умолчанию из файла “000-default.conf”

Откроем файл “site1.conf” и изменим параметр “DocumentRoot”. В качестве значения нужно указать путь к новому сайту, в нашем случае это “/var/www/sites/site1”

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

Настройка HTTP-сервера завершена, переходим к следующему этапу.

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.

Установка IIS

Для установки веб-сервера, открываем Диспетчер серверов — переходим в Управление — Добавить роли и компоненты:

Если откроется окно с приветствием, нажимаем Далее:

При выборе типа установки выбираем Установка ролей или компонентов:

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

Среди ролей выбираем Веб-сервер (IIS) — во всплывающем окне кликаем по Добавить компоненты:

Также среди ролей в подразделе «Разработка приложений» ставим галочку для установки CGI — этот компонент нам нужен для работы PHP:

При выборе компонентов ничего не меняем — нажимаем Далее:

Откроется окно настройки роли веб-сервера — просто нажимаем Далее:

Выбор служб ролей — нажимаем далее или, при необходимости, выбираем FTP-сервер:

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

Дожидаемся окончания процесса установки.

Сразу после установки IIS запускается автоматически. Но, если что, его можно запустить с помощью команды iisreset:

iisreset /start

* если выполнить данную команду без опций, то она перезапустить веб-сервер.

Также мы можем открыть диспетчер служб (команда services.msc) и перезапустить Службу веб-публикаций:

Открываем браузер и вводим адрес http://localhost — должен открыться стартовый портал: