Immortal_pony

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

В первом случае выкинуть весь этот ад и делать по-человечески, передавая переменные в конструктор/методы в качестве параметров.

Перед тем как писать обработчик, надо сначала понять, а зачем он нужен.
Потому что вот эта вот функция - она совершенно бессмысленная.
Вся "обработка", которой она занимается - это добавляет бессмысленные фразы типа "Error_message" к тому что РНР выведет и так.

Обработчик ошибок не должен заниматься удалением файлов. Обработчик вступает в дело, когда ничего исправить уже нельзя, и всё что остаётся - это показать пользователю страницу с извинениями и корректным НТТР кодом. Пример можно взять здесь: https://phpdelusions.net/articles/error_reporting

А вот обрабатывать ошибки надо с помощью оператора try catch
Если надо откатить транзакцию, то всю её целиком надо поместить внутрь try catch, в котором ловить ВСЕ ошибки, то есть \Throwable и после этого скорее всего добавить throw с тем же исключением, поскольку вряд ли при ошибке БД имеет смысл продолжать работу скрипта. Но зависит от обстоятельств.

Если надо удалить файлы, то опять же, заключить в try catch загрузку файлов, то тут просто заключить в try catch, всё почистить и написать какое-нибудь сообщение пользователю.

Нет, не так.
В 7 версии: т.к. сравниваем число и строку, то преобразовываем строку в число (int)"wow" = 0, и сравниваем результат: 0 и 0 - true.
В 8 версии: т.к. сравниваем число и строку, то проверяем содержит ли строка число, в данном случае - нет, не содержит (что-то вроде is_numeric("wow")), а раз не содержит - false.

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

Сокращалка, удобная для indexOf(), который возвращает -1 если не найдено, или индекс от 0 и больше.

Для логики приложения часто бывает нужно узнать только, найдено или нет: т.е. -1 или иное значение. Можно просто сравнивать if (a.indexOf(b) > -1) { /* найдено! */ } но иногда хочется короче.

Битовый оператор НЕ ~ хорош тем, что выделяет -1: только -1 с этим оператором даст 0. Прочие числа дадут какое-то ненулевое значение.

~(-1) === 0

Остаётся привести значение из численного в булево. Для этого два воскл. знака — два логических НЕ.

• для варианта «найдено» из числа от 0 и больше получилось тоже ненулевое число, и !! даст true
  
• для варианта «не найдено» из -1 получится уникальный 0, и !!0 вернёт false
  

<?php
class A
{
	protected $sql = null;
	
	public function setSQL()
    {
        $this->sql = "SELECT * FROM users WHERE id = 123";
        return $this;
    }
	
	public function getSQL()
    {
        return $this->sql;
    }
}

class B extends A
{
    public function addSQL()
    {
        $this->sql .= " AND name = 'Alex'";
		
		return $this;
    }
}
$a = new A();
$b = new B();

echo $b->setSQL()->addSQL()->getSQL();

PHP class test

1. нужна таблица - календарь, либо сгенерированный набор дат
2. либо к календарю надо сделать left join вашей таблицы, либо к вашей таблице надо сделать right join календаря.

SQL join в примерах с описанием

в результате получится:

select cal.cal_date, count(person)
  from some_table st
  right join (
  -- генерируем календарь - набор дат
    select *
      from (
        select adddate('1970-01-01',t4*10000 + t3*1000 + t2*100 + t1*10 + t0) cal_date
          from
            (select 0 t0 union select 1 union select 2 union select 3 union select 4 union select 5 union select 6 union select 7 union select 8 union select 9) t0,
            (select 0 t1 union select 1 union select 2 union select 3 union select 4 union select 5 union select 6 union select 7 union select 8 union select 9) t1,
            (select 0 t2 union select 1 union select 2 union select 3 union select 4 union select 5 union select 6 union select 7 union select 8 union select 9) t2,
            (select 0 t3 union select 1 union select 2 union select 3 union select 4 union select 5 union select 6 union select 7 union select 8 union select 9) t3,
            (select 0 t4 union select 1 union select 2 union select 3 union select 4 union select 5 union select 6 union select 7 union select 8 union select 9) t4
      ) v
      where cal_date between '2021-11-01' and '2021-11-30'
  ) cal on cal.cal_date = st.date_field
  group by cal.cal_date

в MariaDB есть Sequence Storage Engine, но до MariaDB 10.0 , он поставлялся в виде динамической плагина, начиная с MariaDB 10.1 , движок Sequence устанавливается по умолчанию. Используя его можно генерировать список дат (календарь) следующим образом:

SELECT '2021-11-01' + INTERVAL seq DAY FROM seq_0_to_29;

а запрос будет соответственно:

select cal.cal_date, count(person)
  from some_table st
  right join (
  -- генерируем календарь - набор дат
    SELECT '2021-11-01' + INTERVAL seq DAY as cal_date FROM seq_0_to_29
  ) cal on cal.cal_date = st.date_field
  group by cal.cal_date
;

см. пример работы на dbfiddle.uk

и если person добавить в группировку - пример

Вопрос: как после обновления страницы сохранить эти данные, мол купон такой-то активирован. У меня код купона, его скидка и статус пишутся в массив $_SESSION.

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

<?php
$str = "http://site.com/index.php?id=20";
$str = parse_url($str, PHP_URL_QUERY);
parse_str($str, $result);

Output:

array(1) {
  ["id"]=>
  string(2) "20"
}

Достаточно держать в памяти, что есть три варианта ответа - да/нет/что угодно (true/false/null), и тут же все станет понятно:

1) Да. "что угодно" = "что-то конкретное" дает "что угодно, потому-то слева может быть и правое значение, и любое другое.
2) Нет. См. п.1.
3) Нельзя, потому что п.1.

То есть, можно представить себе, что в null может быть любое значение - как равное конкретному, с которым мы сравниваем, так и не равное. Поэтому результат тоже может быть любым.

Собственно, этого мнемонического правила вполне достаточно, чтобы не делать ошибок при запросах к БД.

UPD: или же можно трактовать null как функцию random() - так еще понятней.
1) 1 = random()? А кто его знает - может, равно, а может, и нет... то есть ответ рандомный.
2) random() это false? Может, да, а может, и нет... в общем, все тот же рандом.
3) Из вышеизложенного вытекает, что любое сравнение какого-то конкретного значения с рандомным дает рандомный результат. А операторы IS NULL/IS NOT NULL как раз работают как "это рандом?" и "это не рандом?" - поэтому для работы с null надо использовать именно их.

1) При использовании операторов =, <, >, <> - да
2) Нет. Но при этом он не является true, т.е. при использовании в WHERE или JOIN условие с ним сработает как ложное. Ну и вне БД, например, в PHP и других слабо типизированных языках он легко превращается в false
3) Странный вопрос какой-то, перевернутый. Операторы IS NULL/IS NOT NULL придумали потому, что сравнение с NULL обычными операторами работает не так, как все привыкли. Вообще, в SQL троичная логика (на примере =):

=     | TRUE    FALSE   NULL
________________________________
TRUE  | TRUE    FALSE   NULL
FALSE | FALSE   TRUE    NULL
NULL  | NULL    NULL    NULL

Функция mysqli_real_escape_string() должна вызываться с двумя параметрами

PS.: ваш php стар как г..но мамонта