Slava Rozhnev

Ничто не мешает использовать оконный вариант агрегатных функций. Кроме слишком старой версии СУБД, не поддерживающей оконные функции, конечно.

SELECT MIN(`min_price`) OVER () as `min_price`, 
       MAX(`max_price`) OVER () as `max_price`, 
       `item_id` as `id`
FROM `product_table` 
WHERE `id` IN (SELECT  тут запрос)

Получишь все нужные id, и в каждой строке - нужные MIN и MAX.

======================

Akina, да, версия 5.7.21 и она, я так понимаю, не поддерживает оконные функции.

SELECT t2.min_price, 
       t2.max_price, 
       t1.item_id as id
FROM product_table t1
CROSS JOIN ( SELECT MIN(min_price) AS min_price, 
             MAX(max_price) AS max_price
             FROM product_table ) t2
WHERE t1.id IN (SELECT  тут запрос)

Это очень хороший вопрос, по многим причинам.

Во-первых, очень хорошо что он сам по себе поставлен. Обычно пользователи РНР не задумываются о таких "мелочах". Но на самом деле об этом должен думать каждый программист, делающий сайты
Во-вторых, здесь мы можем видеть довольно характерный баг Апача, который действительно, почему-то не выполняет директиву ErrorDocument для 500 ошибок, полученных от РНР. Ну и вообще, завязываться на Апач во времена доминирования Нжинкса как-то не очень дальновидно.
В-третьих, как правильно заметил Stalker_RED, сделать редирект при 500 статусе (или 500 статус при редиректе) невозможно - статус может быть только один. Да это и нет смысла делать - проще сразу на месте нужную страницу и прочитать.
В-четвертых, текущий подход, прямо скажем, не очень оптимальный:
- о роботах мы позаботились, о пользователе позаботились, но надо ещё не забыть и программиста. Которому как раз сообщение об ошибке-то нужно видеть во всех подробностях!
- просто отдать нужный НТТР код недостаточно - надо бы ещё и завершить работу скрипта.
- ловить все ошибки вручную через try-catch так себе удовольствие. И код раздувает,и поведение потом быстро не поменяешь. А если в какой-то момент захочется для отладки прикрутить whoops - это придётся по всем блокам бегать?

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

В самом простом варианте это будет что-то вроде такого:

set_exception_handler(function ($e)
{
    error_log($e);
    http_response_code(500);
    if (ini_get('display_errors')) {
        echo $e;
    } else {
        include 'pages/error_500.php';
    }
});

В теории, конечно, можно заменить error handler на глобальный try-catch который оборачивает точку входа, но это менее удобно. Тем более, что для обработки фатальных ошибок нужен свой отдельный обработчик, и в итоге код обработки ошибок начинает занимать довольно значительный объем и лучше конечно его инициализацию вынести отдельно.

https://github.com/laravel/laravel
https://github.com/laravel/lumen-framework

Никак не очищать.

На самом деле этот вопрос встречается довольно часто. Вот например популярный ответ на Stack Overflow, который подробно разбирает этот распространённое заблуждение: https://stackoverflow.com/a/3126175. И основная мысль там:

Понятие такой генерализованной "очистки данных" изначально бессмысленное и вредное.

Особенно такой вот индусской функцией, которая сама по себе - пример редкого идиотизма: сначала заменяем символы < и > на HTML сущности... а потом бодро пытаемся вырезать HTML теги. Которых к этому моменту в тексте не останется ни одного!
Или функция stripcslashes, которая здесь вообще ни к селу, ни к городу. Если я хочу написать сочетание \n, то с какой стати эта функция будет заменять его на перевод строки?
Всё что можно оставить из этого безумного набора - это trim(). Да и то не всегда. Как правильно заметил Rsa97, могут быть случаи, когда лидирующие пробелы имеют значение, например, при выводе форматированного кода. Кстати, этим как раз грешит Хабр. Если запостить код с отступами, то первый будет "съеден"!

Очистка

Любая "очистка" (хотя правильнее говорить про форматирование), имеет смысл только в определённом контексте.
И поэтому "очищать" надо только адресно, строго перед использованием в том или ином конкретном случае.

Например, базе данных ни жарко, ни холодно от наличия HTML тегов.
А проблемы могут начаться только при выводе данных в HTML. Но если мы будем предотвращать эти проблемы заранее, то просто попортим кучу данных. Поэтому форматировать данные для использования в контексте отрисовки HTML следет строго перед этой отрисовкой. То есть при выводе.
Что и делают все популярные РНР шаблонизаторы автоматически.
То есть вручную колупаться с "очисткой" вообще не нужно.

Больше того, "очистка" HTML поможет данным, выводимым в яваскрипт, как мёртвому припарки. То есть опять же - всегда надо понимать, в какой именно контекст мы выводим данные, и форматировать соответствующим образом. В частности любые данные передавать в яваскрипт только через json_encode()

И таких контекстов неисчислимое множество. Например, если мы используем переменную для передачи параметров в консольный скрипт, то надо обязательно обрабатывать её через escapeshellarg(). Если в регулярку - то preg_quote(). Имя файла для инклюда из переменной (хотя так делать вообще не стоит) надо хотя бы обрабатывать через basename(). И так далее.

Валидация

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

Защита БД

И кстати, по поводу "использую pdo".
На всякий случай уточню, что само по себе использование PDO не защищает ни от каких проблем
Важно помнить, что защита - это когда в базу данных отправляется строго константная строка запроса, полностью на 100% составленная из значений, прописанных в коде РНР, и в ней не используется ни одно значение, пришедшее в код извне. Причем PDO помогает здесь только наполовину, позволяя использовать в запросе подстановки вместо самих данных.
Но при этом для всех остальных частей запроса - например имен полей - у ПДО нет никакой защиты и её надо организовывать самостоятельно. Либо проверяя по белому списку, лабо, по крайней мере, прогоняя через регулярку.

Почитайте про оптимистические блокировки.

Типичная sql инъекция.
Строки нужно экранировать, прежде чем пихать в базу.
https://www.php.net/manual/ru/mysqli.real-escape-s...

Буквальный ответ на этот вопрос, который будет полезен тем, кого привлечёт заголовок вопроса - escapeshellarg()
Все параметры, которые передаются в команды шелл, должны в обязательном порядке обрабатываться этой функцией.

Решение смешной проблемы в текущем коде - надо всего лишь использовать двойные кавычки вместо одинарных.

$fileD = escapeshellarg("https://domain.zone/files/file".date("Ymd").".zip");
exec ("wget -O todayfile.zip $fileD");

Для решения же исходной задачи, разумеется, не нужен никакой РНР. Использовать для этих целей РНР - это все равно что сначала завернуть котлету в целлофановый пакет, а потом её есть. Ну ведь wget - это уже шелловая команда, и запускать её надо напрямую.

/usr/bin/wget -O /path/todayfile.zip "https://domain.zone/files/file$(date '+%Y%m%d').zip"

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

Вариант 1 - шаблонизаторы плюс рендер на стороне сервера
Вариант 2 - RESTful API на PHP а рендер на фронте по полученным данным

Запрос обрабатывает веб-сервер, он и принимает решение что делать дальше — передать «в React» или «в WordPress». React, разумеется, запросы на /blog перехватывать не должен.