krypt3r

Проще всего сделать это через Docker: https://hub.docker.com/layers/library/php/5.4-fpm/...

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

$type = $JSON->{message}->{text} ? 'text' : 'photo';

find умеет искать и по возрасту, и по wildcard (в т.ч. с отрицанием), руководств валом.
!-name "*-01-*.zip"
Самое простое, что видел по обучению регуляркам - внезапно, помощь LibreOffice (там это естественный язык поиска).

Рекомендую начать отсюда.
https://postgrespro.ru/education/courses/DBA1

$dt = new DateTime;
$formatter = new IntlDateFormatter(
    'ru_RU',
    IntlDateFormatter::LONG,
    IntlDateFormatter::LONG
);
$formatter->setPattern('d MMMM yyyy');
echo $formatter->format($dt);
// 18 января 2023

<?php if ( is_front_page() ) : ?>
         <div class="header-page clearfix">
              <h2 class="name-page">Акции</h2><a href="#" class="cart-btn">
              <div class="cart-btn__img"><img src=" <?php echo esc_url( get_template_directory_uri() );?>/img/shopping-bag.svg" alt=""></div>
              <div class="cart-btn__text">Ваша корзина</div></a>
         </div>
<?php else: ?>
        <div>AAAAAAAAAAAAAAAA</div>
<?php endif; ?>

Проблема в том, что приходит невалидный json, а конкретно лишняя последняя запятая. Убери ее и json_decode отработает нормально
preg_replace('/("beauty":\s\d),/', $1, $previes)

контроллеры умеют сильно битые сектора убирать из обслуживания, но делают это лишь тогда когда его заставят

Это всё сказки, повествующие о программах, которые переразмечают бедблоки. На деле, если вы заглянете в спецификацию AHCI, то не обнаружите там ничего подобного. Нет таких команд в протоколе. Контроллер должен сам об этом позаботится. Если на диске появились бедблоки (не просто запись в S.M.A.R.T., а именно нечитаемые области), то это означает лишь то, что резервная область закончена и переразмечать сектора уже некуда.

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

Но если вас не смущает скорая смерть диска и потеря данных, то да, такие файловые системы есть. Например ext4. mkfs.ext4 имеет параметр -l, после которого можно указать файл, сгенерированный программой badblocks. Так же mkfs.ext4 может сама проверить диск перед созданием файловой системы. Битые сектора будут игнорироваться.

Если вначале раздела много битых секторов, то файловая система не сможет быть создана, т.к. драйвер файловой системы ожидает расположение суперблока в строго определённом месте диска. В этом случае имеет смысл попробовать перенести начало раздела в другое место, урезав раздел слева.

UPD: Что бы продлить жизнь такому диску, можно определить сбойные области. Обрамить их несколькими гигабайтами (при большом объёме диска, из-за плотности записи лучше несколькими десятками) с каждой стороны. Объединить близколежащие области. Полученные диапазоны вообще не размечать. В итоге должно получится что-то вроде 200 гигабайт вначале не используемые, а затем раздел. Это позволит минимизировать количество перемещений головок над сбойной областью, что замедлит деградацию.
Но этот способ не подходит, если сбойные сектора распределены по всему объему диска.

Ох, молодежь.. :)

<?php

$string = '41feb2dbe18c02f099f84247dffbee8b';
$parts = sscanf($string, '%8s%4s%4s%4s%8s');
$result = join('-', $parts);

var_dump($result);
// string(32) "41feb2db-e18c-02f0-99f8-4247dffb"