💻 Подборка новостей по PHP за неделю:​

🔹 CakePHP 4.6.3 — исправлены предупреждения о депрекейшнах в PHP 8.4 и 8.5, а также ошибки при работе с подзапросами, которые уже были выполнены.

🔹 PhpStorm 2025.3 — крупное обновление IDE: нативная интеграция Claude Agent, поддержка Laravel «из коробки», совместимость с PHP 8.5, улучшенная работа с дженериками и новая тема Islands.

🔹 Laravel 12.41 — представлен обновлённый современный шаблон писем, добавлены хелперы для длительностей (миллисекунды, недели, месяцы) и команда перезагрузки сервисов во время деплоя.

🔹 Symfony 8.0.2 — maintenance-релиз с исправлениями и улучшениями стабильности.

🔹 Symfony 1–7 декабря — активная работа над багфиксами после релиза Symfony 7.4 и 8.0, опубликован отчёт с SymfonyCon Amsterdam и анонсирована конференция SymfonyCon Warsaw 2026.

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

#свежак

💡 Совет по Laravel: Форматоры Faker

Поскольку Laravel использует FakerPHP для генерации фиктивных данных, вы можете использовать как numerify, так и bothify для генерации данных по определенному шаблону 🚀.

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

📍 Навигация: Вакансии • Задачи • Вопросы с собеса

#vardump

🚀 Symfony 7.4 — новый LTS, время апгрейда

В конце ноября 2025 вышла Symfony 7.4 — официальная Long-Term Support версия.
Это не просто «ещё одна версия»: 7.4 — серьёзный шаг к упрощению архитектуры и снижению лишнего кода, особенно если вы работаете на PHP 8.2+.

✅ Что реально даёт Symfony 7.4

Многоэкранные маршруты — теперь в атрибуте #[Route] env принимает массив. Можно одним маршрутом охватить, например, dev и test, и при этом его не будет в prod. Чисто, понятно, без дублирования.
Меньше проверок вручную — атрибут #[CurrentUser] теперь поддерживает union-типизации. Если в одном фаерволе используются, скажем, AdminUser и Customer, — можно сразу типизировать параметр метода как AdminUser|Customer, без ручных instanceof.
Более гибкая безопасность — с #[IsGranted] можно указывать проверку не для всего метода, а только для конкретных HTTP-методов (GET, DELETE и т.д.). Это даёт возможность держать логику (например, чтение и удаление ресурса) в одном методе, но с разным контролем доступа.
Унификация событий — #[AsEventListener] теперь поддерживает union-типы в сигнатуре: можно одним слушателем обрабатывать сразу несколько событий. Это сокращает дублирование кода и упрощает архитектуру.
Возможность «допиливать» чужие классы — теперь можно добавлять атрибуты валидации/сериализации к DTO или другим классам, которые вы не контролируете. То есть, если используете сторонний класс — всё равно можно навесить свои ограничения через «прокси-классы».

🔎 Почему это важно
Symfony 7.4 — это не просто «новые фишки», это стремление к чистоте архитектуры, к уменьшению шаблонного кода и увеличению устойчивости. Это значит:
🔸 меньше boilerplate, меньше копипасты;
🔸 легче поддерживать, рефакторить и тестировать код;
🔸 проще масштабировать проекты — меньше «магии» конфигураций, больше явного, понятного кода;
🔸 долгосрочная стабильность: LTS-версия, с поддержкой багфиксов до 2028 и патчей безопасности до 2029.
Если вы всё ещё на Symfony 6.4 или 7.x — сейчас самое время планировать миграцию. Особенно, если проект живёт и будет жить несколько лет.

📅 Что делать прямо сейчас
Проверьте, что ваш PHP ≥ 8.2 — это минимальное требование для 7.4.
Проанализируйте, где у вас используются маршруты, проверки CurrentUser, слушатели событий, валидация/сериализация — подумайте, как они могут упроститься.
Поднимите 7.4 на тестовом окружении, прогоните тесты — и постепенно заменяйте устаревшие YAML/аннотации/дублирование на современные атрибуты.

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

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

PHP жил, жив и будет жить. А ты?

Рынок требует от PHP-разработчиков всё больше: понимание сложных архитектур, алгоритмическая база, умение работать с высокими нагрузками. Хватит клепать сайты-визитки.

Акция 1 + 2:

Три курса по цене одного. Оплачиваешь самый дорогой, два других — в подарок.

Твой путь к Senior:

— архитектуры и шаблоны проектирования;
— алгоритмы и структуры данных.

Прокачаться

Акция до 31 декабря.

Не знаешь, что выбрать? @manager_proglib

Что будет выведено данным скриптом?

Whisp — простая стартовая точка для создания приложений PHP SSH

Whisp — это «чистый PHP» SSH-сервер, который позволяет запускать PHP-скрипты как SSH-приложения: при SSH-подключении вы попадаете не в обычную оболочку, а в PHP-приложение с TUI или CLI.

Можно задать набор «приложений» (скриптов) — и пользователи могут выбирать, куда подключаться, либо указывать имя приложения при SSH.

Требования: PHP 8.2+, расширения FFI, pcntl и libsodium

🔗 Github

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

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

🛠️ How to: безопасно перейти с «уродливых» URL на чистые и человекочитаемые

Если ваш сайт всё ещё выдаёт адреса вида /product.php?id=12345, вы теряете в удобстве, аналитике и небольшом SEO-профите. Переход на чистые URL — /products/red-running-shoes — даёт выигрыш, но только при корректной миграции, иначе риски высоки.

🔎 «Уродливые» vs «чистые» URL
Ugly: /article.php?id=9876
Clean: /blog/url-migration-best-practices
Чистые URL лучше читаются, повышают CTR и дают поисковикам больше контекста — без магии, только структурное преимущество.

⚠️ Почему миграция опасна без подготовки
Неправильная замена структуры приводит к:
🔸 падению органического трафика
🔸 массовым 404
🔸 потере ссылочного веса

Это решается заранее настроенными 301-редиректами.

✔️ Пошаговый план
1) Аудит
Прокрасьте сайт Screaming Frog’ом, выгрузите все URL. Посмотрите server logs и определите приоритетные страницы.
2) Новая структура
Сформируйте правила для слегов: строчные буквы, дефисы, короткие словосочетания, единый паттерн.
3) Карта соответствия
Создайте таблицу:
old_url → new_url → status → priority → notes → backlinks.
4) Настройка 301 редиректов
Предпочитайте серверный уровень (Apache/Nginx).
Пример принципа:

Redirect 301 /product.php?id=987 /products/mens-black-leather-shoes

Лучшие практики:
— один редирект вместо цепочек
— единое место хранения правил
— учитывать/очищать query-параметры последовательно
5) Обновление внутренних ссылок
Правьте меню, breadcrumbs, canonical-теги, sitemap.
Заново отправьте sitemap в Search Console.
6) Тестирование
Проверьте на стейдже:
— корректность всех 301
— отсутствие блокировок в robots.txt
— отсутствие утечек старых URL в шаблонах
7) Мониторинг
Первые две недели: ежедневно смотреть GSC, 404, трафик, падения по ключам. Быстро устранять ошибки.

⚙️ Советы разработчикам
Используйте regex-паттерны для массовых правил, но фиксируйте итоговую карту вручную.
Тестируйте редиректы через curl и автоматические краулеры.
Делайте релиз в низкую нагрузку и держите rollback-план.

🔧 Полезные инструменты
Screaming Frog
Google Search Console
Ahrefs/Semrush (бэки)
Серверные логи

📋 Чек-лист после миграции
Все старые URL возвращают 301 → новый канонический URL
Нет цепочек и дублей
Sitemap пересобран и отправлен
Canonical обновлены
404 исправляются оперативно

📚 Подробный разбор и практический кейс

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

📍 Навигация: Вакансии • Задачи • Вопросы с собеса

«Я хотел бы знать это раньше. Очереди в Symfony»

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

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

❗ Ошибка №1. Хаотичный нейминг ресурсов
Когда сервисов много, а правил нет, RabbitMQ превращается в набор непонятных очередей и exchange'ей. Чтобы избежать «зоопарка», используется единый шаблон именования:

{service}.{eventOrCommand}[.{consumer}].{queue|exchange|routingKey}[.{failed}]

Он позволяет понять:
• кто публикует сообщение;
• что делает событие или команда;
• кто является потребителем;
• какой тип ресурса перед нами;
• является ли очередь failed-контуром.

❗ Ошибка №2. Сырые JSON вместо явных DTO
Если сообщение передаётся как обычная JSON-строка, изменения формата неизбежно ломают часть потребителей.
Решение:
• для каждой очереди заводится отдельный DTO;
• Messenger принудительно десериализует входящее сообщение в этот класс, даже если внешний продюсер не передаёт заголовок type.
Такой подход устраняет скрытые изменения контракта и гарантирует корректное преобразование на всех языках и сервисах.

❗ Ошибка №3. Отсутствие полноценного failed-контра
Если обработчик падает, сообщение легко потерять, особенно при кастомных конфигурациях. Надёжная схема:
• у каждого транспорта — своя failed-очередь;
• у каждой failed-очереди — собственный exchange;
• включён TTL (например, 7 дней), чтобы очередь не разрасталась до бесконечности.
Это обеспечивает прозрачность ошибок и упрощает повторную обработку.

❗ Ошибка №4. «Очереди работают → значит всё в порядке»
Даже если обработчики крутятся, без мониторинга можно не заметить, что сообщения лежат часами.
Минимальный набор наблюдаемости:
• размер очередей и их рост;
• количество ошибок и сообщений в failed-контуре;
• время обработки (P95 / P99);
• отдельные логи по каждому типу сообщений;
• простые алерты: рост очереди, всплеск ошибок, деградация скорости.

📌 Что это даёт командам
• прозрачный нейминг и понятная структура RabbitMQ;
• безопасные и стабильные контракты сообщений;
• предотвращение тихих потерь данных;
• наблюдаемость и предсказуемое поведение очередей;
• возможность быстро находить и устранять проблемы.

🔗 Хабр

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