Local server: Open Server Panel / Локальный веб-сервер для Windows / Скачать WAMP сервер

Новости / Open Server Panel

Простое и понятное управление
Уникальные возможности по настройке
Дистрибутив скачали уже 3 321 001 раз!

21 августа 2022

Open Server Panel 5.4.3

Что нового

• Добавлены NoSQL модули: MongoDB 6.0, Redis 7 (спасибо alex2018)
• Добавлены DBMS модули: MariaDB 10.7, MariaDB 10.8
• Добавлены расширения для PHP 8.1: ioncube, rar

Изменения

• Улучшения в конфиге MySQL и MariaDB для уменьшения потребления памяти
• Nginx пересобран с библиотекой OpenSSL 3.x
• По умолчанию при установке включена галочка оптимизации сетевых настроек
• По умолчанию при установке теперь активируется PHP 7.2
• Все компоненты обновлены до актуальных версий

Исправления

• На некоторых системах первый запуск MySQL 8 происходил очень медленно

Внимание! Особенности настройки Windows 10

Это финальное обновление 5-й ветки Open Server Panel. Если вы не планируете в ближайшее время переезжать на новую 6-ю ветку OSPanel рекомендуется обновиться до этой версии, поскольку обновлений для старой ветки больше не будет! В сентябре ожидается начало публичного тестирования beta версии 6-й ветки OSPanel.

1 мая 2022

Open Server Panel 5.4.2

Что нового

• Добавлен DBMS модуль: MariaDB 10.6
• Добавлены расширения для PHP 8.1: amqp, apcu, igbinary, imagick, mailparse, memcached, mongodb, redis, ssh3, timezonedb, uploadprogress, xdebug, xhprof, yaml

Изменения

• Мелкие улучшения в конфигурации некоторых модулей
• По просьбам пользователей доступ к MySQL/MariaDB/PostgreSQL по умолчанию теперь неограничен (Осторожно! Требуется обязательная настройка ограничений прав пользователей БД если ваш сервер будет доступен из сети Интернет)
• PostgreSQL теперь поставляется с инициированым хранилищем
• Все компоненты обновлены до актуальных версий

Исправления

• Исправлены недочёты в конфигах MySQL, PostgreSQL и MongoDB
• Расширение Hrtime не работало в PHP 5. 5 и PHP 5.6
• Расширение IMagick не работало c pdf файлами в PHP 7.2/7.3/7.4/8.0

Внимание! Особенности настройки Windows 10

23 декабря 2021

Open Server Panel 5.4.1

Что нового

• Добавлен PHP модуль: PHP 8.1
• Добавлены DBMS/NoSQL модули: PostgreSQL 14.1, MongoDB 5.0
• Добавлены расширения для Apache: mod_log_rotate, mod_limitipconn, mod_authn_ntlm, mod_antiloris

• Мелкие улучшения в конфигурации некоторых модулей
• Сокращён размер установщика за счёт оптимизаций сборки
• Мелкие изменения в темах оформления индексной страницы и Adminer
• Добавлены закладки на документацию и System Preparation Tool
• Все компоненты обновлены до актуальных версий (кроме MySQL/MariaDB)

Исправления

• Установщик некорректно работал с реестром (изменения не применялись)
• Исправлены другие мелкие ошибки в работе установщика

Внимание! Особенности настройки Windows 10

4 июля 2021

Open Server Panel 5.

Что нового

• Установщик теперь позволяет выборочно устанавливать модули Apache и PHP
• Добавлен мини-установщик системных библиотек и настроек (для подготовки Windows к работе с Open Server Panel без наличия оригинального инсталлятора)

Изменения

• Протокол HTTP/2 теперь выключен по умолчанию
• Установлены более либеральные настройки TLS по умолчанию для поддержки старых браузеров
• Уточнены названия модулей Mysql, MariaDB и PostgreSQL согласно системных требований (добавлен префикс Win10)
• Доп. программы в меню теперь имеют оригинальные названия (можно изменить самостоятельно в osinit.txt)
• Обновлены модули MariaDB, PHP и Composer
• Обновлён набор библиотек Microsoft Visual C++ Redistributable Package

Исправления

• Исправлена всплывающая ошибка об отсутствии темы оформления
• Исправлена невозможность установки root привилегий в MySQL 8
• BrightMaster теперь работает только с правами администратора
• Исправлена опечатка в конфиге Nginx (спасибо SagePointer)
• Установщик создавал иконку на рабочем столе независимо от выбора пользователя (спасибо Артём Рыженький)
• Установщик не устанавливал корректные права доступа к файлам и папкам после установки

Внимание! Особенности настройки Windows 10

20 июня 2021

Open Server Panel 5.

Что нового

• Добавлены новые модули: MariaDB 10.5 и PostgreSQL 13.3
• Добавлены новые расширения Nginx: stream_realip_module, stream_ssl_preread_module, http_image_filter_module, http_brotli_filter_module, http_brotli_static_module, http_geoip_module, http_geoip2_module, stream_geoip_module, stream_geoip2_module
• Добавлено новое расширение для Apache_2.4-PHP_7.2 и выше: mod_maxminddb (GeoIP2)
• В сборку добавлен файл базы стран GeoLite2-Country (MaxMind, Inc.)
• Максимальное число подключений для Nginx увеличено с 1024 до 32768
• Реализован новый способ разблокировки HOSTS файла (старый мог не работать)
• Добавлена поддержка Imagick для PHP 8 (спасибо SagePointer)
• Добавлен текстовый редактор Sublime 4 (вместо Sublime 3) + русификация + дополнения

Изменения

• Изменено расположение некоторых системных каталогов PHP (перенесены в . /temp)
• Доступные по умолчанию пользователи баз данных (root и mysql) теперь не имеют пароля (пустой)
• Сетевой доступ для пользователей доступных по умолчанию в модулях Mysql, MariaDB и PostgreSQL разрешен только с локального компьютера (IP 127.0.0.1)
• Немного доработана конфигурация модулей для улучшения быстродействия на HDD дисках
• Оптимизирована и унифицирована конфигурация некоторых модулей
• Перед началом деинсталляции добавлено предупреждение о необходимости сохранить важные данные (спасибо zxhgd22)
• Обновлены все модули и программы в комплекте
• Обновлены все сторонние расширения для всех версий PHP
• Обновлён набор библиотек Microsoft Visual C++ Redistributable Package
• Дополнены некоторые разделы «Руководства пользователя»

Исправления

• Исправлены некоторые ошибки конфигурации PHP модулей
• Исправлено поведение установщика для определённых системных конфигураций
• Убран лишний запрос подтверждения установки набора библиотек Microsoft (спасибо Артём Рыженький)
• Удалены все скины ввиду частой невозможности работы с программой при их использовании

Внимание! Особенности настройки Windows 10

Локальный веб-сервер Symfony — Symfony Framework Documentation documentation

Вы можете запускать приложения Symfony с любым веб-сервером (Apache, nginx, внутренний веб-сервер PHP, и др.

Хотя этот сервер не предназначен для использования в производстве, он поддерживает HTTP/2, TLS/SSL, автоматическое генерирование сертификатов безопасности, локальные домены, и многие другие функции, которые рано или поздно понадобятся вам во время разработки веб-проектов. Более того, сервер не привязан к Symfony, и вы также можете использовать его с любым PHP-приложением, и даже с HTML или приложениями одной страницы.

Установка

Сервер Symfony является частью бинарности symfony, созданной, когда вы устанавливаете Symfony, и имеет поддержку для Linux, macOS и Windows.

Note

Бинарность Symfony разрабатывается внутренне в Symfony. Если вы хотите сообщить об ошибке, или предложить новую функцию, пожалуйста, создайте тему в symfony/cli.

Начало работы

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

1
2
3
4
5
6
7
8

$ cd my-project/
$ symfony server:start
  [OK] Web server listening on http://127.0.0.1:....
  ...
# Теперь, перейдите по заданному URL, или выполните эту команду:
$ symfony open:local

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

1
2
3
4
5
6
7
8
9

$ cd my-project/
# запустите сервер фоново
$ symfony server:start -d
# продолжайте работать и выполнять другие команды...
# покажите последние сообщения лога
$ symfony server:log

Подключение PHP-FPM

Note

PHP-FPM должен быть установлен локально для использования сервера Symfony.

Когда сервер запускается, он проверяет web/index_dev.php, web/index.php, public/app_dev. php, public/app.php в таком порядке. Если найден один из них, сервер автоматически запустится с подключенным PHP-FPM. В других случаях, сервер запустится без PHP-FPM, и отобразит страницу Страница не найдена, при попытке получить доступ к файлу .php в браузере.

Tip

Когда присутствует и index.html, и фронт-контроллер, вроде index.php, сервер запустится с подключенным PHP-FPM, но index.html будет главенствовать над фронт-контроллером. Это означает, что когда в public или web есть файл index.html, он будет отображен вместо index.php, что покажет, к примеру, приложение Symfony.

Подключение TLS

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

$ symfony server:ca:install

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

До просмотра вашего локального приложения с HTTPS вместо HTTP, перезапустите его сервер, остановив и запустив его снова.

Разные PHP-настройки для каждого проекта

Выбор другой PHP-версии

Если у вас на компьюетере установлено несколько версий PHP, вы можете сообщить Symfony, какую использовать, создав файл под названием .php-version в корневом каталоге приложения:

1
2
3
4
5
6
7

$ cd my-project/
# использовать конкретную версию PHP
$ echo 7.4 > .php-version
# использовать любую доступную версию PHP 8.x
$ echo 8 > . php-version

Tip

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

Запустите команду ниже, если вы не помните все установленные на вашем компьютере PHP-версии:

1
2
3
4
5

$ symfony local:php:list
  # Вы увидите все поддерживаемые SAPI (CGI, FastCGI, и др.) для каждой версии.
  # FastCGI (php-fpm) используется там, где это возможно; затем CGI (который также действует,
  # как сервер FastCGIserver), и, наконец, сервер откатывается до обычного CGI.

Переопределение опций конфигурации PHP для каждого проекта

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

1
2
3
4
5
6

$ cd my-project/
# этот проект переопределяет только часовой пояс PHP по умолчанию
$ cat php. ini
[Date]
date.timezone = Asia/Tokyo

Запуск команд с разными версиями PHP

При запуске разных PHP-версий, полезно использовать основную команду symfony в качестве обертки команды php. Это позволяет вам всегда выбирать наиболее подходящую версию PHP в соответствии с проектом, который выполняет команды. Это также автоматически загружает переменные окружения, что важно при выполненни не-Symfony команд:

1
2
3
4
5
6

# выполняе команду с версией PHP по умолчанию
$ php -r "..."
# выполняет команду с версией PHP, выбранной проектом
# (или версией PHP по умолчанию, если проект не выбрал версию)
$ symfony php -r "..."

Имена локальных доменов

По умолчанию, проекты доступны с произвольного порта локального IP 127.0.0.1. Однако, иногда лучше ассоциировать с ними имя домена:

• Это более удобно, когда вы беспрерывно работаете над одним проектом, так как номера портов могут изменяться, а домены — нет;
• Поведение некоторых приложений зависит от их доменов/субдоменов;
• Наличие стабильных конечных точек, вроде локального перенаправления URL для OAuth3.

Настройка локального прокси

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

1. Откройте настройки прокси вашей ОС:
   • Настройки Proxy в Windows;
   • Настройки Proxy в macOS;
   • Настройки Proxy в Ubuntu.
2. Установите следующий URL как значение Автоматической конфигурации прокси: http://127.0.0.1:7080/proxy.pac

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

$ symfony proxy:start

Note

Некоторые браузеры (например, Chrome) требуют повторного применения настроек прокси (нажатия на кнопку Применить настройки повторно на странице chrome://net-internals/#proxy) или полной перезагрузки после запуска прокси. Иначе, вы увидите ошибку “Эта веб-страница недоступна” (ERR_NAME_NOT_RESOLVED).

Определение локального домена

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

$ cd my-project/
$ symfony proxy:domain:attach my-domain

Если вы установили локальный прокси, как объясняется в предыдущем разделе, вы теперь можете перейти на https://my-domain.wip, чтобы получить доступ к вашему локальному проекту с новым пользовательским доменом.

Tip

Перейдите по URL http://127.0.0.1:7080, чтобы получить полный список локальных каталогов проекта, их пользовательские домены и номера портов.

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

$ https_proxy=http://127.0.0.1:7080 curl https://my-domain.wip

Note

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

Tip

Если вы предпочитаете использовать другой TLD, отредактируйте файл ~/.symfony/proxy.json (где ~ означает путь к вашему каталогу пользователя) и измените значение опции tld с wip на любой другой TLD.

Долгосрочные команды

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

# скомпилируйте ресурсы Webpack, используя Symfony Encore ... но сделайте это
# фоново, чтобы не блокировать терминал
$ symfony run -d yarn encore dev --watch
# продолжайте работать и выполнять другие команды...
# время от времени, проверяйте логи команд, если хотите
$ symfony server:log
# и вы также можете проверить, выполняется ли еще команда
$ symfony server:status
Web server listening on . ..
Command "yarn ..." running with PID ...
# остановите веб-сервер (и все ассоциированные команды), когда вы закончите
$ symfony server:stop

Интеграция Docker

Локальный сервер Symfony предоставляет полную интеграцию Docker для проектов, которые ее используют. Чтобы узнать больше о Docker и Symfony, см. Using Docker with Symfony.

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

Через API docker-compose, он ищет раскрытые порты, используемые для распространенных сервисов. Когда он обнаруживает тот, о котором знает, он использует имя сервиса, чтобы продемонстрировать переменные окружения.

Рассмотрите следующую конфигурацию:

1
2
3
4

# docker-compose.yaml
services:
    database:
        ports: [3306]

Веб-сервер определяет, что сервис, раскрывающий порт 3306 работает для проекта. Он понимает, что это — сервис MySQL, и создает переменные окружения в соответствии с именем сервиса (database) в качестве префикса: DATABASE_URL, DATABASE_HOST, …

Если сервис не находится в списке поддерживаемых ниже, устанавливаются общие переменные окружения: PORT, IP, и HOST.

Если имена docker-compose.yaml не совпадают с соглашениями Symfony, добавьте ярлык, чтобы переопределить префикс переменных окружения:

1
2
3
4
5
6

# docker-compose.yaml
services:
    db:
        ports: [3306]
        labels:
            com.symfony.server.service-prefix: 'DATABASE'

В этом примере, сервис называется db, поэтому переменные окружения будут иметь префикс DB_, но так как com.symfony.server.service-prefix установлен, как DATABASE, веб-сервер создает переменные окружения, начинающиеся с DATABASE_ вместо того, что ожидается конфигурацией Symfony по умолчанию.

Вам не нужно создавать два контейнера для основной базы данных и для тестовой БД. Использование APP_ENV=test symfony автоматически приспособит переменные окружения DATABASE_* к окружению test:

1
2
3
4
5
6
7
8
9

$ symfony var:export --multiline
export DATABASE_DATABASE=app
export DATABASE_NAME=app
export DATABASE_URL=postgres://app:[email protected]:49160/app?sslmode=disable&charset=utf8
$ APP_ENV=test symfony var:export --multiline
export DATABASE_DATABASE=app_test
export DATABASE_NAME=app_test
export DATABASE_URL=postgres://app:[email protected]:49160/app_test?sslmode=disable&charset=utf8

Вот список всех поддерживаемых сервисов с их портами, и префиксов Symfony по умолчанию:

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

$ symfony open:local:webmail
$ symfony open:local:rabbitmq

Или нажать на ссылки в разделе “Server” в панели инструментов веб-отладки.

Tip

Чтобы отладить и перечислить все экспортированные переменные окружения, выполните symfony var:export --debug.

Tip

Для некоторых сервисов, веб-сервер также демонстрирует переменные окружения, понимаемые инструментами CLI, связанными с сервисом. Например, запуск symfony run psql автоматически подсоединит вас к серверу PostgreSQL, работающему в контейнере, без необходимости указывать имя пользователя, пароль или имя БД.

Когда запущены сервисы Docker, перейдите на страницу вашего приложения Symfony, и проверьте раздел “Symfony Server” в панели инструментов веб-отладки; вы увидите, что “Docker Compose” — “Up”.

Note

Если вы не хотите, чтобы для сервиса демонстрировались переменные окружения, установите ярлык com.symfony.server.service-ignore как true:

1
2
3
4
5
6

# docker-compose.yaml
services:
    db:
        ports: [3306]
        labels:
            com. symfony.server.service-ignore: true

Если ваш файл Docker Compose не находится в корне проекта, используйте переменные окружения COMPOSE_FILE и COMPOSE_PROJECT_NAME, чтобы определить его местоположение, так же, как для docker-compose:

1
2
3
4
5

# запустите ваши контейнеры:
COMPOSE_FILE=docker/docker-compose.yaml COMPOSE_PROJECT_NAME=project_name docker-compose up -d
# запустите любую команду Symfony CLI:
COMPOSE_FILE=docker/docker-compose.yaml COMPOSE_PROJECT_NAME=project_name symfony var:export

Note

Если у вас более одного файла Docker Compose, вы можете предоставить их все, разделяя их :, как объясняется в справочнике переменных окружения Docker compose CLI.

Caution

При использовании бинарности Symfony с php bin/console (консоль symfony ...), бинарность будет всегда использовать переменные окружения, определенные через Docker, и будет игнорировать локальные переменные окружения. Например, если вы установите другое имя БД в вашем файле .env.test (DATABASE_URL=mysql://db_user:[email protected]:3306/test), и если вы выполните symfony console doctrine:database:drop --force --env=test, команда сбросит БД, определенную в вашей конфигурации Docker, а не “тестовую”.

Интеграция SymfonyCloud

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

Прочтите технические документы SymfonyCloud.

local server — русский перевод

NetSuite Applications Suite — Безопасный HTTP (HTTPS) с локальным сервером

Команда gulp local запускает два экземпляра локального сервера со следующими URL-адресами:

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

Создание SSL-сертификатов и закрытых ключей

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

Для создания SSL-сертификата и закрытого ключа

1. Загрузите и установите OpenSSL.

2. Создайте закрытый ключ RSA.

   1. Выполните следующую команду:

      openssl genrsa -des3 -out ca.key 1024

   2. Введите и подтвердите пароль для сертификата.

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

   Эта команда выводит закрытый ключ RSA в файл с именем ca. key .

3. Создайте новый SSL-сертификат.

   1. Выполните следующую команду:

      openssl req -new -sha256 -key ca.key -out ca.csr

      Эта команда использует закрытый ключ RSA, созданный на предыдущем шаге.

   2. Примите значение по умолчанию для поле localhost . Другие поля не требуются для создания сертификата, используемого локальным сервером при работе по протоколу HTTPS.

   Эта команда выводит сертификат SSL в файл с именем ca.csr .

4. Создать самозаверяющий сертификат:

   openssl x509 -req -days 3600 -in ca. csr -out ca.crt -signkey ca.key

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

5. Создать ключ сервера:

   openssl genrsa -des3 -out server.key 1024

   Эта команда выводит закрытый ключ сервера в файл с именем сервер.ключ .

6. Создать запрос на подпись сертификата (CSR):

   openssl req -new -sha256 -key server.key -out server.csr

   Эта команда выводит CSR в файл с именем server.csr .

7. Удалить пароль из сертификата сервера.

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

   1. Скопируйте файл server.key на server.key.org .

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

      openssl rsa -in server.key.org -out server.key

      Эта команда создает новый закрытый ключ с именем server.key . Локальный сервер использует этот файл при создании защищенного домена. Поэтому следует переместить его на постоянное место.

8. Создать самозаверяющий сертификат сервера:

   openssl x509 -req -sha256 -days 3600 -in server. csr -signkey server.key -out server.crt

   Эта команда создает новый сертификат сервера с именем server.crt . Локальный сервер использует этот файл при создании защищенного домена. Поэтому следует переместить его на постоянное место.

Настройка переменных среды KEYPEM и CERTPEM

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

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

Например, в Windows вы можете установить эти переменные среды, как показано в следующем примере:

              установить KEYPEM=c:\OpenSSL-Win64\server.key
установить CERTPEM=c:\OpenSSL-Win64\server.crt
 
           

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

После создания сертификатов SSL и сервера необходимо разрешить их работу в веб-браузере. В Windows вы можете использовать мастер импорта сертификатов.

Для установки сгенерированных сертификатов:

1. Запустите файл server.crt , созданный с помощью OpenSSL.

2. Щелкните Установить сертификат .

3. Нажмите Далее .

4. Выберите Поместите все сертификаты в следующее хранилище , затем нажмите Обзор .

5. Выберите Доверенные корневые центры сертификации , затем нажмите OK .

6. Нажмите Далее .

7. Проверьте правильность настроек и нажмите Готово .

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

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

Изменить файл distro.json

Чтобы получить доступ к защищенному домену на локальном сервере, необходимо убедиться, что объект https существует в локальном объекте taskConfig . После добавления объекта https добавьте запись для порта HTTPS, сертификата и ключа.

Ваш файл distro.json должен выглядеть примерно так:

              "Конфигурация задач": {
    "местный": {
        "http": {
            "порт": 7777
        },
        "lessSourcemap": ложь,
        "jsRequire": правда,
        "https": {
            "порт": 7778,
            "ключ": "KEYPEM",
            "сертификат": "CERTPEM"
        }
    },
    ...
 
           

Изменение корневого URL-адреса приложения SSP

Чтобы использовать HTTPS с локальным сервером, необходимо изменить значение переменной ROOT в приложении SSP.

Чтобы изменить корневой URL-адрес приложения SSP:

1. Откройте файл приложения index-local.ssp .

   Этот файл расположен в . Например, файл index-local. ssp для приложения «Покупки» находится в этом каталоге: /Модули/suitecommerce/[email protected]/Внутренний

2. Изменить значение переменной ROOT :

                       вар КОРЕНЬ = 'https://localhost:7778/'
    
                    

3. Скомпилируйте и разверните приложение с помощью следующей команды:

   глоток развернуть

   Поскольку эта процедура изменяет внутренний файл, вы должны развернуть файлы в NetSuite. В процессе компиляции приложения эта команда создает файл local.ssp на основе файла index-local.ssp , который вы изменили на предыдущих шагах.

Доступ к локальному серверу с использованием защищенного URL-адреса

Чтобы получить доступ к локальному серверу с помощью локального сервера, вы должны использовать URL-адрес вашего защищенного домена.

Для доступа к локальному серверу через безопасный домен:

1. Выполните следующую команду:

   залпом местный

2. Получите доступ к защищенному домену локального сервера, используя URL-адрес следующего вида:

   https://mysite.com/c.//shopping-local.ssp

   Например, для доступа к приложению «Покупки» ваш URL-адрес должен выглядеть следующим образом:

   https://mysite.com/c.123456/sca-dev-montblanc/shopping-local.ssp

Похожие темы

Справочник по инструментам коммерческого разработчика

Аутентификация на основе токенов

Смешанные домены на локальном сервере

Устранение неполадок с инструментами разработчика

Общие уведомления

Как перенести сайт WordPress с локального сервера с помощью дубликатора

• Фейсбук
• Твиттер
• LinkedIn

Вам нужно перенести сайт WordPress с локального сервера на вашем компьютере на работающий веб-сервер? Этот учебник проведет вас через процесс шаг за шагом.

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

Надеюсь, это облегчит процесс.

Подождите, я могу запустить WordPress на своем компьютере?

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

Но WordPress нужен веб-сервер, база данных MySQL и PHP, так как же запустить его на своем компьютере?

Ответ: WAMP.

WAMP — это пакет, который устанавливает веб-сервер Apache, сервер MySQL и PHP на ваш компьютер. В зависимости от используемого вами пакета WAMP все это можно настроить несколькими щелчками мыши.

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

Подготовка к переносу локального сайта WordPress на работающий сервер

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

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

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

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

Вам также понадобится программа FTP для перемещения файлов. Вы всегда можете использовать популярную и бесплатную платформу FileZilla.

Использование плагина WordPress для упрощения переноса

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

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

Хорошо, давайте начнем перенос Дубликатора.

Установка плагина Duplicator для переноса сайта WordPress с локального сервера

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

Войдите в панель администратора WordPress для вашего локального сайта.

В левой колонке навигации наведите указатель мыши на ссылку «Плагины» и щелкните ссылку «Добавить новый».

В поле «Поиск плагинов…» введите «Дубликатор».

Найдя плагин, нажмите кнопку «Установить сейчас».

Когда плагин будет установлен, нажмите кнопку «Активировать».

Создание копии локального веб-сайта

В левой колонке навигации наведите указатель мыши на ссылку «Дубликатор» и щелкните ссылку «Пакеты».

Нажмите ссылку «Создать новый» в правом верхнем углу.

Назовите пакет.

Оставьте все значения в «Хранилище», «Архив» и «Установщик» как есть.

Нажмите кнопку «Далее» внизу страницы.

Сайт будет просканирован, и вы перейдете на страницу «Сканирование завершено». Если все проверки «Хорошо» (зеленые), нажмите кнопку «Построить».

На странице «Пакет завершен» нажмите ссылку «Загрузка в один клик».

Перенос файлов WordPress на действующий веб-сайт

Создайте пустой каталог на своем сайте. Вы можете использовать корневой каталог для сайта, но для этого урока я использую каталог с именем blog. Я загружу два файла пакета Duplicator в каталог /blog .

Перейдите по URL-адресу файла установщика из веб-браузера.

В этом примере я копирую локальный сайт на ggexample.com/blog/, поэтому URL-адрес файла установщика — https://ggexample.com/blog/installer.php.

Вы увидите страницу «Шаг 1 из 4: развертывание». В разделах «Архив» и «Проверка» должно быть написано «Пройдено» (зеленый). Установите флажок «Я прочитал и принимаю все условия и уведомления» и нажмите кнопку «Далее».

Архивные файлы будут извлечены, что займет некоторое время.

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

Нажмите кнопку «Проверить базу данных».

В разделе «Проверка» в «Требованиях» и «Уведомлениях» должно быть написано «Пройдено» и «Хорошо» (оба зеленого цвета).

Нажмите кнопку «Далее».

Появится окно «Подтверждение установки». Проверьте правильность информации и нажмите кнопку «ОК».

Это приведет вас к «Шаг 3 из 4: Обновление данных». Убедитесь, что информация «Новые настройки» верна.

Нажмите кнопку «Далее».

Откроется страница «Шаг 4 из 4: Тестовый сайт». Нажмите кнопку «Вход администратора», чтобы завершить установку.

Примечания по переносу локального веб-сайта WordPress на работающий сайт

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

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

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

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

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

Сделайте резервную копию

Я упоминал об этом ранее, но стоит повторить: сделайте резервную копию файлов сайта WordPress и базы данных, прежде чем что-либо делать с Duplicator. Это применимо при внесении любых изменений на сайт, не только Duplicator.

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

Знаете ли вы, что можете запустить WordPress на локальном компьютере? Вы переместили сайт WordPress с помощью другого метода или плагина? Дайте нам знать, как все прошло.

• Фейсбук
• Твиттер
• LinkedIn

локальный веб-сервер — npm

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

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

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

Используйте этот инструмент для:

• Создайте интерфейсное веб-приложение любого типа (статическое, динамическое, одностраничное приложение, прогрессивное веб-приложение, React и т. д.).
• Прототип внутренней службы (REST API, микрослужба, веб-сокет, служба событий, отправленных сервером, и т. д.).
• Мониторинг активности, анализ производительности, эксперименты со стратегией кэширования и т. д.

Local-web-server — это дистрибутив lws в комплекте со «стартовым пакетом» полезного промежуточного программного обеспечения.

Краткий обзор

Этот пакет устанавливает 9Инструмент командной строки 0003 ws (см. руководство по использованию).

Статический веб-сайт

При запуске ws без каких-либо аргументов текущий каталог будет размещен как статический веб-сайт. При переходе на сервер отобразится список каталогов или ваш index. html , если этот файл существует.

 $ вс
Прослушивание на http://mbp.local:8000, http://127.0.0.1:8000, http://192.168.0.100:8000 

Учебник по статическим файлам.

Этот ролик демонстрирует статический хостинг плюс пару форматов вывода лога — dev и статистика .

Одностраничное приложение

Обслуживать одностраничное приложение (приложение с маршрутизацией на стороне клиента, например, приложение React или Angular) так же просто, как указать имя вашей отдельной страницы:

 $ ws --spa index.html 

На статическом сайте запросы типичных путей SPA (например, /user/1 , /login ) будут возвращать 404 Not Found , поскольку файл в этом месте не существует. Однако, отметив index.html в качестве SPA вы создаете это правило:

Если запрашивается статический файл (например, /css/style.css ), то обслуживайте его, если нет (например, /login ), то обслуживайте указанный SPA и обрабатывать маршрут на стороне клиента.

Учебник SPA.

Перезапись URL-адресов и проксированные запросы

Другим распространенным вариантом использования является перенаправление определенных запросов на удаленный сервер.

Следующая команда проксирует запросы сообщений блога с любого пути, начинающегося с /posts/ от до https://jsonplaceholder.typicode.com/posts/ . Например, запрос /posts/1 будет проксирован на https://jsonplaceholder.typicode.com/posts/1 .

 $ ws --rewrite '/posts/(.*) -> https://jsonplaceholder.typicode.com/posts/$1' 

Учебник по переписыванию.

Этот клип демонстрирует описанное выше, а также использование --static.extensions для указания расширения файла по умолчанию и --verbose для отслеживания активности.

HTTPS и HTTP2

Для HTTPS или HTTP2 передайте флаги --https или --http2 соответственно. Дополнительные параметры конфигурации и руководство о том, как получить «зеленый замок» в браузере, см. на вики.

 $ ws --http2
Прослушивание на https://mba4.local:8000, https://127.0.0.1:8000, https://192.168.0.200:8000
 

Встроенный стек промежуточного ПО

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

Имя	Описание
↓ Базовая аутентификация	Защитите сервер паролем, используя обычную аутентификацию
↓ Анализатор тела	Анализирует тело запроса, делая ctx.request.body доступным для нижестоящего ПО промежуточного слоя.
↓ Монитор запросов	Передает информацию о трафике на вывод --verbose . Добавить комментарий Отменить ответ Ваш адрес email не будет опубликован. Обязательные поля помечены * Комментарий * Имя * Email * Сайт Поиск: Рубрики Seo Wordpress Дизайн Заработок Плагин Разное Рекомендац Сайт Совет Советы Тем Темы Урок Уроки