PHP *

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

PHP – один из самых популярных языков веб-разработки. Благодаря экосистеме фреймворков (Laravel, Symfony, Yii) и обширному опен-сорсу он остаётся выбором №1 для быстрого вывода приложений. При этом сообщество в основном концентрируется на классических уязвимостях (SQL-инъекции, XSS, CSRF, LFI/RFI). Тонкие особенности интерпретатора, малоизученных расширений и встроенных механизмов нередко остаются вне поля зрения. В этой статье мы подробно рассмотрим малоизвестные опасности и способы защиты от них.

Потребовалось мне сделать свою реализацию проверки прав для PHP. В итоге эта разработка стала отдельным пакетом. Возможно кому-то пригодится. В статье рассказываю как это работает.

Привет, меня зовут Степан Золотухин, я разработчик в Битрикс24. Моя команда работает над такими продуктами, как Почта, Маркетинг, Структура компании, Подписание, CRM-Формы и Бизнесс процессы.

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

В дефолтной конфигурации отправка идёт нативным PHP через функцию mail() (если у отправителя не задан SMTP). Дальше всё идет в инфраструктуру пользователя (exim, sendmail, postfix И так далее)
Это просто и надёжно, но скорость отправки упирается в ограничения при отправке в один поток.

Искал реализацию EAV (Entity-Attribute-Value) паттерна на PHP или Symfony и не нашел. Типичная задача, но, на удивление, нет таких библиотек. Решил сделать свою [EAV bundle](https://github.com/maxkain/eav-bundle). Есть достаточно подробная документация...

Для современных веб-приложений на PHP выбор ORM играет ключевую роль в организации работы с базой данных. В Laravel по умолчанию используется Eloquent — простой и удобный инструмент, идеально подходящий для большинства задач. Однако при сложных проектах, требующих гибкости, расширяемости и мощных возможностей работы с объектно-реляционным отображением — стоит обратить внимание на Doctrine ORM.

Я PHP-разработчик с многолетним стажем (от слова «много»). Привык, что мой мир — это веб‑приложения, серверный код и бесконечные «фичи» на Laravel или Yii (да... легаси — это мой конёк). В последние пару лет вокруг бушует AI‑бум: всюду слышно про нейронки, LLM, про каких‑то «агентов», которые сами решают задачи. И, признаться, временами у меня появлялась лёгкая тревога. Не отстану ли я от поезда, если не перейду полностью на Python/NodeJS или не выучу новый фреймворк? Ведь почти все примеры ИИ‑интеграций, что я видел, были на Python или JavaScript. PHP в этих разговорах фигурировал редко, если вообще упоминался.

Недавно я наткнулся на упоминание о Neuron — инструменте, который гордо назван «первым enterprise‑ready агентным фреймворком на PHP». Мой скептицизм сразу поднял голову: «Агентный фреймворк? На PHP? Серьёзно?» С другой стороны, это заинтриговало. Если всё правда, то вместо того чтобы судорожно перелистывать учебник по Python, возможно, я смогу внедрять ИИ прямо там, где мне комфортно — в PHP‑стеке. И вот я решил разобраться, что же такое этот Neuron и насколько он реален.

Привет, Хабр! В мире PHP-разработки роутинг — это основа любого веб-приложения. От простых API до сложных микросервисов, правильный роутер может стать ключом к производительности и масштабируемости. Сегодня я хочу представить вам Cloud Castle HTTP Router — мою библиотеку, которая сочетает скорость, простоту и мощь. Это не просто инструмент, а решение для разработчиков, которые хотят оставить позади громоздкие фреймворки и сосредоточиться на коде. Давайте разберем ее по полочкам: технические фичи, маркетинговый потенциал и архитектурные преимущества. А в конце — сравнение с конкурентами и реальные тесты из документации.

За 6 лет опыта работы в разных IT-компаниях — ни разу не встречал проекты на Laravel, где использовался бы CQRS. Да и погуглив немного, если честно, не нашел ничего стоящего (касательно примеров), поэтому решил сам написать статью на данную тему.

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

Обновление версии php в legacy-проекте — это часто настоящий квест. То времени нет, то бизнес-фичи надо пилить, то еще какие-то причины. И часто бывает, что обновление версии php в командах откладывается на потом.

14 октября 2025 года вышла Joomla 6, а так же минорная версия Joomla 5.4. Что нового в этих релизах, какой релизный цикл, ресурсы для Joomla-разработчиков - в этой статье.

В прошлой статье мы рассказали, почему Compo Soft решила уйти от привычного PHP‑стека и перейти на Java ради выхода в сегмент Enterprise. Но если кто‑то подумал, что за этим решением последовал массовый найм Java‑разработчиков — нет. Мы пошли по куда более хардкорному пути: взяли всю свою PHP‑команду и начали переобучать ее на Java. Полностью c нуля. И без отрыва от производства.

Статья о реализации параллельных SOAP запросов в PHP с использованием кастомного HTTP транспорта и Guzzle promises.

Я PHP-разработчик с восьмилетним коммерческим опытом. Долгое время я не видел смысла в микросервисах — пока не перешёл на Python и не столкнулся с его архитектурными особенностями.

Статья описывает методику миграции приложения, содержащего множество SQL запросов из базы данных Oracle в Postgres. Будет интересна всем, кто собирается мигрировать или уже мигрировал приложение из Oracle в Postgres.

Последние 4 года я занимаюсь реализациейпроектов на PHP по DDD, используя слоистую архитектуру. Каждый раз я сталкиваюсь с одной из самых насущных проблем DDD: определение границ агрегата. Ведя разработку «как удобно», очень легко не заметить, как вся бизнес логика сосредоточилась в один «божий класс».

В этой статье я поделюсь своим опытом, как проектировать и разрабатывать по DDD, не скатываясь в «один агрегат, чтобы править всеми». Поговорю о проблемах определения границ агрегата и цены чтения, гидрации и содержания больших объектов в памяти PHP процесса.

На протяжении многих лет команда Compo Soft успешно создавала eCommerce‑решения, клиентские порталы, PIM‑системы и другие решения малого и среднего бизнеса. Для этих задач было достаточно привычного стека на PHP и связанных с ним технологий. Когда в 2018 компания приняла стратегическое решение о выходе в сегмент Enterprise — встал вопрос о новом стеке. Им стала Java. В этой статье решили поделиться своим пониманием и опытом — почему сделан такой выбор, и почему PHP «не вывозит» Enterprise‑решения.

Enum’ы в PHP с нами уже давно, но вы задумывались, как они реально работают внутри? Давайте разберёмся, что там происходит под капотом.

Привет, Хабр!

Redis Streams давно перестали быть экзотикой для любителей CLI и стали нормальным способом гонять события между сервисами. Но у PHP есть своя специфика: один код — два способа конкурентности. Либо Amp с неблокирующим I/O и семафорами, либо Swoole с корутинами. В обоих случаях хочется одного и того же: устойчивые consumer-группы, ручной ack, автоматический claim зависших сообщений, backpressure, экспоненциальные ретраи и внятный дед-леттер.

Берем два разных больших числа (отличаются на 1) и проверяем равны ли они. Должно быть false – не равны. Но на самом деле – true! Они «равны» 😊

Эта статья для тех, кого удивляет данное поведение.

На одной из конференций по разработке ПО я разговорился с коллегой о современных подходах и архитектурных паттернах. В ходе беседы он задал мне, казалось бы, простой вопрос:

 «Какой архитектурный паттерн используется в твоём текущем проекте?»

Этот вопрос заставил меня задумать и взглянуть на проблему выбора архитектуры под другим углом. Возможно, повлияла атмосфера конференции (всё-таки они должны приносить пользу), но я задумался: почему при разработке приложений мы чаще всего закладываем один архитектурный паттерн, а не комбинацию нескольких? Однако, как показал личный опыт и обсуждения в профессиональном сообществе, этот вопрос часто подразумевает поиск единственного правильного ответа. В реальности же, на практике, мы нередко видим, как команды стремятся придерживаться одного доминирующего подхода — будь то акцент на CQRS, строгое следование Hexagonal Architecture или применение DDD в объеме текущего понимания и опыта команды. Но мало кто пытаеться применить сразу несколько подходов, где каждый паттерн решает свою задачу.

Гибридные подходы, комбинирующие сильные стороны различных архитектурных решений, становятся не просто возможной опцией, но часто необходимостью. Каждое из этих решений способно эффективно решать специфические проблемы: