Ипатьев

Смотрите.
Вот вы заходите на страницу adminpanel.php без авторизации. Там происходит что?
Правильно, перенаправление на avt.php.
Вы попадаете на страницу avt.php, где первой строчкой идет обращение к переменной $_POST['login'].
И откуда она там возьмется?

Чтобы этого не было, из adminpanel.php надо направлять куда?

Кроме того.
Просто header('Location: '); писать недостаточно. Если я не захочу, то не буду переходить на указанную страницу, а останусь на этой.
то есть попаду на админпанель без авторизации.
Это очень дурацкая и очень известная дыра в безопасности.
После header('Location: '); всегда должно идти die;

Если говорить про конкретный пример, то он просто бессмысленный, даже с точки зрения житейской логики.
Учитывая, что if ($isTestOrder) можно прочитать, как ЕСЛИ переменная не занимает памяти то проверка выглядит просто глупостью. "Если переменная не занимает памяти, то не передавать её. Так мы с экономим память!" Если переменная и так не занимает никакой памяти, то какого еще дополнительно выделения памяти она может потребовать?

Если говорить про передачу параметров вообще, то оба неправы, но тимлид ближе к истине и надо всегда следовать его рекомендации не экономить на пустом месте. А экономить только адресно, когда экономия очевидна и востребована.

В общем случае тут не будет никакой экономии, ни на спичках, ни без.

При передаче параметра внутрь метода под него выделяется дополнительная память

- это чушь и неправда.

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

• Объекты изначально передаются по ссылке
  
• Строки и массивы - с использованием механизма copy-on-write. Что означает, что память будет выделяться только если переданное значение будет изменено в процессе обработки. А если оно будет только считываться, то дополнительной памяти занимать не будет
  

Для всех остальных типов, как было правильно сказано тимлидом - это будет экономия на спичках.

Если человек ничего не понимает в какой-то теме, он никогда не должен выступать с заявлениями вида "у меня возникла потребность". Потому что такие заявления базируются не на реальных потребностях, а на неграмотности, фантазиях и путанице в голове. И получаются вопросы вида "У меня возникла потребность забивать гвозди микроскопом. Я обыскал весь интернет но ничего понятного не нашел, только понял то что это делается на кухне. "

Вместо таких заявлений он должен подробно изложить исходную задачу.
Про которую ему подробно расскажут, как её решать нормально.

Хранить фото и видео в БД - это как надевать штаны на голову.
Хранить фото и видео в монге - как надевать на голову помойное ведро.

Файлы надо хранить в файловой системе.
Структурированные данные надо хранить в Базе Данных.
Монгу не нужно использовать ни для чего. Это вообще не база данных, а просто хранилище по типу "куча мусора", которое используется исключительно в стильных модных молодёжных стартупах, в которых не нашлось ни одного специалиста по базам данных. Это была тупиковая ветвь, поднявшаяся на отсутствовавшей на тот момент поддержке JSON в базах данных и хайпе

Простейшим вариантом будет выгрузить csv и, соответственно, загрузить его в mysql, используя либо запрос LOAD DATA либо какую-нибудь кнопочку в интерфейсе.
Во всяком случае, на этот вариант вы потратите гораздо меньше времени, чем на поиски "экранирования".

А так-то SQL сервер вряд ли поддерживает создание дампа в формате Mysql напрямую

Учитесь задавать вопросы, Балаганов.

С одной стороны мы все когда-то учились и делали глупости.
С другой - ну очень тяжело поверить, что человек, учивший в школе математику, не в состоянии справиться с задачей "посчитать повторяющиеся события".
Вот вы же сами говорите, что есть цикл
Какая проблема завести переменную, и прибавлять к ней для начала хотя бы единичку внутри цикла, а потом вывести получившийся результат?

1. РНР теги пишутся не так
2. Если вы хотите что-то передать, то передаваемое значение надо вывести, а не просто написать.
3. Данные из РНР в JS всегда передаются через json_encode
if(<?= json_encode($boris->step) ?> == true)

При решении любых задач необходимо применять логику. Желательно не женскую, а формальную. Булеву.
Если вам "очень нужна форма", то она у вас уже есть. Задача решена.

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

Эту задачу тоже надо решать с помощью логики.
Разбивая её на отдельные элементы, приступая к следующему только после того, как выполнили предыдущий.
При отправке файлов из формы у вас несколько этапов
1. Отправка отправка одного файла из формы в РНР скрипт.
2. Отправка файла, гарантированно имеющегося на сервере, на почту.
3. Если отправка одного файла работает, а нужно больше, то добавить нужное количество и вернуться к п.1

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

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

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

Так же, как и сайт с базой данных.

А ошибка 500 к заливке отношения не имеет, она может быть от чего угодно.
Сам текст ошибки надо посмотреть в логе ошибок веб-сервера, прочитать, что там написано, и исправить

В общем, чтобы не издеваться над девушкой, объясним на пальцах.

Во-первых, заголовок у вопроса чудовищно некорректный. Это все равно что спросить, "что быстрее - пылесос или стиральная машина?"
Во-вторых, ответ на вопрос "производить ли обработку данных в БД или же запросить все данные в клиентское приложение и обрабатывать там" совершенно очевиден: обработку данных следует производить в общем случае только в БД. Она для этого и придумана. Чтобы обрабатывать значительные объемы данных.

Да, js тоже "может" обрабатывать большие объемы данных.
Но чтобы значительный объем данных обработать, его сначала надо передать, полностью забив канал между сайтом и базой
Чтобы значительный объем данных обработать, его надо сначала проиндексировать. Причем делать это каждый раз, а не использовать уже имеющийся набор индексов
Чтобы значительный объем данных обработать, надо иметь значительный объем памяти или упасть из-за её недостатка
Чтобы значительный объем данных обработать в многопоточном режиме (а сайт как раз является многопоточной системой), все вышеперечисленное надо умножить на количество посетителей сайта - при каждом запросе перегонять весь массив данных, выделять память, индексировать, считать. Если же вы оставляете все данные в памяти приложения, то их тогда надо как-то синхронизировать с БД. То есть вы себе собираете кучу проблем на пустом месте.

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

Сто раз уже обсуждалось.
Заголовок не гарантирует не только уникальность, но и неизменность.
В реальной жизни заголовки довольно часто редактируются.
И "если убрать из URL уникальный id", то все ссылки, которые вели на статью, после редактирования превращаются в тыкву.