pantsarny

Именно для этого существует usort - чтобы отсортировать массив по значениям используя пользовательскую функцию. Если хотите сортировать не по значениям - есть uksort.

А как именно вы отсортировать хотите, я не очень понял. Но общий код такой:

$array = [3, 2, 5, 6, 1];

usort($array, function ($a, $b) {
    if ($a == $b) {
        return 0;
    }
    return ($a < $b) ? -1 : 1;
    //Или ваша любая функция сравнения значений.
});

wp all import

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

'http'=> [
    'header'=>"Cookie: beget=begetok; foo=bar;"
  ]

Этих трех мер будет достаточно:
1) Ограничить частоту регистраций с одного IP адреса.
2) Ограничить частоту регистрации для одного отпечатка.
3) Использовать Google Recaptcha v3 для определения ботов.

Суть в том, что ООП - это подход для того, чтобы уменьшить сложность СЛОЖНЫХ программ.
Поэтому когда вы берете простой пример с тремя птичками или "cat says meow, doggy says bark", то разница не видна. В особо тяжелых случаях ООП код будет даже казаться более сложным, чем обычный if или switch.

Представьте себе код какой-нибудь игры, масштаба warcraft, например. Там где есть несколько десятков разновидностей юнитов - всякие эльфы, орки, люди, палладины, лучники, снайперы, драконы, катапульты...
Все они основаны на одном классе Unit, у всех есть много общего кода - методы получения координат, получение урона, отображение хелсбара, команды типа "держать позицию", "патрулировать" "атаковать"...
При этом есть и различия в поведении - разная скорость, разные показатели урона, здоровья, брони, размера. Даже алгоритмы поиска пути могут отличаться, т.к. часть юнитов могут пройти в узком проходе, другие не могут, а кто-то вообще может летать,

И если написать это на ООП, то у вас будет класс Unit с общими методами, и несколько десятков классов
Paladin extends Unit
GoblinTechies extends Unit
GoldenDragon extends Unit
в каждом из которых учтены особенности конкретного типа юнитов.

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

IMHO, там где понятно по тайпхинтам, смысла в phpdoc нету. А вот там где непонятно

/**
 * @return array{uid: string, name: string, isAdmin: bool}
 * @throws AuthenticationException on authentication error
 */
private static function authenticate(string $login, string $password): array
{
}

Название параметра должно состоять минимум из одного печатного символа (ASCII-коды от 33 до 126). Регистр символов в названиях не имеет значения. Заголовки с неизвестными именами должны игнорироваться. После названия сразу должен следовать символ двоеточия.

Wiki

Символы ASCII с кодом от 33 до 126 — в этом списке нижнего подчеркивания нет. snake_case не поддерживается.

UPD: Всё же в данном списке — нижнее подчеркивание есть под №95:

Но поделились ссылкой на документацию nginx, с разделом Missing (disappearing) HTTP Headers, который гласит: «NGINX will silently drop HTTP headers with underscores (which are perfectly valid according to the HTTP standard». И изменение snake_case мою проблему решило.

preg_match('/csrftoken=([^;]+)/', $login, $matches);
$csrftoken = $matches[1];

Кхм?

PHP 8.0

If both operands are numeric strings, or one operand is a number and the other one is a numeric string, then the comparison is done numerically.

Более ранние версии PHP:

If a string is compared to a number or a numeric string then the string was converted to a number before performing the comparison.

То есть, когда вы в 7.4 сравниваете строку с числом, то строка в любом случае приводится к числу. В 8.0, при сравнении нечисловой строки с числом, число будет приведено к строке.
А дальше у вас, похоже, проблема XY. Вам надо искать не "как сравнить через ==", а как решить исходную задачу, для которой нужно такое сравнение.

"WHERE CONCAT(',', fieldName, ',') LIKE CONCAT('%,' " + тут искомое значение +  "',%')"

Идея куда думать.

Но это с учетом ;)

Сейчас вообще не важно то, на сколько хорошо или плохо написан запрос