Дмитрий Энтелис, я описал подходы к решению проблемы в прицнипе. В данном случае предпочтительнее первый метод и я это также отметил. Что использовать и в каком конкретном случае - отдельный вопрос.
Максим Золотой, потому что использование глобальных переменных порождает неявные зависимости и затрудняет отладку - любая часть приложения имеет возможность изменить данные в глобальной переменной и это может быть проблемой.
Спасибо, под валидацией вы имеете ввиду real escape string и strip tags?
real_escape_string - нет. htmlspecialchars - можно использовать для санитизации, но не бездумно. strip_tags - можно использовать для санитизации, но не бездумно.
Каждый входящий парметр должен быть провалидирвован и очищен своим собственным образом. Из некотрых полей стоит вырезать тэги, а из некоторых - совсем нет.
Например, если вы ожидаете на вход только значения "email" или "sms", то вам надо убедиться, что пришло одно из двух этих значений, а не просто какая-то строка. Для этого есть много удобных библиотек. Например, Aura.Filter
ничего очищать не надо - подготовленные запросы справляются со своей задачей.
Vasiliy_M, Никто и никогда не даст вам 100% гарантии безопасности. Не порите чушь с умным видом.
Входящие от пользователя параметры надо проверять, проверять и еще раз проверять. После этого можно еще несколько раз проверить.
Да, задача sql-инъекции с подготовленными выражениями стала на порядок сложнее, но это не значит, что нет ничего невозможного и надо пренебрегать элементарными мерами безопасности.
И, да, есть много других векоторов атак, связанных с сохранением данных в базе, не являющихся именно sql-инъекциями.
В Wordpress планировщик построен вокруг открытия web-страницы. Пришел пользователь, открыл страницу, WP проверил, нет ли у него задач и выполнил их.
Естественно, если никто на сайт не будет заходить, то события не сработают. Или сработают, но не в тот момент. Поэтому обычно файл wp-cron.php вызывают через системный планировщик, чтобы таких накладок не происходило.
return in_array($number, range(1,9));