Привет, добрых майских,

продолжая тему RFC с Property Hooks, Brent Roose (автор сайта https://stitcher.io и канала PHP Annotated) провел трансляцию с одним из авторов RFC Ларри Гарфилдом, видео очень интересное, помимо основной темы затрагивались так же около externals/internals вопросы.

Если английский не помеха, советую посмотреть

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

Всем, привет!

С наступающим праздником и небольшая заметка о возможной грядущей проблеме для кого-нибудь,

Как вы знаете (а может еще не в курсе), но недавно был релиз Mysql 8.4 и среди списка обновлений есть такой пункт как:

default_authentication_plugin: Deprecated in MySQL 8.0.27, and now removed. Use authentication_policy instead

Что логично ведет к отключению устаревшего плагина аутентификации mysql_native_password по умолчанию и полному отказу сервиса MySQL в принципе после обновления, если он у вас используется, а это может произойти как после запуска update и upgrade системы, так и запуск контейнера докера с mysql:latest.

В логах mysql /var/log/mysql/error.log можно увидеть ошибку, валящую СУБД:

2024-05-08T07:15:11.474311Z 0 [ERROR] [MY-000067] [Server] unknown variable 'default-authentication-plugin=mysql_native_password'.
2024-05-08T07:15:11.475302Z 0 [ERROR] [MY-010119] [Server] Aborting 

Либо при попытке подключиться к MySQL:

mysql -u root -p

выдается:

ERROR 1524 (HY000): Plugin 'mysql_native_password' is not loaded

Решить данную проблему можно, запустив MySQL с новой опцией сервера --mysql-native-password=ON или добавив директиву mysql-native-password=ON в раздел [mysqld] вашего конфигурационного файла MySQL:

#может быть здесь
nano /etc/mysql/mysql.conf.d/default-auth-override.cnf

#или здесь
nano /etc/mysql/mysql.conf.d/mysqld.cnf

открыв файл вы увидите что-то типа:

# This file is automatically generated by MySQL Maintainer Scripts
[mysqld]
default-authentication-plugin = mysql_native_password

приводим его к виду:

# This file is automatically generated by MySQL Maintainer Scripts
[mysqld]
mysql-native-password=ON

и перегружаем или стартуем mysql: service mysql start или service mysql restart

в докере меняем соотвественно команду c :

command: ["mysqld", "--default-authentication-plugin=mysql_native_password"]

на

command: ["mysqld", "--mysql-native-password=ON"]

ну или в любом другом месте где используется default-authentication-plugin=mysql_native_password на mysql-native-password=ON.

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

Всем доброго дня!

В предыдущем посте с ошибкой unknown variable default-authentication-plugin=mysql_native_password мы смягчили последствия обновления до последней версии MySQL 8.4.

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

Например здесь можно узнать что теперь по-умолчанию в MySQL плагин аутентификации является caching_sha2_password. MySQL предоставляет два плагина аутентификации, которые реализуют хеширование SHA-256 для паролей учетных записей пользователей:

* sha256_password(устарело): реализует базовую аутентификацию SHA-256. Устарел и может быть удален. Не используйте этот плагин аутентификации.

* caching_sha2_password: реализует аутентификацию SHA-256 (как и sha256_password), но использует кэширование на стороне сервера для повышения производительности и имеет дополнительные функции для более широкого применения.

Решение - обновить старые пароли с помощью caching_sha2_password

Перед всеми операциями советую сделать резервную копию базы данных

Итак, первым делом надо вывести список пользователей, использующих плагин mysql_native_password, делаем запрос в MySQL (не важно какой клиент для подключения к MySQL вы используете):

mysql> SELECT user, host, plugin from mysql.user WHERE plugin="mysql_native_password";

Результат будет примерно такой:

+------------------+-----------+-----------------------+
| user             | host      | plugin                |
+------------------+-----------+-----------------------+
| mysql.infoschema | localhost | caching_sha2_password |
| mysql.session    | localhost | mysql_native_password |
| mysql.sys        | localhost | mysql_native_password |
| root             | localhost | caching_sha2_password |
| mukhin           | localhost | mysql_native_password |
+------------------+-----------+-----------------------+
5 rows in set (0.00 sec)

Поскольку caching_sha2_password это новый плагин аутентификации по умолчанию в MySQL 8.x, нам не нужно переопределять метод шифрования пароля дополнительной директивой или флагом. Единственное требование - заново создать/обновить пользователей базы данных с паролем.

Для этого надо будет сделать запрос по шаблону, для каждого пользователя, использующего старый mysql_native_password:

ALTER USER "%user%"@"%host%" IDENTIFIED WITH caching_sha2_password BY "%password%";

Например, чтобы обновить пользователя mukhin на хосту localhost:

ALTER USER "mukhin"@"localhost" IDENTIFIED WITH caching_sha2_password BY "its_not_my_really_password";

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

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

sudo nano /etc/mysql/mysql.conf.d/default-auth-override.cnf

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

# This file is automatically generated by MySQL Maintainer Scripts
[mysqld]
#mysql-native-password=ON

а в докере поубирать упоминание с установкой дефолтного плагина аутентификации:

"--default-authentication-plugin=mysql_native_password"

Делаем рестарт сервиса MySQL:

sudo service mysql restart

и не должны получить ошибок :)

Если вдруг вы удалите или закомментируете директиву #mysql-native-password=ON, а пароль забудете обновить с помощью caching_sha2_password и приложение перестанет работать, вы всегда можете вернуть или расскомментировать конфиг назад и попытаться сделать это снова.

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

Сегодня пятница, 24 мая и возможность поделиться новостью об успешном #RFC - Создание экземпляров класса без дополнительных круглых скобок от Валентина Удальцова, которого вы знаете как автора канала Пых, а так же активного участника русскоязычного PHP-комьюнити.

Данная статья у меня висела в черновиках пару недель еще с 10 мая наверное, голосование шло оптимистично бодро, но конечно все что угодно можно было ожидать от голосующих, и на текущий момент "25 - за" и "4 - против" - я думаю результат понятен)

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

$request = (new Request())->withMethod('GET')

в противном же случае мы получим синтаксическую ошибку:

// PHP Parse error: syntax error, unexpected token "->"
$request = new Request()->withMethod('GET');

Теперь же в PHP 8.4 мы сможем писать именно так, без дополнительных скобок вокруг new выражения:

new MyClass()->method()

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

Например, если использовать метод AAAS (Actions as a Service), т.е. вместо одного большого класса как сервис, много классов, каждый из которых может быть независимой, самостоятельной единицей (привет маниакальное использование SOLID), написание кода может вылиться в такой вид:

$user = (new UserFind())(new UserFindRequest($request))

Много скобочек, не правда ли,
тут конечно можно пенять сам себе Буратино, потому что в классах вместо _ _invoke(), можно использовать что-то более человекочитаемое, типа handle, run и другие методы, несущие смысл чего-то там запуска, типа:

$user = (new UserFind)->handle(new UserFindRequest($request))

Но опять же, дело вкуса, в любом случае уменьшение скобок в синтаксисе, по-моему мнению принесет пользу. Кто-то возможно будет не согласен, как люди, которые высказываются о возможных проблемах в externals и PR, но опять же это только начало, и в будущем возможны другие RFC, исправляющие их,

кстати, по-поводу упразднения оператора new - пока это невозможно в рамках этого RFC, Валентин упомянул это:

Некоторые языки, такие как Котлин, позволяют создавать экземпляры классов с помощью выражения MyClass(). Опустить ключевое слово new в PHP на данный момент невозможно, поскольку классы и функции могут иметь одно и то же имя (в Котлине это невозможно ). И чтобы добиться этого в PHP, нам следует сначала отказаться от объявления функций и классов с одинаковыми именами.

Можно порадоваться и поздравить @vudaltsov за первый и успешный RFC!

Доброе утро!

Или не доброе, учитывая последние новости, пока мы спали, Докер заблокировал доступ странам, попавшим под санкции.
В статье на Хабре уже идет активное обсуждение решения проблемы, логичным выходом из ситуации - указание проксей/зеркал:

Создайте или добавьте в конфиг демона докера /etc/docker/daemon.json директиву registry-mirrors:

{
    "registry-mirrors": ["https://mirror.gcr.io"]
}

или любое другое зеркало из списка:

- https://huecker.io
- https://daocloud.io
- https://registry.docker-cn.com

Перегрузите докер и проверьте зеркала:

service docker restart
docker info

Вывод, что-то типа:

...
 Registry Mirrors:
  https://mirror.gcr.io/
 Live Restore Enabled: false

Добрый вечер!

Теперь уж вправду добрый,

Вcе успели настроить зеркала и прокси в #докере?
Наверное даже не все успели обойти запрет, как внезапно https://hub.docker.com стал вновь доступен из России

Всем доброго дня!

Незаметно вышел очередной инновационный релиз MySQL 9.0, по уже устоявшейся стратегии изменений не так уж и много, итак что имеем в итоге:

1. Сохранение вывода JSON из EXPLAIN ANALYZE INTO. Теперь поддерживается сохранение выходных данных JSON из EXPLAIN ANALYZE в пользовательскую переменную с использованием синтаксиса:

EXPLAIN ANALYZE FORMAT=JSON INTO @variable select_stmt

Переменная может быть впоследствии использована как аргумент для работы с JSON.

2. Начиная с MySQL 9.0.0, можно подготовить следующие операторы:
- CREATE EVENT
- ALTER EVENT
- DROP EVENT
в виде параметризованных запросов внутри хранимых процедур с помощью PREPARE и EXECUTE, пример:

delimiter |

CREATE PROCEDURE sp(n INT)
BEGIN
  SET @s1 = "CREATE EVENT e ON SCHEDULE EVERY ";
  SET @s2 = " SECOND
       STARTS CURRENT_TIMESTAMP + INTERVAL 10 SECOND
       ENDS CURRENT_TIMESTAMP + INTERVAL 2 MINUTE
       ON COMPLETION PRESERVE
       DO
       INSERT INTO d.t VALUES ROW(NULL, NOW(), FLOOR(RAND()*100))";
  
  SET @s = CONCAT(@s1, n, @s2);
  PREPARE ps FROM @s;
  EXECUTE ps;
  DEALLOCATE PREPARE ps;
END |

delimiter ;

3. MySQL 9.0 добавляет две новые таблицы, которые предоставляют информацию о системных переменных сервера:

Таблица variables_metadata содержит общую информацию о системных переменных. Эта информация включает имя, область действия, тип, диапазон (где применимо) и описание каждой системной переменной, распознаваемой сервером MySQL. Два столбца в этой таблице ( MIN_VALUE и MAX_VALUE) предназначены для замены устаревших столбцов таблицы variables_info.

В таблице global_variable_attributes представлена ​​информация о парах атрибут-значение, назначенных сервером глобальным системным переменным, таких как например offline_mode или read_only.

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

4. Столбцы таблицы variables_info MIN_VALUE и MAX_VALUE теперь устарели и могут быть удалены в будущем. Вместо этого используйте столбцы таблицы variables_metadata которые имеют те же названия.

5. Ну и самое главное, что скорее всего повлекло за собой увеличение мажорной версии:

Плагин аутентификации mysql_native_password, ранее устаревший в MySQL 8.x, был удален. Теперь сервер отклоняет запросы аутентификации mysql_native от старых клиентов, которые не имеют функции CLIENT_PLUGIN_AUTH.

В связи с этим изменением также были удалены следующие параметры и переменные сервера:

- Серверный параметр --mysql-native-password
- Серверный параметр --mysql-native-password-proxy-users
- Системная переменная сервера default_authentication_plugin

Привет!

Кстати, не успели мы оправиться после блокировки докер хаба, как подъехала новая в виде блокировки репозитория ondrej/php на packages.sury.org от самого автора:
Тут можно почитать его точку зрения https://github.com/oerdnj/deb.sury.org/issues/2155 по геоблокировке.

Вкратце, он заблокировал доступ пользователем из РФ, пока только к тем репозиториям, к которым у него есть доступ.

Не сказать что это блокировка вызовет большую проблему нежели блокировка докер хаба, но все же некоторые неудобства несет, те же мануалы по установке PHP на Debian/Ubuntu будут немного "барахлить" в случае установки на Debian, так то все же репозитории Ondrej'а были удобны и своевременно обновляемые.

Пока остаётся использовать стандартные пакеты php в ОС, хоть, конечно с небольшим отставанием.

Так же остаётся вариант контейнера докера с нужной версией php.

Ну и опять же зеркала того же https://mirror.yandex.ru скорее всего помогут обойти блокировку,

Кстати на Ubuntu пока проблему блокировки не наблюдаю, благо что заблокировать launchpad.net у него не получится.

Никто пока не столкнулся с этим?

Всем, доброй пятницы!

Так ну "лед тронулся", график релизов PHP 8.4 немного сместился, Альфу 1 должны были выкатить только вчера 4 июля (хотя на самом деле 2 июля уже был ее релиз):

Запустил Альфу,

- "пощупал" функции array_find, array_find_key, array_any, array_all - достаточно удобно, про них кстати надо будет написать еще
- хуки пока не работают
- не получилось сходу запустить request_parse_body,
- зато Создание без скобочек от @vudaltsov работает без нареканий)

ждем остальные релизы!

Всем, привет!

Вы меня, наверное потеряли, но я нашелся и готов рассказать кое-что :) В общем:

- Сегодня 7 ноября последний релиз кандидат PHP 8.4 (затеган он был уже пару дней назад, ну ок)

- Актуализировал список всех фич PHP 8.4 на сегодня, включая Lazy objects, напомню ленивая инициализация или отложенная инициализация - распространенный шаблон, используемый фреймворками для создания прокси-объектов, ленивая загрузка которых используется в компонентах внедрения зависимостей для предоставления ленивых сервисов, которые полностью инициализируются только при необходимости. Некоторые ORM делают свои сущности ленивыми, позволяя объектам гидратировать себя из базы данных только при обращении.

Вот и PHP 8.4 в этом RFC позволит нам создавать ленивые объекты:

class MyClass
{
    public function __construct(private int $foo)
    {
        // Здесь сложная логика инициализации
    }
 
    // ...
}
 
$initializer = static function (MyClass $ghost): void {
    $ghost->__construct(123);
};
 
$reflector = new ReflectionClass(MyClass::class);
$object = $reflector->newLazyGhost($initializer);
// на этом этапе $object - ленивый призрачный объект

//Для создания ленивого прокси необходимо использовать метод newLazyProxy()

$initializer = static function (MyClass $proxy): MyClass {
    return new MyClass(123);
};
 
$reflector = new ReflectionClass(MyClass::class);
$object = $reflector->newLazyProxy($initializer);

так же Ассиметричную видимость свойств, функции для работы с массивом array_find, array_find_key, array_any, array_all, новые функции mb_ucfirst и mb_lcfirst, небольшие дополнения с деприкейтами типа "Неявные типы, допускающих NULL ", "Вызов session_set_save_handler() с более чем 2 аргументами" и константой E_STRICT.

- Как уже запостил @vudaltsov в посте Пыха о том что действительно следующая версия PHP будет PHP 8.5, а не как все ожидали 9.0 (на просторах интернета я уже видел статьи что нового в php 9.0 😁) и в UPGRADING уже пошли первые изменения, следить за которыми можно в статье PHP 8.5 , так сказать продолжаем в том же духе.

- Напоминаю что вчера у Валентина прошел лайв кодинг добавления поддержки PHP 8.4 в Symfony PropertyInfo https://youtu.be/LjJtb-kFYZg, что полезно будет посмотреть, хоть вывод неутешительный на данный момент 😁 ну, а завтра 8 ноября на канале Пыха пройдет Пыхап, для всех желающих посмотреть.

В отпуске пропускаю все самое интересное 😄

Зарелизился PhpStan 2.0 ( уже и первый фикс в виде 2.0.1)!

Из явных фишек можно отметить:

- Новый уровень 10.

Для хардкорщиков максимального уровня! Ранее 9 уровень показал, что использование mixed в вашем коде на самом деле совсем не безопасно, и с этим надо что-то делать. Пока у него есть некоторые слепые пятна, и он все еще допускает некоторые ошибки. Внутри себя он называется checkExplicitMixed. Это означает, что он будет сообщать об ошибках для явно типизированных mixed значений в вашем коде.

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

/** @param list<int> $listOfIntegers */
public function doFoo(array $listOfIntegers): void
{
}

- Оптимизация потребление памяти + увеличена производительность работы

Была уменьшена прожорливость PhpStan и улучшена производительность, как в свое время это произошло с Composer с перехода 1 на 2 версию и это радует!

- Улучшена работа с кэширование и использования дискового пространства

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

Ну и первое что стоит в планах после релиза - это добавление поддержки PHP 8.4. Можно ожидать, что она будет добавлена до конца 2024 года.

Каждый раз поражаюсь титанической работой Алексея и Павла, если вы что-то упустили, то спокойно можете наверстать упущенное, прочитав статью.

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

Являются ли exit() (или его псевдоним die()) функцией в PHP?

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

Ну и как мы знаем в сравнении с теми же "фейковыми-функциями-собратьями" типа require(), include(), isset(), empty(), print(), echo(), unset(), list() и т.д. которые подразумевают передачу выражения (или чего-то другого) в скобки, или даже без них, точнее скобки там воспринимаются как приоритет в тех же выражениях, то в exit можно не писать скобки.

Для совместимости, RFC позволит синтаксису все так же продолжать опускать скобки, то есть в принципе ничего не изменится, по сути это будет функция с возможностью не передавать аргумент и опускать скобки после:

exit(string|int $status = 0): never {}

exit; //все так же валидно

Но чем еще примечательно это изменение, что учитывая направление, который выбрал PHP: быть более строже и предсказуемее, то есть вероятность, что в каком-нибудь PHP 8.5 объявят устаревшим вызов функции exit без скобок, а в следующей мажорной версии 9 вызов syntax error,
а так было удобно экономить время на опускании скобочек! 😁

Залетаем на стрим,
https://www.youtube.com/live/UgNAvNmAizk?si=cbQFBBCYJoM6KoII

Доброй ночи и С Новым Годом!

Желаю всем в новом 2025 году счастья и благополучия!

Достижение поставленных целей, поменьше багов и перейти поскорей на PHP 8.4 🐘

Желаю быть оптимистично настроенными, не выгорать и не терять бодрости духа и ... слонов, как я, куда-то задевал своего, поэтому фоточка с прошлого года 😄

С Новым Годом, друзья!