Ипатьев

Написать нужное условие в ON

Не "два", а в каждом скрипте, который использует сессии.
поэтому обычно её просто кладут в общий файл, который инклюдится во все скрипты

Ошибка headers already sent к количеству вызовов отношения не имеет, это стандартная ошибка при кривой структуре кода и лечится элементарно. В интернете примерно миллион рекомендаций по её решению.

DirectoryIndex

Стоит ли проверять имя и пароль пользователей при каждом запросе к api(guzzle)?

Вот как всегда, в заголовке вопроса одно, а в тексте - ну совсем же другое.

В моем случае выдавать токен вообще бессмысленно,верно?

Верно

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

Никак.

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

Рекомендую найти видео "Как писать код, который понравится вашим тестам" с первой 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 заниматься отладкой бессмысленно.
Именно поэтому для программиста очень важно понимать, как работает его код. Иначе он просто не сможет его отладить.

Это пустые страхи.
Никакой "фрагментации" "диска"в таблице из двух числовых полей (то есть с фиксированным размером записи) не будет. БД прекрасно сама повторно использует ячейки удалённых записей.
Поэтому, как правильно сказал Akina, мягкое удаление для лайков делать бессмысленно

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

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