Библиотека пхпшника | PHP, Laravel, Symfony, CodeIgniter

✅Автозаполнение вводимых команд в Laravel При создании опций для CLI-приложений вы можете улучшить UX, реализовав автозаполнение для пользователя. Это можно сделать с помощью метода anticipate, предоставляемого Laravel 🚀 Библиотека пхпшника #vardump

💻 Подборка новостей по PHP за неделю:​ 🔹 Laravel: официальная AI-документация — в документации Laravel 12.x появился раздел AI Assisted Development с рекомендациями по эффективному использованию AI-инструментов при разработке Laravel-приложений. 🔹 Filament v4.5 — вышло обновление админ-панели с улучшениями из версий 4.4 и 4.5: доработки UX, новые возможности компонентов и дальнейшая шлифовка стабильности. 🔹 Claude Code Simplifier для Laravel — Тейлор Отвелл выпустил плагин для Claude Code, который автоматизирует упрощение и чистку Laravel/PHP-кода прямо в рабочем процессе. 🔹 Laravel 12.45.1–12.46.0 — добавлены новые хелперы для массивов и коллекций, улучшена авторизация Gate с поддержкой enum, а также включены важные багфиксы. 🔹 Symfony 5–11 января — фокус на исправлении багов и обновлении тестов под новые версии PHPUnit. В Symfony 8.1 начали появляться новые фичи, а Symfony UX представил новый Toolkit-пакет. Библиотека пхпшника #свежак

🎄 Новый год прошёл — возвращаемся в рабочий режим Декабрь был рваным: дедлайны, релизы «перед праздниками», хотфиксы между салатами и попытки не сломать прод на последнем деплое года. Теперь это уже история — самое время спокойно разобрать, что реально произошло и что делать дальше. Предлагаем в этой ветке дополнительно обсудить: 🎯 что из запланированного на декабрь так и не взлетело — и почему 📉 какие технические долги утащили с собой в январь 📈 какие решения неожиданно сработали лучше ожиданий 🧪 что хотите переписать, выкинуть или зафиксить в первом квартале 🚀 планы на 2026: стек, архитектура, апгрейды, эксперименты Новый год — удобная точка не для «мотивационных обещаний», а для холодного инженерного пересмотра: что масштабируется, что тормозит команду, а что пора честно признать ошибкой. 👇 Пишите, с чем вы вошли в январь — и куда собираетесь двигаться дальше. Библиотека пхпшника

#байтовый_юмор

«Этот манёвр будет стоить нам 51 год...» Если вы застряли на поддержке легаси, пора делать манёвр в сторону архитектуры и алгоритмов. Это единственный путь к масштабным проектам и высоким зарплатам. До понедельника все курсы Proglib Academy доступны по старой цене: — Разработка ИИ-агентов — Математика для разработки AI-моделей — ML для старта в Data Science — Математика для Data Science — Специалист по ИИ — Алгоритмы и структуры данных — Программирование на Python — Основы IT для непрограммистов — Архитектуры и шаблоны проектирования Успеть забрать со скидкой ⚠️ Дедлайн — 19 января

Иногда вам может потребоваться убедиться, что строка заканчивается определенным символом, например косой чертой или точкой. Laravel поставляется с помощником finish, который позволяет сделать это 🚀. Библиотека пхпшника #vardump

🧑‍💻 Пишете на PHP, но всё чаще появляются задачи, где стандартного стека не хватает? Интенсивные вычисления, интеграции с нативным кодом, необходимость выжать максимум из железа — здесь в игру входят FFI и WASM. 📖 На открытом уроке поговорим о сценариях применения, типичных задачах, для которых подключают FFI или WebAssembly, и разберём реальные примеры. ❗️ Вы увидите, какие преимущества дают FFI и WASM с точки зрения производительности и гибкости и архитектуры, а также с какими рисками и ограничениями придётся считаться. Это полезно тем, кто хочет выходить за рамки классического PHP и понимать, какие инструменты есть над фреймворками. ▶️ Встречаемся 26 января в 20:00 МСК в преддверие старта курса «PHP Developer. Professional». Регистрация открыта: https://clc.to/u0ASNg Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

Небольшой совет по PHP, который сэкономит время (и строки кода) Недавно при ревью PHP-проекта всё работало идеально: тесты зелёные, багов нет. Но в глаза бросилось другое — один и тот же шаблон в каждом конструкторе(фото 1) Технически всё корректно. Практически — это рутина. Когда в проекте: — десятки классов — по 5–10 свойств в каждом вы постоянно пишете один и тот же бойлерплейт. Это шум, а не логика. Что изменилось с PHP 8.0 В PHP 8.0 появился Constructor Property Promotion. Он позволяет объявлять и инициализировать свойства прямо в конструкторе(фото 2) Результат: — нет отдельных свойств — нет $this->name = $name — поведение то же — кода меньше — читать быстрее Мозг фокусируется на зависимостях класса, а не на механике. Видимость — любая

class Post
{
 public function __construct(
  public string $title,
  public string $content,
  private int $authorId
) {}
}

Работает ровно так, как ожидается. Реальный эффект на проекте В одном Laravel-сервисе было 12 свойств. Конструктор — ~30 строк. После рефакторинга: — 6 строк — логика не изменилась — код стало проще ревьюить Времени: ~2 минуты (multi-cursor в VS Code). Когда стоит использовать Используйте promotion, если: — свойства задаются только в конструкторе — нет дополнительной логики при присваивании — хотите чистый, современный PHP Когда не стоит Не используйте, если: — нужна валидация — вы трансформируете значение — важно явно показать логику инициализации Здесь старый способ — осознанно лучше. 🔗Ссылка на статью Библиотека пхпшника

🧠 Отключайте логирование SQL при тяжёлых запросах 🧠 Суть проблемы Когда вы выполняете много SQL-запросов, особенно в пакетных операциях (импорт больших объёмов данных, миграции, мигрейт-скрипты), ORM может логировать каждый запрос. Такое логирование полезно при отладке, но в рабочих сценариях оно: ⚡ генерирует огромное количество записей в памяти, ⚡ может привести к утечкам памяти (memory leak) при Doctrine, если логгер накапливает записи, ⚡ увеличивает время выполнения операции, так как обработка логов сама по себе не бесплатна. Почему отключать логирование полезно 🔹 При больших импортных задачах или миграциях сотни тысяч запросов могут накапливаться в логере — это вызывает рост потребления памяти и может привести к «зависанию» процесса. 🔹 Если логирование не нужно в этом контексте, его отключение убирает ненужную нагрузку и ускоряет выполнение операций. 🔹 Это особенно важно на production-задачах, где производительность имеет приоритет над подробным аудитом запросов. 🛠️ Как отключить логирование в разных экосистемах 🟦 Laravel (Eloquent / Query Logging) Laravel логирует запросы, если включён режим отладки или уровень логов очень подробный. Чтобы уменьшить SQL-логирование, в .env: APP_DEBUG=false LOG_LEVEL=info Это снизит объём логов, не выводя SQL-запросы по умолчанию (они обычно логируются на уровне debug). Если же вы используете кастомный логгер запросов — отключите его в продакшене. 🟩 Symfony / Doctrine ORM Doctrine по умолчанию может логировать SQL через SQLLogger (особенно в dev-режиме). Для отключения логгера Doctrine: $emConfig = $entityManager->getConnection()->getConfiguration(); $emConfig->setSQLLogger(null); Это полностью выключит SQL-логирование для этого соединения. Такой подход особенно полезен при массовых операциях, например в консольных командах или миграциях. 💡 Значение null удаляет логгер, и Doctrine перестаёт накапливать записи о каждом выполненном SQL. ⚠️ В более новой версии Doctrine SQLLogger был заменён системой middlewares, и для полного отключения придётся убирать middleware-логгеры — см. документацию. 📌 Пример использования в консоли (Symfony) Если у вас есть импорты/массовая обработка в консольной команде — отключите логгер в начале:

public function execute(InputInterface $input, OutputInterface $output): int
{
 $config = $this->entityManager->getConnection()->getConfiguration();
 $config->setSQLLogger(null);

 // дальнейшая обработка
}

Такой трюк помогает избежать накопления большого количества логов в памяти и снижает риски OOM (Out Of Memory). 🧠 Когда это стоит делать ✅ Тяжёлые операции с данными: импорт/экспорт больших таблиц, миграции ✅ Длительные фоновые задачи в очередях/консоли ✅ Прод-окружение, где логи не нужны для каждого SQL-запроса ⚠️ Когда не стоит отключать ❗ Если вы на этапе отладки и хотите видеть каждый запрос для оптимизации ❗ Если нужно собирать подробную аналитику SQL-вызовов ❗ Если у вас разработка и подробные логи помогают тестировать логику Библиотека пхпшника

Yii3. Официальный релиз Это случилось! Yii3 официально выпущен после многих лет интенсивной разработки и полировки. 🔗 Хабр Библиотека пхпшника

Roadmap: Внедрение ИИ-агентов в PHP-приложения ИИ-агенты — это новый стандарт автоматизации бэкенда. Разработчикам на PHP пора осваивать архитектуру автономных систем для расширения возможностей своих проектов. Этапы обучения: — изучение принципов взаимодействия с языковыми моделями через API; — проектирование агентской логики: инструменты, память, планирование; — интеграция мультиагентных систем в веб-сервисы; — оптимизация работы агентов для решения бизнес-задач. Курс «Разработка ИИ-агентов» проведёт вас от теории до реализации готовых ИИ-решений. Стать AI-разработчиком До 19 января действует акция «3 в 1»: купите один курс — два получите бесплатно.

⌨️ Топ-вакансий по PHP за неделю PHP разработчик — от 170 000 до 240 000 ₽, Удалёнка (Москва) Middle+ / Senior Laravel разработчик — от 2200 до 3000 $, Удаленка (Москва) Веб-программист PHP — 200 000 до 300 000 ₽, Удаленка (Москва) ➡️ Еще больше топовых вакансий — в нашем канале PHP Jobs

How to: правильно обрабатывать ошибки валидации в Symfony DTO + #[MapRequestPayload] в Symfony выглядят отлично. Но ошибки валидации по умолчанию — шумные, разные по формату и неудобные для фронта. Из-за этого часто появляются: 🔸 try/catch в контроллерах 🔸 дублирующийся маппинг ошибок 🔸 хаос в API-ответах ✅ Правильный подход Пусть валидация падает сама, а форматирование ошибок происходит глобально, один раз. Это решает Symfony Validation Response Bundle: 🔹 перехватывает ошибки из #[MapRequestPayload], #[MapQueryString], #[MapUploadedFile]; 🔹 возвращает чистый JSON; 🔹 единый формат для всех эндпоинтов; 🔹 без логики в контроллерах. 🚀 Быстрый старт composer require soleinjast/symfony-validation-response Без конфигурации. Есть simple, RFC7807 и кастомные форматтеры. 👉 Подробный разбор и примеры — в статье. Библиотека пхпшника

#байтовый_юмор

🔍 Can I PHP: проверяем доступность фичи налету Расширение позволяет проверить доступность определенной функции/метода в различных версиях PHP и получить краткое описание возможностей. 👉 Сайт #инструменты

⚖️ whereHas() vs whereRelation() в Laravel короче — не значит понятнее Laravel-разработчики любят шорткаты. Меньше кода, меньше шума — приятно. Но в реальных проектах с командой и постоянно меняющимися требованиями выигрывает ясность, а не длина строки. Часто советуют заменить whereHas() на whereRelation():

// было
User::whereHas('profile', function ($q) {
    $q->where('is_verified', false);
})->get();

// стало
User::whereRelation('profile', 'is_verified', false)->get();

Формально — да, код короче. Практически — не всё так радужно. 🧠 В чём реальная разница whereHas() — явно про отношения

User::query()
    ->whereHas('profile', fn ($q) => $q->where('is_verified', false))
    ->get();

С первого взгляда понятно: 🔸фильтрация по relation 🔸логика живёт внутри профиля 🔸условия легко расширяются 🔸запрос честно отражает намерение whereRelation() — скрывает сложность

User::whereRelation('profile', 'is_verified', false)->get();

Читается как фильтр по колонке users. Но на деле — это подзапрос к связанной таблице. ❗️ Это вводит в заблуждение, особенно при чтении чужого кода. 🧩 Масштабирование условий С whereHas() — естественно и прозрачно:

->whereHas('profile', fn ($q) => $q
    ->where('is_verified', false)
    ->whereNotNull('phone')
    ->where('age', '>', 18)
)

С whereRelation(): 🔸либо цепочка вызовов 🔸либо возврат к whereHas() 🔸либо каша из стилей 🔍 Поиск и поддержка кода Реальный кейс: «Эндпоинт тормозит, ищем фильтрацию по отношениям» whereHas() — легко найти поиском whereRelation() — прячется среди обычных where Для поддержки и отладки это критично. ⚙️ Производительность — миф whereRelation() не быстрее. Под капотом — тот же whereHas() и почти идентичный SQL. Если медленно: 🔸нет индексов 🔸не тот подход к запросу Метод тут ни при чём. 🧱 Проблема консистентности Что происходит в проектах: 1. Сначала whereRelation() — «быстро и красиво» 2. Потом требования растут 3. Появляется whereHas() 4. В коде — два стиля без причины 5. В ревью — споры Если сразу использовать whereHas(): 🔸один паттерн 🔸единый стиль 🔸код готов к росту 🧠 Внутренности Laravel Без магии: whereRelation() — это обёртка над whereHas(). Не умнее. Не быстрее. Просто без closure. 📌 Правило на практике Можно whereRelation(), если: 🔸один простой фильтр 🔸скрипт, отчёт, админка 🔸логика точно не вырастет Лучше whereHas(), если: 🔸бизнес-логика 🔸командная разработка 🔸код придётся читать и менять Экономия пары символов — плохой аргумент. Пишите код для того, кто откроет файл через полгода. В реальных проектах честный whereHas() почти всегда выигрывает. 👉 Ссылка на статью Библиотека пхпшника #элементарный_выбор

Что будет выведено на экран?

🐘 PHP 8.5 выходит, а вы всё ещё не разобрались, какие фичи реально поменяют код, а какие останутся в релиз-нотах? 📖 На открытом уроке мы разберём, что именно вошло в релиз, какие изменения затронут ваш повседневный код и инфраструктуру, а какие можно отложить. Посмотрим на ключевые нововведения, изменения в языке и поведении, обсудим, как аккуратно внедрять их в проект. ❗️ Урок будет полезен практикующим PHP-разработчикам, которые хотят писать современный код, готовиться к обновлению продакшен-окружения и понимать, куда развивается стек. Вы получите структурированную выжимку вместо бесконечного чтения разрозненных статей. ▶️ Встречаемся 14 января в 20:00 МСК в преддверие старта курса «PHP Developer. Professional»: https://clc.to/0kdArw Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

🧵 PHP и многопоточность: куда всё реально движется (TrueAsync) Статья — не про «давайте добавим async». Она отвечает на более жёсткий вопрос: способен ли PHP вообще эволюционировать к настоящему параллелизму — и какой ценой. Коротко и без иллюзий 👇 ❓ Зачем эта статья RFC TrueAsync 1.7 упирается в будущее PHP Core. Асинхронность нельзя проектировать в вакууме — нужно понимать: где у PHP фундаментальные ограничения, можно ли выйти за рамки корутин, возможна ли реальная многопоточность без слома экосистемы. 🧪 Эксперимент, который всё прояснил Попытка обрабатывать CPU-тяжёлую телеметрию через корутины (Swoole): I/O — отлично CPU (сжатие, сериализация) — просадка throughput ×2 Вывод жёсткий, но честный:

Корутины не решают CPU-bound задачи.

Решение с выносом вычислений в отдельные процессы оказалось быстрее, несмотря на IPC. 🧠 Базовая модель: Single-threaded + offload Рабочая архитектура, уже доказавшая эффективность: Event Loop (1 поток) I/O, сеть, БД, ожидание Workers (несколько потоков / процессов) сжатие, криптография, парсинг, ML Так работают: 🔸Node.js (Worker Threads) 🔸Python (asyncio + executors) 🔸 PHP (Swoole Request Workers + Task Workers) ✅ Плюсы модели 🔹 тысячи I/O-операций без mutex’ов 🔹 простота reasoning’а (нет гонок) 🔹 минимум требований к компилятору 🔹 контроль над нагрузкой ❌ Минусы 🔻 ручное разделение задач 🔻 легко ошибиться и положить event loop 🔻 плохо подходит для вычислительных систем 🧱 Почему PHP не готов к потокам «из коробки» Главная проблема — память и GC: 🔸глобальный object_store 🔸refcount + stop-the-world GC 🔸память одного VM нельзя освобождать из другого потока 🔸ZTS ≠ настоящая многопоточность PHP — строго single-VM модель. 🧠 Ключевая идея: не делить память, а передавать владение Вместо shared mutable state: 🔸move-семантика объектов 🔸если refcount = 1 → перенос без копии 🔸иначе → deep copy с сохранением идентичности Это: 🔸безопасно 🔸без сериализации 🔸прозрачно для разработчика 🧵 Что реально нужно в core 🔸многопоточный memory manager 🔸адаптация GC под параллельный режим 🔸поддержка shared immutable объектов (GC_SHARE) 🔸исследование region-based memory Это не «хотелки», а необходимые условия. 🧩 Корутины + потоки вместе Поток = Awaitable. 🔸корутина не блокируется 🔸CPU-задача уходит в thread pool 🔸event loop остаётся отзывчивым Код выглядит последовательно, но работает параллельно. 🎭 Самая сильная абстракция — Actors Actors дают: 🔸изолированное состояние 🔸последовательную обработку сообщений 🔸отсутствие mutex’ов естественное OOP-мышление Каждый actor: 🔸может жить в своём потоке 🔸имеет собственный регион памяти 🔸безопасно масштабируется Это реальный путь к безопасной многопоточности в PHP. 🔗 Medium Библиотека пхпшника