ThunderCat

Вангую что в запросе что-то типа селект * , соответственно айди тупо переписывается. Создайте алиас для нужного поля, типа comments.id as comment_id, users.id as user_id

Если используется построитель запросов, укажите какие поля нужны и выставите алиасы через встроенные методы.

Для лары есть пакеты с переводами уже готовые, если их функционал подходит, не вижу смысла строить свой велосипед.
Если же нужно очень кастомное решение с администрированием на уровне админки, то бд будет более качественным решением, так как работа с поиском и сортировкой это больше про РБД, нежели про файлы.

Мой инпут содержит всего 1 название фото, из-за в базу данных и отправляется 1 фото

Для загрузки большого количества файлов из одного инпута используется тег multiple.
Для того чтобы понимать что приходит в пхп делайте print_r($_FILES); и смотрите что там пришло.
Естественно для обработки более 1 файла нужен будет цикл, перебирающий $_FILES.

иногда на сайте могут возникать ошибки http(404, 401, 500 и т.д.),

Это абсолютно разные ошибки, и обрабатываться должны по разному.
404 должна обрабатываться самим движком сайта, отдавать именно запрошенный урл без перенаправления, и отдавать 404 статус, в том числе для того чтобы поисковые роботы вывели страницу из индекса.
401 скорее всего вообще ошибка настройки серверной части и прав на папки/файлы, редко когда эта ошибка вываливается просто так...
500 вообще не является конкретной ошибкой, это скорее общее оповещение что на конкретной странице что-то пошло не так или сайт в целом не работает. Упрощенно это любой фатал ерор, скрытый настройками вывода ошибок, + некоторые ошибки системного характера.

пробывал в htacces:
ErrorDocument 500 /error?error=500

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

Вроде запрос уходит

Что в пэйлоаде? Вангую что там ничего связанного с $_POST переменными нет...

contentType:"application/json; charset=utf-8"

Так как вы явно указываете что будете передавать строку жсон в теле запроса, не понятно что вы пытаетесь найти в $_POST.

<?echo($_POST);?>

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

1) Что пишет конслоль?
2) Запрос вообще выполняется? В нетворке виден запрос по субмиту на mail.php?
3) Что показывает нетворк в пэйлоаде запроса?
4) Что возвращает сервер на запрос?

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

Сложный ответ: Для того чтобы выявить проблему используют логирование и профилирование. В лог пишутся все запросы к бд или места где предполагается длительное выполнение кода (например запросы к апи или другим сайтам). Затем анализ, потом нахождение решения и фикс.
Профилирование же состоит из комплекса действий по нахождению узких мест. В частности код условно делится на блоки, затем выполнение каждого блока замеряется и выясняется какой блок создает задержки. Далее соответственно данный блок дробим до тех пор пока не находим конкретное место проблемы. 80% вероятности что это будет какой-то запрос, с выборкой из нескольких таблиц и структурами по типу EAV, 18% что запрос к какому-то апи/сайту и 2% что тормозит именно криво написанный код (хотя это вордпресс, тут вероятности примерно равные). Что делать зависит от того что за проблема в конкретном случае. Иногда надо что-то закешировть, иногда править запрос, добавлять индексы, возможно что-то менять в структуре. Тут уже от ситуации...

Перевести дату в стандартный формат, далее можно использовать MONTH() YEAR() DAY() для нужной сортировки.

Чистый SQL разработчик нужен в 1 случае на 1000, например сложный по архитектуре бд проект и средние знания у разрабов. Выгоднее нанять 1 дбшника, чем переучивать толпу девелоперов. Но в 99% случаев дбшник избыточен.

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

js + onClick + preventDefault() + window.location.href

SELECT * FROM store WHERE LIKE 'сбер%'

Это по тому что у вас и с SQL не все норм. Хинт - между WHERE и LIKE пропущена важная составляющая.

UPD: Судя по ошибке у вас там индекс на фултекст, по этому вместо лайк должно быть что-то типа MATCH(cp_name, 'сбер', 'fuzziness=AUTO:1,5')

Давайте вместе почитаем документацию и поучимся понимать что пишут умные дяди и тети:

session_destroy() уничтожает все данные, связанные с текущей сессией. Данная функция не удаляет какие-либо глобальные переменные, связанные с сессией и не удаляет сессионные cookie. Чтобы вновь использовать переменные сессии, следует вызвать .

Это значит что у вас в текущем состоянии пропадает переменная $_SESSION и связанный с ним идентификатор, но кука сессии и файл сессии на сервере никуда не деваются. И при следующем обращении к серверу вы делаете session_start() и сессия вновь работает.

Замечание: Нет необходимости вызывать session_destroy() в обычном коде. Очищайте массив $_SESSION вместо удаления данных сессии.

Очень важное замечание, как раз связанное с вашей возмущенной репликой о том что "ну вот так же работает!111!". При большом разнообразии настроек и конфигураций серверов, сессия может вести себя по разному, что с одной стороны дает гибкость поведения если знать как и зачем вы что-то делаете, с другой стороны может вызвать проблемы, как в вашем случае, когда вы не очень понимаете зачем какие настройки и как обойти возникшие сайдэффекты. По этому самым верным решением является удаление данных из сессии.

Чтобы полностью удалить сессию, также необходимо удалить и её идентификатор. Если для передачи идентификатора сессии используются cookie (поведение по умолчанию), то сессионные cookie также должны быть удалены. Для этого можно использовать setcookie().

Чего вы очевидно не делаете.

При включённой опции session.use_strict_mode, вам не нужно удалять устаревшие cookie идентификатора сессии. В этом нет необходимости, потому что модуль сессии не примет cookie идентификатора сессии, если с этим идентификатором сессии нет связанных данных, и модуль сессии установит новый cookie идентификатора сессии. Рекомендуется включать опцию session.use_strict_mode для всех сайтов.

Рекомендуемые настройки, которые возможно вам помогут решить проблему именно вашим способом, НО вышеописанный способ является рекомендуемым.

Такое делается на уровне приложения. БД это отдельный слой - хранения, вполне нормально получить пустое значение при отсутствии значения в хранилище, он (слой) не должен оперировать логикой замены или подстановки. Логика подстановки может поменяться, и при этом у вас не должно быть изменений нигде, кроме как в конкретной точке логики приложения. Хранилище с этим никак не связано.