MoonShine 4: AI-инструменты, Tailwind 4 и новый UI — большой разбор релиза open source админ панели

Tailwind 4, дизайн-токены, AI-генерация через Claude Code, Telegram Mini App, модульная архитектура CRUD, 20+ палитр из коробки и генератор собственных. MoonShine 4 большое обновление админ панели для проектов на Laravel и других фреймворках. Вместо часов настройки полей — один промпт. Вместо танцев с CSS — система дизайн-токенов. Вместо мобильного приложения — интеграция с Telegram. За 11 месяцев разработки было переосмыслено то, как должна создаваться админ-панель в 2025 году. Внутри — полный технический разбор.

🔗 Хабр

Библиотека пхпшника

🧠 Продвинутый кеш для запросов и HTTP-ответов

⚡ 1) Кеширование данных/результатов запросов в Laravel
Laravel предоставляет единый API для работы с кешем — Redis, Memcached, DynamoDB, файл-драйвер и другие хранилища доступны «из коробки».
Это позволяет кешировать результаты тяжёлых запросов или вычислений, чтобы не выполнять их повторно при каждом HTTP-запросе.
Пример:

use Illuminate\Support\Facades\Cache;

$products = Cache::remember('products.active', 3600, function () {
 return Product::where('active', true)->get();
});

🔹 remember() проверяет наличие ключа в кеше → если нет — выполняет запрос, сохраняет результат → использует кеш до истечения TTL (в секундах).

⚡ 2) Полное кеширование HTTP-ответов (Response Cache)
Для страниц или API-эндпоинтов, результат которых редко меняется, можно кешировать весь HTTP-ответ. Это значит: тот же запрос не будет обрабатываться Laravel/Symfony — ответ будет браться из кеша.

🤝 Laravel
Существуют готовые пакеты (например, spatie/laravel-responsecache), которые автоматически кешируют весь ответ для GET-запросов:

composer require spatie/laravel-responsecache

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

⚡ 3) HTTP-кеширование через заголовки
Можно использовать HTTP-кеширование на уровне клиента и прокси: браузеры или CDN будут хранить ответы и не обращаться к серверу.
Пример установки заголовков в Laravel:

return response()->json($product)
 ->header('Cache-Control', 'public, max-age=3600')
 ->setEtag(md5($product->updated_at));

🔹 Cache-Control указывает, как долго браузер/CDN может хранить ответ.
🔹 ETag позволяет клиенту проверить, изменился ли ресурс, без загрузки полного тела ответа.

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

⚡ 4) HTTP-кеширование в Symfony
Symfony поддерживает стандартизированное HTTP-кеширование (RFC 7234): можно настраивать TTL, validation-кеш, работу через обратные прокси.
Пример для компонента Symfony:

$response = new Response($content);
$response->setSharedMaxAge(3600); // кеш прокси
return $response;

🔹 Symfony может работать с reverse proxy (gateway cache), например с Varnish или встроенным HttpCache, что позволяет обходить приложение полностью при совпадении кеша.

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

⚡ 5) Низкоуровневые кеш-стратегии
Помимо кеширования данных и ответов, можно:
🔹 кешировать вычисления, агрегации и подготовленные отчёты;
🔹 кешировать результаты внешних API-вызовов, чтобы не дергать их при каждом запросе;
🔹 кешировать конфигурацию/маршруты, чтобы уменьшить накладные расходы на bootstrap.

🧠 Когда это эффективно
✅ Высокая нагрузка на API/сервер
✅ Часто повторяющиеся запросы к одним и тем же данным
✅ Страницы, результаты поиска, публичные каталоги
✅ Обслуживание данных, которые редко меняются

⚠️ Что важно учитывать
⚠️ Если данные меняются часто — кеш нужно инвалидировать своевременно
⚠️ Неразумное кеширование может привести к устаревшим ответам
⚠️ Не все маршруты подходят для полного HTTP-кеша — динамические, приватные, зависящие от сессии должны быть исключены

Библиотека пхпшника

🐘 PHP для начинающих: зачем нужен php artisan и как им пользоваться

php artisan — это CLI-интерфейс Laravel, который ускоряет разработку:
он генерирует код, управляет БД, помогает с отладкой и обслуживанием проекта.
Если вы работаете с Laravel и не используете artisan — вы тратите время впустую.

1️⃣ Контроллеры
🔹 Обычный контроллер

php artisan make:controller UserController

Что делает: создаёт пустой контроллер
Когда использовать: нужен полный контроль над методами

🔹 Resource-контроллер (CRUD)

php artisan make:controller UserController --resource

Создаёт методы:
index, create, store, show, edit, update, destroy
Идеально для: MVC-приложений

Работает в паре с:

Route::resource('users', UserController::class);

🔹 API Resource-контроллер

php artisan make:controller UserController --api

Без create() и edit()
Для: REST API (JSON, Sanctum, JWT)

🔹 Invokable-контроллер

php artisan make:controller LoginController --invokable

Один метод __invoke()
Для: одного действия, чистые роуты

2️⃣ Представления (Blade)
🔹 View

php artisan make:view about

Создаёт resources/views/about.blade.php

🔹 Blade-компонент

php artisan make:component About

Для: переиспользуемых UI-элементов
Пример:

<x-about />

3️⃣ Модели и база данных
🔹 Модель

php artisan make:model Course

Часто используемые флаги:

-m — migration

-f — factory

-s — seeder

-a — всё сразу

🔹 Информация о модели (Laravel 10+)

php artisan model:show Course

Показывает таблицу, поля, связи, casts
Очень полезно для отладки

4️⃣ Миграции

php artisan make:migration create_posts_table
php artisan migrate
php artisan migrate:rollback --step=3
php artisan migrate:reset ⚠️ удаляет все таблицы
php artisan migrate:refresh

Запуск конкретной миграции:

php artisan migrate --path=/database/migrations/xxxx.php

5️⃣ Seeders (данные)

php artisan make:seeder TeachersSeeder
php artisan db:seed --class=TeachersSeeder

Для: тестовых и стартовых данных

6️⃣ Валидация и middleware

php artisan make:rule Uppercase
php artisan make:middleware CheckRole

Используется для:
валидации, авторизации, фильтрации запросов

7️⃣ Аутентификация и API

php artisan install:api

Устанавливает Laravel Sanctum и API-авторизацию

php artisan make:provider AuthServiceProvider

Gates и Policies

8️⃣ Почта

php artisan make:mail WelcomeMail

Emails и уведомления

9️⃣ Настройка и обслуживание

php artisan key:generate обязательно после clone
php artisan storage:link доступ к storage
php artisan down
php artisan down --secret=token
php artisan up

🔟 Роутинг и отладка

php artisan route:list
php artisan route:list --except-vendor

Для: поиска конфликтов и middleware

1️⃣1️⃣ Локализация и stubs

php artisan lang:publish
php artisan stub:publish

Stubs — шаблоны для make: команд
Можно кастомизировать стиль проекта

1️⃣2️⃣ Кэш и оптимизация

php artisan optimize
php artisan optimize:clear
php artisan config:cache
php artisan route:cache
php artisan view:clear

Для продакшена и странных багов

1️⃣3️⃣ Очереди и задачи

php artisan make:job SendEmailJob
php artisan queue:work

1️⃣4️⃣ Policies

php artisan make:policy CoursePolicy --model=Course

⭐ 1️⃣5️⃣ Tinker (обязательно знать)

php artisan tinker

Интерактивный REPL
Можно выполнять Laravel-код, запросы, сервисы прямо в консоли

Библиотека пхпшника

#php_азбука

Совет по Laravel: Порционное удаление данных

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

Библиотека пхпшника


#vardump

Какое значение по умолчанию принимает директива memory_limit в PHP?

Правильный ответ лежит в канале задач

Совет по Laravel 💡: Используйте события повторной привязки для обновления зависимостей

Когда привязанный экземпляр в контейнере Laravel привязывается заново, запускается событие повторной привязки. Вы можете прослушивать это событие, чтобы обеспечить актуальность классов, использующих этот экземпляр. Это можно сделать с помощью метода rebinding() или просто с помощью команды refresh 🚀

Библиотека пхпшника

#vardump

Symfony 7.4 — наконец-то без костылей

Иногда релиз фреймворка — это «косметика перед следующей мажорной версией».
Symfony 7.4 — не из таких.
Этот релиз закрывает старые, раздражающие проблемы, с которыми все давно смирились. И
делает это аккуратно, системно и по-взрослому.

🎥 Видео — больше не боль
Если вы когда-либо валидировали видео, вы знаете этот путь:
File → Image → кастомный валидатор → ffmpeg → боль.

В 7.4 появился #[Assert\Video] — и всё стало нормально.
Теперь можно одной аннотацией проверить:
🔸формат и MIME
🔸вес файла
🔸разрешение и ориентацию
🔸соотношение сторон
🔸длительность
🔸контейнеры и кодеки
🔸битые файлы ещё до бизнес-логики

Никакой логики в контроллере.
Никаких «проверим потом».
Видео либо валидно — либо сразу нет.

🧩 Консоль, которую приятно писать
Symfony Console всегда был сильным, но шумным.
В 7.4 его реально упростили.

Enum прямо в аргументах
Не строка, не if-else — нормальный BackedEnum.

DTO через #[MapInput]
Аргументы команд наконец выглядят как структура, а не мешок параметров.

#[Ask] и #[Interact]
Интерактив описывается декларативно, без ручных вопросов в коде.
CLI теперь пишется так же аккуратно, как контроллеры.

🧹 Request без магии
Старый Request::get() был удобным… и опасным.
Он угадывал, откуда брать данные. Иногда — не так, как вы ожидали.
В 7.4 его депрекейтнули. И это правильное решение.
Теперь вы всегда знаете:
1. откуда пришли данные
2. почему они именно такие
3. где искать баг

Плюс — на PHP 8.4 Symfony нормально парсит PUT/PATCH/DELETE с телом запроса. Без хака, без костылей, без сюрпризов.

📦 var/share — мелочь, которая сильно упрощает жизнь
Раньше:
кеш
шареные данные
временные файлы
всё лежало рядом.

Теперь:
var/cache — локально, быстро, одноразово
var/share — переживает деплой, масштабирование, рестарты
Если вы используете Docker или Kubernetes — вы сразу почувствуете разницу.

✨ Атрибуты вместо ритуалов
Symfony продолжает двигаться к коду без «обвязки»:
#[IsSignatureValid] — подписанные URL без сервисов
#[CurrentUser] с union-типами
нативный HTML5-парсер из PHP 8.4
Быстрее. Точнее. Без libxml-наследия.
Ничего не нужно настраивать — просто становится лучше.

👉 Читать статью

Библиотека пхпшника

Что выведет код?

От 45 мс до 8 мс: тестирование Symfony 7.4 на FrankenPHP

Больше десяти лет PHP-стек выглядел одинаково: Nginx → FastCGI → PHP-FPM. Надёжно, привычно — и технологически застыло.
FrankenPHP ломает эту модель полностью.

FrankenPHP — это application server, встроенный прямо в Caddy. Без FastCGI, без прокси-прослоек и с ключевой фичей — Worker Mode.

В чём суть
В классическом PHP-FPM каждый запрос:

загружает autoload
поднимает Kernel
и тут же всё уничтожает

Для тяжёлых приложений на Symfony 7.4 это 30–100 мс чистых потерь на каждый запрос.

Что меняет FrankenPHP
Worker Mode загружает приложение один раз и держит его в памяти.
Результат:
🚀 3–4× рост RPS
⚡ P95 latency ~8 мс
🌐 HTTP/3, Early Hints, auto-HTTPS из коробки
🔴 встроенный Mercure без отдельного сервиса

Архитектура будущего
Один контейнер вместо nginx + php-fpm:
1. Docker
2. FrankenPHP
3. Symfony 7.4 LTS
4. real-time события без Redis и WebSocket-зоопарка

Важный нюанс
Worker Mode = общая память между запросами.
Stateful-сервисы — под строгий контроль. Symfony 7.4 решает это через ResetInterface, но архитектурное мышление придётся обновить.

Бенчмарк (AWS t3.medium)
Nginx + PHP-FPM: ~1 240 RPS / 45 мс
FrankenPHP Worker: ~3 850 RPS / 8 мс

PHP-FPM не «плохой» — он просто устарел.
Связка Symfony 7.4 + FrankenPHP — это новый дефолт для high-load и API-first проектов.
Если начинаете новый проект — выбирайте FrankenPHP сразу.
Если поддерживаете легаси — пора планировать миграцию.


👉 Читать статью

Библиотека пхпшника

Hi.Events

Опенсорс платформа для управления мероприятиями и продажи билетов

🔗 Github

Библиотека пхпшника

#инструменты

⚡️ How-to: serverless Symfony/PHP на AWS без Redis для сессий

У serverless есть ловушка: Lambda требует stateless, а PHP-сессии по умолчанию живут в файлах. В AWS Lambda это «песок»: инстанс исчез — сессия исчезла. Частый костыль — Redis/ElastiCache, но это уже VPC, обслуживание и лишние расходы. В статье предлагают более «чистый» вариант: хранить сессии и CSRF-токены в DynamoDB.

Идея простая: заменить файловый session handler на DynamoDB-backed, добавить TTL для авто-истечения и использовать Lambda Function URL (без API Gateway). В итоге приложение остаётся действительно serverless: масштабируется само, не требует инфраструктуры под Redis и платит «по факту». Отдельно разбираются single-table паттерны (сессии/CSRF/сущности в одной таблице), нюансы генерации URL в Symfony и честные компромиссы: cold start, стоимость на высоком стабильном трафике и гонки при параллельных вкладках.

🔗 Читать статью

Библиотека пхпшника

⌨️ Топ-вакансий по PHP за неделю

Middle PHP-разработчик (Fullstack) — от 200 000 до 250 000 ₽, Удалёнка/Офис (Москва)

PHP Developer — 200 000 —‍ 400 000 ₽, Удаленка (Москва)

Middle PHP-разработчик, Symfony (SaaS, b2b) — Договорная, Удалёнка (Москва)

➡️ Еще больше топовых вакансий — в нашем канале PHP Jobs

«Как я ускорил установку PHP-зависимостей в 5 раз с помощью Go»

PHP-разработчик решил проверить простую гипотезу:
что будет, если убрать PHP-runtime и сделать установку зависимостей по-настоящему параллельной?

Результат — go-composer: совместимый (почти) с Composer инструмент, написанный на Go.

Почему обычный Composer медленный
Коротко и без иллюзий:

• интерпретируемый PHP
• последовательная загрузка пакетов
• тяжёлый runtime даже для простых операций
• медленный SAT-resolver зависимостей

В CI это превращается в минуты ожидания.

Что сделал go-composer
Ключевая идея — конкурентная модель Go:
• параллельная загрузка всех пакетов (goroutines)
• один скомпилированный бинарник (~10 MB)
• отсутствие PHP runtime overhead
• эффективная работа с памятью

Архитектура (упрощённо)
Пайплайн выглядит так:
1️⃣ Парсинг composer.json / composer.lock
2️⃣ Resolver строит граф зависимостей
3️⃣ Пакеты загружаются параллельно
4️⃣ Генерируется совместимый autoload
5️⃣ Результат — привычный vendor/

Самое интересное внутри
Parallel Installer — сердце ускорения
Каждый пакет:

• скачивается
• проверяется по SHA-256
• распаковывается
• добавляется в lock

И всё это — одновременно, а не по очереди.

Бенчмарки (MacBook M1, 300 Mbps)
Результаты выглядят болезненно честно:
• Monolog (3 пакета): 3–4× быстрее
• Symfony app (36 пакетов): 4–5× быстрее
• Laravel app (80+ пакетов): до 5× быстрее

Что уже работает
✅ composer.json / composer.lock (чтение)
✅ semver (^, ~, >=, ||, *)
✅ PSR-4 / PSR-0 / classmap
✅ Packagist (P2 API)
✅ проверка хэшей

Что не работает (и это важно)
❌ Composer scripts
❌ Composer plugins
❌ VCS-репозитории
❌ Private Packagist
❌ полная совместимость composer.lock

👉 в продакшен — пока нет

Почему появился go-composer.lock
Полной совместимости с composer.lock пока нет, поэтому:
• если lock есть — используется он
• если нет — создаётся go-composer.lock
• флагами можно управлять поведением

Это честный технический компромисс.

👉 Хабр

Библиотека пхпшника

🧠 Оптимизируйте автозагрузку в Symfony с помощью Service Container preloading

🚀 Что такое preloading в контексте Symfony

Symfony пользуется Service Container, который создаёт множество PHP-классов и зависимостей для каждого запроса. Чтобы снизить накладные расходы на автозагрузку и повторную компиляцию этих классов на каждом запросе, можно включить OPcache-preloading — когда PHP загружает классы один раз на старте процесса и держит их в памяти.

Preloading помогает избегать многократного вызова автозагрузчика и снижает I/O-операции, потому что классы уже готовы к использованию до первого запроса.

⚙️ Как это работает в Symfony
1. Symfony может сгенерировать специальный preload-файл, который содержит список нужных классов — часто это файл вроде:

var/cache/prod/App_KernelProdContainer.preload.php

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

2. В php.ini нужно указать путь к этому файлу в директиве opcache.preload:

opcache.preload=/path/to/project/var/cache/prod/App_KernelProdContainer.preload.php
opcache.preload_user=www-data

Благодаря этому PHP заранее закеширует эти классы в OPcache ещё до обработки первого запроса.

3. Symfony поддерживает теги container.preload и container.no_preload, чтобы тонко настраивать, какие классы должны (или не должны) попадать в preload. Это даёт контроль над тем, какие части приложения загружаются заранее.

📈 Почему это даёт преимущество
🔹 Меньше автозагрузки: после preload’а PHP не вызывает автолоадер для этих классов, что снижает число системных вызовов и ускоряет отклик.
🔹 Более быстрый контейнер: код контейнера (сервисы, зависимости) часто входит в preload-список — это ускоряет его инициализацию.
🔹 Оптимизация OPcache: preload’енные классы остаются в памяти OPcache между запросами, снижая накладные расходы на парсинг и компиляцію PHP-файлов.

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

🧠 Когда использовать
✅ Production-среда: preload лучше всего раскрывает себя на стабильно работающем приложении без частых изменений файлов.
✅ Большие проекты: где много сервисов и зависимостей — preload помогает устранить значительный слой задержек.
⚠️ Dev-окружение: preload менее нужен, так как код часто изменяется — потребуется частый рестарт сервера/OPcache при изменениях.

📌 Практические рекомендации
➤ Убедитесь, что файл preload действительно сгенерирован — в некоторых проектах его может не быть по умолчанию.
➤ Настройте OPcache: включите opcache.enable_cli, увеличьте memory_consumption, max_accelerated_files, и установите validate_timestamps=0 на проде для стабильной загрузки.
➤ Используйте теги container.preload и container.no_preload, чтобы включать только действительно нужные классы — это помогает избегать загрузки лишнего.

📌 Итог
Оптимизация автозагрузки через OPcache preloading в Symfony — это мощный способ ускорить приложение на уровне PHP-рантайма:
✔️ сокращает работу автозагрузчика,
✔️ уменьшает I/O и время инициализации контейнера,
✔️ даёт заметный прирост производительности без изменения бизнес-логики.

Библиотека пхпшника

PHP в 2026

Если коротко: PHP не стагнирует. Он аккуратно, но системно взрослеет — и в 2026 это особенно заметно.

PHP 8.5
Релиз без «вау-революций», но с полезными доработками: pipe-operator, клонирование объектов с модификацией, улучшения замыканий, нормальные stack trace даже для fatal error. Это не хайп, а качество жизни.

Partial Function Application → PHP 8.6
Вот здесь начинается магия. PFA раскрывает pipe-operator по-настоящему: меньше анонимных функций, больше читаемого функционального кода. PHP медленно, но уверенно учится декларативности — и это хороший знак.

Pattern Matching (RFC)
Пока в обсуждении, но потенциал огромный. Более выразимые match-конструкции и is-проверки — шаг к более строгому и понятному коду.

FrankenPHP
Кандидат на будущее PHP-рантайма по умолчанию. Drop-in замена PHP-FPM, +10% производительности «из коробки», worker-mode, бинарные сборки, современный HTTP. Без боли — с профитом.

Mago
Линтер, форматтер и статический анализатор на Rust. Быстро. Строго. Практично. Пример того, как экосистема учится у других языков.

Async PHP / TrueAsync
Сложно, долго, но перспективно. Пока фокус на CPU-тасках и потоках, но если дойдём до удобного async I/O — PHP сильно выиграет в серверных сценариях.

PHPverse — возвращается в 2026
Онлайн-конфа показала, что комьюнити живо и массово. Это важно.

Tempest
Новый взгляд на PHP-фреймворки: современная архитектура, активное OSS-сообщество, третий мажорный релиз на подходе.

🔗 Ссылка на статью

Библиотека пхпшника

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

Библиотека пхпшника

#vardump

Какая функция используется для сортировки массива в естественном порядке (без учета регистра)?

Правильный ответ лежит в канале задач