alexalexes

Можно удалить id из элемента массива (точнее из копии элемента), оставшиеся свойства засериализовать, от сериализации найти md5 хэш - это и будет ориентир для уникальности элемента.

$out_array = [];
foreach($donates as $donate)
{
   $donate_copy =  $donate; // копируем элемент массива
   unset( $donate_copy->id); // удаляем уникальное свойство из элемента
   $key = md5(serialize($donate_copy)); // получаем уникальный ключ по содержанию остальных свойств
   $out_array[$key] =  $donate; // добавляем исходный элемент в новый массив по уникальному ключу
}

Проблема такой защиты от DDOS на PHP в том, что атакующий пользователь все же успевает запустить скрипт на PHP, хоть и с минимальными ресурсами. Если у вас архитектура серверного приложения построена не на event loop (как правило, обычные сайты), то для каждого запущенного скрипта выделяется отдельный системный процесс - не самый экономный вариант работы PHP сервера.
Поэтому, нерадивых пользователей лучше отшивать как можно раньше.
Идентифицировать плохого пользователя вы можете и на PHP, а вот работу по его отсечению лучше доверить системе, которая стоит перед PHP сервером. Это может быть и Apache, и Nginx.
Определяете пользователя и добавляете его в файл черного списка по IP, user agent или cookie, который будет обрабатывать настроенный Apache или Nginx.
Лучше конечно, чтобы это был отдельный файрвол, еще лучше - на железке (но в условиях арендуемого хостинга такое маловероятно).

Сморите по регламенту сайта, каков официальный срок действия пароля (если нет такого, то определяетесь с этим).
1. Создаете в базе новое поле под bcrypt пароль, а также дату смены пароля.
2. Делаете авторизацию использующую как md5, так и bcrypt если последняя задана.
3. Разрабатываете систему оповещения для пользователей, у которых истек срок действия пароля.
4. Ставите дату пароля такой же как и дату регистрации пользователя, если не использовали это раньше.
5. При смене пароля пишете только bcrypt, md5 не используете, лучше сделать поле-флаг, что пользователь менял пароль уже по новой технологии.
В течение пару периодов срока действия пароля будет постепенный переход на новый хэш.
Активных пользователей придется как-то стимулировать, чтобы сменили пароль.
Неактивные будут восстанавливать пароль, например, по email, если они вернутся на ваш ресурс и вы решите когда-нибудь больше не поддерживать md5 хэш.
PS: Принудительно заставлять менять пароль пользователю - это не самый оптимальный вариант. Заменяйте хэш пароля по новому алгоритму, как только получили от пользователя исходный пароль, который валиден по старому алгоритму, например, в процессе авторизации.

Обрабатывать пришедшие данные налету или перезаписывать в файлы?
Зависит от того, хватает ли выделенной оперативной памяти PHP скрипту если попытаться сформировать тело $xml_post_string с бинарником. Если размер файлов, перекодированных в base64 в большинстве случаев заведомо меньше чем возможности ОЗУ скрипта, то смело можете налету обрабатывать.
Если нет, то принимаете все меры предосторожности, чтобы скрипт не хапнул лишних данных, вызывая переполнение выделенной ОЗУ, (если такая ситуация случится, то скрипт умрет молча, не выдав исключение). Записываете временный файл из $_FILES, порционно формируете другой временный файл с форматом $xml_post_string. Потом присоединяете данные этого файла к curl и отправляете.

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

<?foreach ($arResult["PARTNERS"] as $partners) {if($partners['NAME']=='test')continue;?>

Если вы видите, что пишите один и тот же код повторно, значит, пора общую часть кода выносить в функцию или метод. И эта ситуация может случиться не обязательно в модуле валидации.
Пишите базовые функции:
а) проверка обычной строки на минимум и максимум по длине;
б) проверка радиокнопки;
в) проверка чекбокса;
г) выпадающего списка.
Все остальные функции будут вызывать что-то из этого базиса и допроверять свойства поля, например, email вы проверяете функцией А на корректность длины, а потом валидность по регулярке. Если длина не та, то предупреждения выведете из функции А, а регулярку не станете проверять, а если косячит по регулярке, то уже будет предупреждение, что email некорректен.

Если просто нужен флаг, что товар в корзине, то достаточно этого запроса.

SELECT p.*,
            case
               when exists(SELECT 1 from cart c where c.products_id = p.id)
               then 1
               else 0
            end is_exists_in_cart -- есть товар к корзине? 0 - нет, 1 - есть
FROM table_products p

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

SELECT p.*, c.*
FROM table_products p
left join cart c on c.products_id = p.id

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

Приводите склеенную строку $date_time.$time и параметр функции STR_TO_DATE к одинаковому формату времени.
Делаете с помощью bind_param функций привязку склеенной строки на месте знака вопроса.

insert into your_table (your_field)
values (  STR_TO_DATE(?, '%d.%m.%Y %h:%i')  )

Выполняете этот запрос, он вставит в таблице your_table свойство your_field в формате datetime.
Дополнено:

$sth = $dbh->prepare("insert into your_table (your_field)
values (  STR_TO_DATE(:your_datetime_string, '%d.%m.%Y %h:%i')  )");
$sth->bindParam(':your_datetime_string', $date_time.' '.$time, PDO::PARAM_STR);
$sth->execute();

Ссылку на подключение к базе $dbh подготавливаете согласно PDO.

Проблема обойти невалидное название свойства (так как используется дефис).
Используем магию именования свойства класса через переменную.

$recaptcha_property_name = 'error-codes';
echo $recaptcha->$recaptcha_property_name[0];

А в чем сложность?
Берем таблицу товаров (goods), подключаем таблицу категорий (category), по parent_id получаем товары одной категории родителя.

select distinct g.*
from goods g
join category c on c.id = g.category_id  
                        and c.parent_id = 34

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

select distinct g.*
from goods g
join good_category_hold gch on g.id = gch.good_id
join category c on c.id = gch.category_id
                                and c.parent_id = 34

Фильтруете массив:
$selected_items = array_filter($inp_array, function($item){return $item['status'] == 0;});