maks.4k

Nginx — скорость и гибкость

Главная фишка :Скорость и производтельность.

Из плюсов, скорость , можно использовать как прокси с apache , в open server v 6.

Из минусов выше порог вхождения для новичков , что касается настроек . Отсутвует файл .htaccess.Все настройки пишутся в основном файле настроек , в open server v6 ,этот файл называется nginx.conf в папке с модулем. Необходимость разбираться в синтаксисе Nginx , если необходимо будем настроить к примеру , сложные проекты с «красивым» URL.

Если ты разрабатываешь высоконагруженные проекты, API, используешь современные фреймворки (Laravel, Symfony) и готов разбираться с конфигами-выбирай nginx.

Короткая таблица сравнения:

Характеристика apache nginx

.htaccess Есть Нет

Простота нас-ки Высокая Требует знаний

Производ-ть Средняя Высокая

Потр-е памяти Выше Ниже

Wordpress Подходит Да(но с руч. нас-кой)

Для Open Server 6 и локальной разработки:

Начинай с Apache — проще, привычнее, меньше головной боли.

Переходи на Nginx, если:

-нужна максимальная скорость

-хочешь разобраться, как работают веб-серверы

-проект уже требует сложных настроек, где Nginx даёт больше гибкости

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

Если вам интересна тема веб-разработки, я также публикую разборы других кейсов в своем Telegram-канале и на Максе. Буду рад единомышленникам

[myproject.local]

web_engine = Nginx # или Apache

php_engine = PHP-8.2

public_dir = {base_dir}\public

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

3)Далее включаем модули , глобальный и для проекта отдельно.

Глобально через меню open server модули =>http=> выбираем нужный веб движок apache или nginx

После настройки глобальных модулей , мы можем настроить , веб сервер и версию php , локально для проекта

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

4) Что касается файла project.ini , и настройки корневой папка .Если файл лежит именно в корне проекта , оставляем настройку

[myproject.local]

public_dir = {base_dir}

если же присутствуют подпапки,как в laravel к примеру :

home/

└── myproject.local/

├── app/

├── config/

├── public/ ← вот она, папка с точкой входа

│ ├── index.php

│ └── style.css

├── storage/

└── vendor/

То добавляем через / название папки где находится наша точка входа в приложение

[myproject.local]

public_dir = {base_dir}/public

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

Что будет, если не указать public_dir?

Без public_dir в project.ini домен появится, но сервер не будет знать, откуда отдавать файлы, и вы увидите ошибку 404 или пустую страницу.

5)Как теперь работают домены (Прощай, файл hosts!)

В 5-й версии мы были обязаны вручную править системный файл C:\Windows\System32\drivers\etc\hosts, прописывая туда строки вида 127.0.0.1 myproject.local.

В Open Server 6 всё работает иначе:

В программу встроен собственный DNS-сервер.

При запуске OSP 6 автоматически перехватывает DNS-запросы на вашем компьютере.

Как только вы прописали имя проекта в скобках [myproject.local] внутри project.ini, программа сама связывает этот домен с нужным внутренним IP-адресом.

Вам больше не нужно трогать файл hosts — Windows мгновенно увидит ваш сайт по его DNS-имени. Если вам всё же нужен доступ по IP, проект по умолчанию доступен на локальном адресе http://127.0.0.1 (или с указанием конкретного порта, если вы изменили его в глобальных конфигах)

6)Важное изменение при подключении к БД (MySQL)

Раньше в конфигурационных файлах ваших сайтов (например, в .env файле Laravel или wp-config.phpв WordPress) в строке подключения к базе данных (DB_HOST) мы всегда писали localhost или 127.0.0.1.

В OSP 6 из-за изолированной архитектуры модулей localhost больше не работает!

Теперь для подключения к MySQL нужно использовать:

DNS-имя модуля: Например, MySQL-8.2 (указывайте ровно то имя, которое запущено у вас в системе).

Или конкретный IP-адрес: По умолчанию OSP 6 выделяет модулям баз данных адреса в локальной подсети. Чаще всего это 127.0.0.1, но с уникальным портом, либо выделенный IP из диапазона 127.x.x.x (смотрите точный IP/порт в консоли OSP при старте модуля).

Пример настройки файла .env ,в проекте

DB_CONNECTION=mysql

DB_HOST=MySQL-8.2 # Вместо localhost пишем имя модуля DNS

DB_PORT=3306

DB_DATABASE=my_db

DB_USERNAME=root

DB_PASSWORD=

Вот и все основные нюансы для запуска проекта в open server v6.

А если вы не знаете какой веб-сервер выбрать apache или nginx .Об этом я тоже расскажу в след. посте.

Если вам интересна тема веб-разработки, я также публикую разборы других кейсов в своем Telegram-канале и на Максе. Буду рад единомышленникам.

SSH-ключи. настройка HTTPS.создание репозиториев.GitVerse Pages (для хостинга статических сайтов) и интеграцию с инфраструктурой Cloud.ru.CI/CD пайплайны ,рекламировать их не буду скажу только что есть платные и бесплатные вариант.
и самое главное — импорт репозиториев из других Git-систем

Кстати: если тащите приватный проект, сначала создайте персональный токен (Personal Access Token) там, откуда экспортируете.

Ок поговорим про импорт по пунктам:

Импорт одного репозитория

Выбираете сервис (ну, например, GitHub).

Через пару минут проект уже в GitVerse.

1. Импорт нескольких репозиториев (массовый)

Если хотите перенести всё подряд:

На GitHub генерируете токен (classic).Ниже покажу как это сделать.

Нажимаем на свой профиль GitHub=>Settings=>Developer settings=>Personal access tokens=>Generate new token

В GitVerse выбираете импорт через токен.

Вставляете токен — сервис сам покажет, какие проекты можно импортировать.

3.Как работать с новыми проектами (зеркалирование).
Самый практичный метод пушить в 2 репозитория одновременно.
Как это сделать:
Создаём два репозитория Один на GitHub (как обычно),второй на GitVerse
.Далее несколько команд настроит нам push в 2 репозитория одновременно.
Настраиваем несколько адресов для push.
Сначала привязываем тот сервис откуда будет скачиваться код ,для избежание конфликтов -код скачивается из одного места а пушится в два,мы выберем сервис для скачивание GitHub в качестве примере.

Если нужна автоматическая синхронизация, в GitVerse можно настроить официальное зеркало (синхронизация каждые 8 часов). А если хотите пушить вручную в два сервиса — можно добавить несколько push-адресов через git remote.

git remote add origin https://github.com/maks4k/testHelloWorld

git remote set-url --add --push origin https://gitverse.ru/maks4k/HelloWorldTest.git

set-url --add просто добавляет новый адрес

В итоге у origin будет два push-адреса.

Проверяем, что получилось:

git remote -v

Должно быть примерно так:

origin https://github.com/maks4k/testHelloWorld.git (fetch)
https://gitverse.ru/maks4k/HelloWorldTest.git (push)
https://github.com/maks4k/testHelloWorld.git (push)

Ссылки, естественно, будут ваши.

Почему у GitHub и fetch и push ,связанно как раз ,с тем какой сервис мы привязали первым.

4.Как все это работает:

После настройки команда git push шлёт код и на GitHub, и на GitVerse.Если какой-то сервер недоступен, push упадёт с ошибкой.
Так скорее всего будет при первом push на GitVerse,вас попросит авторизоваться Git Manager,авторизация будет зависеть от того каким образом вырегистрировались, скорее всего потребуется получить токен что-бы ввести его вместо пароля ,а логин надо использовать имя вашего профиля на GitVerse(не логин при авторизации на GitVerse,а именно имя профиля).

Как получить токен для пароля:Аватар=>Настройки=>Управление токенами=>Отметить галочками необходимую функциональность и сгенерировать токен.

Для автоматического зеркалирование лучше использовать CI/CD, но для ручного резервного копирования этот способ нормально заходит.

5.Что ещё умеет GitVerse

Что ещё умеет GitVerse

Автоматическая синхронизация

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

Но работает это только если вы импортировали репозиторий с GitHub.

2.Так же существуют приватные репозитории ,если необходимо спрятать код под NDA

3.Разнообразные ачивки ,ну так на любителя естественно

Настройка зеркалирования занимает пару минут и не требует танцев с бубном.

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

Настройка зеркалирования занимает пару минут и не требует танцев с бубном.

Если вам интересна тема веб-разработки, я также публикую разборы других кейсов в своем Telegram-канале и на Максе. Буду рад единомышленникам

Новые корневые единицы rcap, rch, rex и ric как раз решают эту задачу: они позволяют строить размеры не от абстрактного font-size, а от реальных характеристик шрифта корневого элемента <html>.

Перейдем к самим единицам с минимальными примерами:

rcap равен cap height корневого шрифта - номинальной высоте заглавных букв шрифта корневого элемента.

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

```
.nav-icon {

width: 1.2rcap;

height: 1.2rcap;

}
```
rch- (root character unit) измеряет ширину символа 0 (ноль),заданную для шрифта корневого элемента <html>.

Как это работает: браузер берет advance measure глифа 0, в шрифте корневого элемента, и это значение становится равным 1rch.

Стоит уточнить что речь идет именно о advance measure-это расстояние, на которое курсор (или печатающая головка) продвигается после отображения символа, до того, как начнет рисоваться следующий символ.
Один из самых практичных сценариев для rch — поля ввода, где ширина должна быть привязана к количеству символов.
Например, если интерфейс предполагает ввод короткого кода, PIN или номера заказа фиксированной длины, можно задать ширину поля не в px и не в rem, а через rch. Тогда размер будет опираться на реальную ширину символов корневого шрифта.

```
.code-input {

width: 8rch;

padding: 0.5rem 1rch;

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

rex — корневая версия ex, это x-height шрифта корневого элемента.

rex больше не привязан к конкретному элементу. Это корневая версия ex,он считается не от текущего элемента ,а от корневого элемента html.
То есть чтобы точно было понятно rex игнорирует локальные шрифты и всегда смотрит только на глобальный шрифт заданный в html.

Если корневой шрифт, например, 'Georgia', rex всегда будет использовать его метрики, даже если внутри элемента задан другой шрифт

```
html {

font-family: 'Georgia', serif;

font-size: 16px;

}

.button {

font-family: 'Courier New', monospace;

padding: 1rex;

}

```

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

Корневая версия ic, единицы для идеографической метрики в CJK-письменностях. Обычно она соотносится с advance measure символа 水 и полезна прежде всего для китайского, японского и корейского текста.
Удобна, когда нужно создать сетку, рассчитанную на иероглифические тексты. Например, поле для ввода на 20 иероглифов.

Единицы rcap, rch, rex и ric описаны в CSS Values and Units Module Level 4. Несмотря на то что спецификация W3C по-прежнему имеет статус Working Draft, сами единицы уже поддерживаются современными браузерами

Chrome / Edge: 135+ ✅Firefox: 130+ ✅Safari: 18.3+ ✅(на июнь 2026)

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

Краткая сводка по css-еденицам :

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

На всякий случай для production-проектов: используйте с @Supports или fallback-значениями, так как спецификация ещё не финальная.

Подробнее - в спецификации по ссылке ниже:

https://www.w3.org/TR/css-values-4/

Если вам интересна тема веб-разработки, я также публикую разборы других кейсов в своем Telegram-канале и в Максе. Буду рад единомышленникам!