Ипатьев

Это нормально.
Ну то есть про конкретный код нельзя сказать, не видя его, но " выносить каждые пару строк в отдельную функцию" - это нормально. Куда нормальнее, чем писать всю тысячу в одной.

Рекомендую найти видео "Как писать код, который понравится вашим тестам" с первой PHPRussia. Там очень доходчиво рассказывается про то, почему надо делать простые методы. Не только для тестов. А ещё и для повторного использования и для упрощения поддержки кода. Когда надо прочитать основную логику модуля, то даже сокращение в два раза (по одному методу вместо двух строк кода) уже сильно облегчает задачу.
А если уж даже тест понял, что делает ваш код, то человек поймёт и подавно :)

Как вам написали выше - все дело в именах методов. Если они информативные, то есть если конструкция

if ($this->function_7($a) && $this->function_8($b))

читается как связный английскй текст, то mission accomplished! Функции выполняют свою роль: легче всего читать код, которого нет. Вместо того, чтобы разбирать, что делает тот или иной код, можно просто прочитать небольшой текст на английском.

В старых версиях PHP деление на ноль никакое не исключение, а обычная ошибка.
О чем ясно написано в выводимом сообщении: Warning: Division by zero in ...

Чтобы перехватывать ошибки, их надо конвертировать в исключения. В простейшем варианте

set_error_handler(function ($level, $message, $file = '', $line = 0)
{
    throw new ErrorException($message, 0, $level, $file, $line);
});

После установки такого обработчика все ошибки будут автоматически конвертироваться в исключения, и соответственно могут быть пойманы через try..catch:

Fatal error: Uncaught ErrorException: Division by zero

Мне не нравится ни тот ни другой вариант.

Сами по себе функции фильтрации - довольно странная часть языка. И нынешний отказ от FILTER_SANITIZE_STRING как раз подтверждает этот тезис. Задумка была в теории неплохая, но реализация получилась так себе. А, главное - все эти функции только насильно меняют значение переменной. Молча.
А в нормальном современном приложении принято проверять переменную на соответствие правилам и выдавать ошибку

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

Поэтому я бы взял какую-нибудь либу для валидации, вот первая же из гугля, https://github.com/rakit/validation
И нормально проверял входящие параметры.
В случае, если это пользовательский ввод, типа логина и пароля, то отдавать культурные ошибки
Если же это чисто внутренняя инфраструктура приложения, типа id из нашей же ссылки, то при наличии ошибок молча отдавал 400.

Задачка, конечно, очень смешная.
И как всегда - на арифметику

Шкала у нас нелинейная, первый шаг 100 единиц, последний - 2000.
Но при этом для вычислений мы берём не позицию шага, а его значение.
Ну и разумеется получаем то, что получаем.
250 от 3000 - это никакие не "примерно 50 единиц", а примерно 8 процентов. Вот эти 8 процентов вам и показывает.

Длина отрезка при разбивке на 5 частей будет 20%
И вот 8 от 20 как раз и составляет те самые "примерно 50" процентов длины первого отрезка :)

Выше товарищ правильно пишет про отладку.
Но отладка в обязательном порядке состоит из двух вещей:
1. Надо понимать, что делает твой код. В частности, иметь представление, какое значение каждая переменная должна иметь на каждом этапе.
2. Запускать код, выводя промежуточные результаты, и сравнивая их с ожидаемыми.

Без п.1 заниматься отладкой бессмысленно.
Именно поэтому для программиста очень важно понимать, как работает его код. Иначе он просто не сможет его отладить.

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

Во-первых, очень хорошо что он сам по себе поставлен. Обычно пользователи РНР не задумываются о таких "мелочах". Но на самом деле об этом должен думать каждый программист, делающий сайты
Во-вторых, здесь мы можем видеть довольно характерный баг Апача, который действительно, почему-то не выполняет директиву 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 который оборачивает точку входа, но это менее удобно. Тем более, что для обработки фатальных ошибок нужен свой отдельный обработчик, и в итоге код обработки ошибок начинает занимать довольно значительный объем и лучше конечно его инициализацию вынести отдельно.

$executer = debug_backtrace()[1]['function']  ?? 'direct call';

или чуть более расширенный вариант

$class = debug_backtrace()[1]['class'] ?? '';
$executer = ($class ? "$class::" : "") . (debug_backtrace()[1]['function']  ?? 'direct call');

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

На самом деле этот вопрос встречается довольно часто. Вот например популярный ответ на 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 помогает здесь только наполовину, позволяя использовать в запросе подстановки вместо самих данных.
Но при этом для всех остальных частей запроса - например имен полей - у ПДО нет никакой защиты и её надо организовывать самостоятельно. Либо проверяя по белому списку, лабо, по крайней мере, прогоняя через регулярку.

Насколько я помню по прошлому вопросу, для $allonline надо просто перед циклом написать
$allonline = 0;

А для $serversonline надо самому смотреть - что это за переменная, откуда она берется и почему у неё нет значения. Ну в смысле код надо не только бодро строчить, но иногда и читать. На предмет имеет ли вообще смысл то, что мы написали. В частности, есть ли у нас переменная, к которой мы пытаемся обратиться.

Самый тупой вариант: strpos($num, '1')-2;

Буквальный ответ на этот вопрос, который будет полезен тем, кого привлечёт заголовок вопроса - 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"

Если отбросить все фантастические версии, типа различий между операционными системами Centos и Ubuntu, то ошибка Duplicate entry '1' for key 'cb_tmp_acc_buttons.PRIMARY' при явном указании значения автоинкрементного поля в запросе может быть вызвана двумя причинами:
1. в дампе дублируются значения id
2. после установки БД уже заполнена какими-то значениями.

Оба варианта легко проверить и исправить. В первом случае обращаться к авторам программы или поправить руками, во втором - сначала очистить базу.

С кавычками же - это однозначно к авторам этой кривой программы.

Ну и самое главное - нет ни одной настройки, которая одни строки обрамляет в кавычки, а другиие - нет.

Вопрос оказался не так прост, как кажется. Действительно, в РНР нет функции, которая округляет дробные числа в меньшую сторону.
Так что остаётся только решение, предложенное Ankhena в комментариях:

floor(758.66318000*10)/10;

Так же, универсальное решение приведено в пользовательских комментариях к функции round() (я, правда, позволил себе его немного подредактировать):

function round_down($number, int $precision = 2)
{
    if  ($precision === 0) {
        return floor($number);
    }
    $fig = pow(10, $precision);
    return round(floor($number * $fig) / $fig, $precision);
}

(round() в конце на всякий случай, если вдруг деление вернет не 8, а 7.9999999, как это бывает с дробными числами)