Всем большой привет!

Итак, первое, поздравляю всех с профессиональным праздником Днем Программиста (как вы помните это 256 день)

Второе, сегодня мой день рождения, потому праздную я вдвойне можно сказать 😄 и у меня для вас есть интересная информация напрямую от одного из главных контрибьюторов PHP Дмитрия Стогова о новом JIT-движке, который будет использоваться в следующих версиях PHP.

Как вы знаете JIT появился в PHP 8.0 и представлял из себя компиляцию "на лету" - Just In Time, так же вы вероятно знаете, что PHP является интерпретируемым языком, он не компилирует программы в прямом смысле этого значения, как, например это делают C или Rust.

Чтобы включить JIT нужно было указать несколько параметров конфига php.ini.

Новый JIT движок PHP

Дмитрий Стогов поделился информацией в internal рассылках PHP о новом JIT-движке, который будет использоваться в следующих мажорных версиях PHP. Теперь это настоящий оптимизирующий компилятор с промежуточным представлением, аналогичный серверному компилятору Java HotSpot.

Он создает основу для будущих улучшений и устраняет многие низкоуровневые детали существующего PHP JIT. Вместо поддержки ассемблерного кода для разных процессоров теперь PHP генерирует один IR и передает его независимому от PHP JIT-движку.

Новая реализация JIT основана на IR-Lightweight JIT Compilation Framework и в отличии от старого JIT-подхода в PHP 8.*, который генерирует собственный код непосредственно из байт-кода PHP, эта реализация генерирует промежуточное представление (IR) и делегирует все задачи более низкого уровня в IR Framework. IR для JIT похож на абстрактное синтаксическое дерево (AST) для компилятора.

По сравнению с классическими оптимизирующими компиляторами (такими как GCC и LLVM), IR Framework использует очень короткий конвейер оптимизации. В сочетании с компактным IR-представлением это делает его чрезвычайно быстрым и позволяет генерировать довольно хороший машинный код за разумное время.

Более подробно и с примерами в новом посте https://sergeymukhin.com/blog/novyi-jit-dvizok-dlia-php-84-i-php-9

Ребят, привет!

Сегодня четверг и пара интересных новостей:

- Выпущен второй релиз кандидат для PHP 8.3

Как вы помните первый релиз кандидат PHP 8.3 был выпущен 31 августа, теперь же и второй кандидат доступен для тестирования, осталось еще 4 кандидата для финального выпуска.
Обратите внимание, что версии-кандидаты PHP 8.3 предназначены только для тестирования будущей версии PHP и не готовы для производственных систем.

31 Августа  RC 1
14 Сентября RC 2
28 Сентября RC 3
12 Октября  RC 4
26 Октября  RC 5
9 Ноября    RC 6
23 Ноября   GA

- Стали подготавливать список устаревших функции для PHP 8.4

Доброе утро, бодро работаем в пятницу и все те же пара новостей!

- Выпущен третий релиз кандидат для PHP 8.3 от

28 Сентября RC 3

Выше в посте можно увидеть график выхода всех релизов.


И к новостям о следующей версии PHP 8.4:

Вывод phpinfo() в PHP 8.4 будеть показывать размер целого числа, поддерживаемый текущей настройкой PHP в битах, также включается в выходные данные PHP CLI. Как вы помните, ранее все предыдущие версии (начиная с PHP 5.0.5) поддерживают константу PHP_INT_SIZE для определения размера целого числа.

Всем отличной пятницы, друзья!

Я тут немного расслабился в отпуске и пока не могу от него еще отойти, но давайте быстро наверстаем упущенное по текущим новостям:

1. Во-первых 12 и 26 Октября прошли 4 и 5 Релиз Кандидаты PHP 8.3

2. Как вы знаете интернет (те же сервисы Гугла и клиенты Cloudflare) потрясла HTTP/2 атака Rapid Reset (быстрого сброса)
При определенных условиях эту уязвимость можно использовать для выполнения атаки типа "отказ в обслуживании" в nginx или других продуктах, реализующих серверную часть спецификации HTTP/2. Чтобы защитить ваши системы от этой атаки, рекомендуется немедленно обновить конфигурацию NGINX или другого веб-сервера.

3. В PHP 8.4 стали появляться первые RFC, направленные на изменение текущего функционала, в частности
Алгоритмическая сложность хеширование паролей Bcrypt по умолчанию изменена с 10 на 12, чтобы сделать пароли более устойчивыми и сложными.

Это изменение по существу эквивалентно:

password_hash("some password", PASSWORD_BCRYPT, ["cost" => 12]);

Доброе утро!

За окном пятница, впереди выходные, давайте немного пробежимся по новостям:

1. 9 ноября вышел предпоследний релиз кандидат PHP 8.3 RC6
а это означает что следующий выпуск будет финальный, и по плану он 23 ноября, что уже довольно скоро)

2. Я продолжаю цикл статей о следующей версии HTTP/3 и здесь вы можете почитать о том, как подключить 3 версию http на Nginx
пример хоста nginx для подключения http3:

server
{
    # для лучшей совместимости рекомендуется использовать один порт для quic и https
    # указываем протокол quic и параметр reuseport для правильной работы с несколькими рабочими процессами
    listen 443 quic reuseport;    
    listen 443 ssl;

    # включаем поддержку http2
    http2 on;    
    # включаем поддержку http3
    http3 on;
    # разрешаем GSO
    quic_gso on;
    # разрешаем проверку адреса
    quic_retry on;

    # Для работы QUIC требуется версия протокола TLSv1.3.
    ssl_protocols TLSv1.2 TLSv1.3;

    ssl_certificate /path_certs/fullchain.pem;
    ssl_certificate_key path_certs/privkey.pem;

    # для перенаправления браузеров в quic-порт
    add_header Alt-Svc 'h3=":443";max=86400';

    ...

}

Трансляция PHP RnD

https://www.youtube.com/live/8ZzAqhgmBFg?feature=share

Релиз PHP 8.3

Ну вот и настало 23 ноября 2023 года, а с ним релиз следующей версии PHP 8.3.
Были небольшие проблемы с выпуском в планируемый срок, но официально он все же состоялся.

В PHP 8.3 есть улучшения классов только для чтения, новая функция json_validate(), дополнения к недавно добавленному классу Randomizer, обнаружение переполнения стека и многое другое.

Как установить можно почитать в последнем посте Как установить PHP 8.3 в Ubuntu/Debian.

Для Windows бинарники как обычно можно скачать https://windows.php.net/download/

Ребята, привет, всех с наступающим Новым Годом!

Я тут немного пропадал, но в любом случае, у меня есть для вас новости, итак что у нас нового в PHP 8.4:

1. В PHP 8.4 появится поддержка AEGIS-128L и AEGIS256 в Sodium
AEGIS - это семейство алгоритмов шифрования с проверкой подлинности на основе AES, которые работают быстрее, чем AES-GCM. Расширение Sodium в PHP 8.4 поддерживает алгоритмы шифрования AEGIS-128L и AEGIS256, если расширение Sodium скомпилировано с версией libsodium 1.0.19 или новее. Расширение Sodium в PHP 8.4 добавляет шесть новых функций и четыре новые константы PHP для AEGIS-128L и AEGIS-256AEAD.

2. Новый метод DateTime createFromTimestamp

До PHP 8.4, чтобы создать экземпляр DateTime или DateTimeImmutable из временной метки UNIX, его нужно было создать с помощью createFromFormat:

$dt = DateTimeImmutable::createFromFormat('U', (string) 1703485481);
$dt->format('Y-m-d'); // "2023-12-25"

С PHP 8.4 классы DateTime и DateTimeImmutable в PHP 8.4 имеют новый метод createFromTimeStamp, позволяющий легко создать экземпляр из заданной временной метки UNIX в виде целого числа или значения с плавающей запятой.

$dt = DateTimeImmutable::createFromTimeStamp(1703485481);
$dt->format('Y-m-d'); //"2023-12-25"

Далее, если вы разработчик своих пакетов PHP, то возможно вам будет полезна информацию о предложении Composer установки девтулсов в require-dev в новом посте
https://sergeymukhin.com/blog/composer-zastavit-ustanovku-paketa-require-dev

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

Всем удачи и хорошего Нового Года!!!

🎄С НОВЫМ 2024 ГОДОМ!🎄

Итак, новый год настал, но расслабляться не будем, ну разве что чуть-чуть)

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

А вот в продолжении к нему, недавно принятый RFC, про cпособ отключения/включения JIT по умолчанию:

До PHP 8.4 JIT был как был и включен и отключен по умолчанию, используя значение по умолчанию opcache.jit_buffer_size=0 вместо opcache.jit=disable. Это фактически отключает JIT не потому, что jit=disable, а потому что размер буфера установлен равный 0.

В этом RFC предлагается изменить эти значения по умолчанию на выключенный jit и размер буфера на 64 мегабайт:

opcache.jit=disable
opcache.jit_buffer_size=64m

Еще одна интересная новость, Валентин Удальцов автор канала Пых опубликовал RFC в котором пасрер PHP может пренебрегать скобками при обращении к объектам, созданным через new, т.е. вместо

(new Class())->method()

можно будет писать:

new Class()->method()

В данный момент это невозможно сделать, т.к. парсер PHP выдаст ошибку синтаксиса. Будем следить за развитием этого RFC.

Ну и как обещал разыграл слона и он уезжает к @Drummi, поздравляю! @Drummi напишите мне в личку адрес, куда я отправлю слона.

Надеюсь 2024 год будет насыщен на новые интересные и полезные RFC PHP.

Всем привет и хороших праздничных выходных!)

Ребят, тут phpcommunity.ru сделало свой ежегодный опрос среди разработчиков, можно неспеша пройти его — до закрытия осталось 3 дня.
Что интересно, там тоже можно будет выиграть php слона)

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

https://forms.gle/n9QErGz5iGYrWEzj9

Интересные события произошли в рейтинге TIOBE.

Впервые в истории индекса TIOBE C# получил награду «Язык программирования года». На втором месте Scratch (+0,83%) и Fortran (+0,64%). C# отнимает долю рынка у Java и становится все более популярным в таких областях, как серверная часть веб-приложений и игры (спасибо Unity). C# можно использовать бесплатно, и он постоянно развивается, делая язык более выразительным с каждой новой версией. C# никуда не денется и, возможно, вскоре он сможет даже превзойдет Java.

Помимо C#, в прошлом году в индексе TIOBE произошло много интересных изменений. Fortran и Kotlin навсегда вошли в топ-20 игроков, заменив старых фаворитов R и Perl. Фортран очень хорошо подходит для вычислений с помощью хороших библиотек и остается фаворитом университетов во многих областях. Kotlin — простой в изучении/написании конкурент Java.

Что интересно Julia ненадолго коснулась индекса TIOBE в 2023 году, но не смогла удержать эту позицию.

JavaScript поднялся на 6 место, а PHP на 7-ое.

Привет всем!

Ежегодный пост со статистикой версии PHP из открытых данных экосистемы composer. Статистика версий PHP - выпуск январь 2024.

Похоже, что внедрение PHP 8.3 происходит немного быстрее по сравнению с PHP 8.2: 6,4% проектов используют PHP 8.3 в течение первых двух месяцев после его выпуска, для PHP 8.2 этот показатель в свое время составил 4,7%.

Более того, доля PHP 7.* продолжает сокращаться - и это хорошо, учитывая, что поддержка серии 7.* закончилась более года назад. На данный момент PHP 8.1 является самой старой поддерживаемой версией, обновления безопасности которой будут получать только до 25 ноября этого года. Это важно обновить ваши версии PHP!

А вы уже обновились до PHP 8.3?)

Более подробно, с табличками и графиками https://sergeymukhin.com/blog/statistika-versii-php-vypusk-20241

Врываемся в пятницу! Ребята, всем привет!

Каждый день собираюсь "запоститься" и что-нибудь да отвлекает, итак что имеем на сегодня?

Изменения:

1. Тип констант PHP_ZTS и PHP_DEBUG изменен с int на bool.

PHP_ZTS и PHP_DEBUG - две глобальные константы PHP, которые предоставляют информацию о текущей среде выполнения PHP.

- PHP_ZTS: Указывает, является ли текущая сборка PHP потокобезопасной.
- PHP_DEBUG: Указывает, является ли текущая сборка PHP отладочной сборкой.

До PHP 8.4 эти две константы содержали целочисленные значения: 0 когда отключено и 1 когда включено. Начиная с PHP 8.4 и более поздних версий, они изменились на логические значения.

if (PHP_ZTS === 1) {} //было

if (PHP_ZTS) {} //стало

Устаревшие функции:

2. Константа CURLOPT_BINARYTRANSFER, предоставляемая расширением Curl, устарела в PHP 8.4. Эта константа не имела никакого эффекта, начиная с PHP 5.1.2.

Удаленные функции:

Pspell было перенесено из PHP Core в PECL

Расширение Pspell предоставляет из себя PHP функции проверки орфографии с помощью Pspell или Aspell. Зависимости этого расширения не получали никаких обновлений за последние несколько лет, в результате чего было принято решение расширение Pspell перенести из ядра PHP в расширение PECL в PHP 8.4.

IMAP было перенесено из PHP Core в PECL

В PHP 8.4 расширение IMAP больше не является частью PHP Core и перешло в PECL, рекомендуется перейти на альтернативные библиотеки, например Webklex/php-imap.

OCI8 и PDO-OCI были перенесены из PHP Core в PECL

Расширения oci8 и pdo_oci8 предоставляют функциональные возможности для использования баз данных Oracle в PHP. Эти расширения основаны на собственных библиотеках коммерческого поставщика Oracle. Эти расширения прошли длительный период накопления неисправленных ошибок и требуют значительных усилий для миграции их resource объектов в объекты классов. Учитывая зависимость этих расширений от сторонних проприетарных библиотек и необходимость усилий по их обслуживанию, расширения больше не являются частью ядра PHP и перешли на PECL как oci8 и pdo_oci.

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

Кстати кто не смотрел вчерашнюю трансляцию LivePHP советую к ознакомлению, почерпнете много чего интересного для себя)

https://www.youtube.com/watch?v=DhkTJcjJouc

Всем хороших выходных!

Ребята, приветствую всех!

Сегодня хочу рассказать об очередном интересном принятом RFC в PHP 8.4, который вводит две новых функций:

http_get_last_response_header(): ?array
http_clear_last_response_header(): void

которые можно использовать для получения и очистки HTTP-заголовков последнего ответа HTTP-обертки (wrapper), которые могут заменить историческую переменную $http_response_header.

Напоминаю, что когда вы зайдествуете слой stream'ов, в частности использование HTTP-wrappers (оберток) то всякий раз магически создается переменная $http_response_header в локальной области видмости. Одним из таких способов использования является получение содержимого по URL-адресу file_get_contents():

file_get_contents('https://sergeymukhin.com');

var_dump($http_response_header);
  
array (size=10)
  0 => string 'HTTP/1.1 200 OK' (length=15)
  1 => string 'Server: nginx' (length=13)
  2 => string 'Date: Thu, 07 Mar 2024 07:34:18 GMT' (length=35)
  3 => string 'Content-Type: text/html; charset=UTF-8' (length=38)
  4 => string 'Connection: close' (length=17)
  5 => string 'Vary: Accept-Encoding' (length=21)
  6 => string 'Set-Cookie: PHPSESSID=uea9m7qcm0jgq4t2g3kfolm51h; path=/' (length=56)
  7 => string 'Expires: Thu, 19 Nov 1981 08:52:00 GMT' (length=38)
  8 => string 'Cache-Control: no-store, no-cache, must-revalidate' (length=50)
  9 => string 'Pragma: no-cache' (length=16)

Переменная $http_response_header будет содержать все заголовки HTTP, которые были обнаружены во время запроса.
Мотивация введения новых функций обусловлена более предсказуемый и интуитивно понятный код:

file_get_contents('https://sergeymukhin.com/blog/cto-novogo-v-php-84');

 //$headers = $http_response_header;

 $headers = http_get_last_response_headers(); //запросили заголовки
 http_clear_last_response_headers(); //почистили за собой

Кстати, переменная $http_response_header не модифицируется этими новыми функциями. Т.е.

Очистка $http_response_header не влияет на возвращение значений из http_get_last_response_headers() (она продолжает возвращать все, что было доступно), а вызов http_clear_last_response_headers() не сбрасывает значение в переменной $http_response_header.

Всем доброй пятницы! И хороших выходных!

А пока расскажу про одно из самых значимых RFC в предстоящем PHP 8.4 - RFC1867 для методов HTTP, отличных от POST, которое вводит
новую функцию request_parse_body.

Как вы знаете PHP автоматически анализирует и разбирает HTTP-запросы POST для заполнения глобальных переменных $_POST и $_FILES. Однако другие HTTP-запросы с такими методами, как PUT или PATCH уже не анализируются автоматически, и работа с обработкой данных с данными типами запроса ложится на плечи разработчика/приложения.

Напомню RFC1867 определяет тип контента multipart/form-data. Этот тип контента используется в основном для отправки HTTP-форм, содержащих файлы. PHP изначально поддерживает анализ этого типа контента, но только для запросов POST. В частности, если запрос имеет метод POST и тип содержимого multipart/form-data, тело запроса немедленно используется перед запуском PHP-скрипта и заполняется в суперглобальные переменные $_POST и $_FILES. Эта функция запускается автоматически и не предоставляется непосредственно пользователю.

Учитывая популярность REST API, которые все чаще используют HTTP методы, отличные от POST - такие как PUT, DELETE и PATCH, где использование multipart/form-data полностью допустимо, но не обрабатывается PHP автоматически. Это требует ручного анализа тела запроса нетривиального формата. Обработка больших объемов данных в пользовательской среде также может быть не оптимальной с точки зрения производительности.

Например в Symfony эта часть отвечает за анализ и разбор таких данных, в том же Phalcon мне пришлось в свое время добавить эту возможность и так в любом мало-мальски используемом фреймворке.

Итак, в PHP 8.4 была добавлена ​​новая функция request_parse_body, которая предоставляет встроенную в PHP функциональность анализа запросов для других методов HTTP-запросов, отличных от POST:

function request_parse_body(?array $options = null): array {}


// Например, это запрос PUT
var_dump($_POST); // []
var_dump($_FILES); // []

[$_POST, $_FILES] = request_parse_body();

var_dump($_POST); // уже есть данные [...]
var_dump($_FILES); // уже есть данные [...]


При вызове функция request_parse_body считывает все содержимое, которое доступно в потоке php://input и создает значения, которые можно использовать в переменных $_POST и $_FILES.
Можно заполнить значения $_POST и $_FILES непосредственно из возвращаемых значений:

[$_POST, $_FILES] = request_parse_body();

Параметр $options можно использовать для передачи массива значений INI, связанных с анализом запроса. Эти значения не обязательно должны быть меньше, чем глобальная конфигурация. Это дает преимущество выборочной обработки меньших или больших значений, чем ограничения, установленные в файлах INI.
Например, чтобы проанализировать запрос с большим или меньшим пределом директивы post_max_size INI, можно вызвать функцию request_parse_body с нужным значением:

request_parse_body(['post_max_size' => 1024]);

И небольшое предупреждение: Функция request_parse_body имеет не идемпотентное поведение и предназначена для вызова только один раз за запрос, т.к. имеет разрушительное воздействие на php://input. При последующих вызовах функция вернет массив с пустыми данными, а поток php://input будет пуст после первого вызова request_parse_body().

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

Давайте дружно похлопаем и поблагодарим Илью Товило за столь замечательный функционал!

Чуть больше информации с табличками https://sergeymukhin.com/blog/php-84-novaia-funkciia-request-parse-body

Ребята, всех с праздником!

Хотел успеть запостить статью к 4.04, но не смог сегодня, поэтому пока просто поздравление с профессиональным, успехов в работе и меньше багов!