ThunderCat

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

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

Если данных не много и вы заранее знаете какие данные вам нужны для селекта просто получите их в json и используйте когда нужно. Если же данных много и они заранее не известны - запрашивайте их с сервера Аяксом. Можно даже в виде готового хтмл для селекта.

1) путь куда загружаете существует?
2) проверьте путь, не факт что вы его правильно указали( у вас путь читается от папки текущего скрипта, лучше использовать $_SERVER['DOCUMENT_ROOT'] и путь от него)
3) Права на папку куда пишете какие?
4) Ерор репортинг включите, отладка требует уровня E_ALL

если нужен совет - храните корзину в сессии/бд, отправляйте id и количество товара аяксом скрипту на сервер, обратно из скрипта выводите json с данными корзины, по которым нужным образом перерисовывайте элемент с корзиной. Тут вообще не вижу как реализовано хранение/получение данных корзины.

if($result == 'true') {...

Если так проверять, можно долго ждать пока результатом ответа будет строка 'true'.

UPD:

$bd_insert_query = "INSERT INTO " . DB_TABLE . " (mailbox) VALUES ('" . $MailBox . "')";
var_dump($bd_insert_query); // копируем и вставляем в базу руками, смотрим ответ, возможно понимаем что запрос кривой.
$result = mysqli_query($bd_link, $bd_insert_query);
var_dump($result); // смотрим что на самом деле произошло в запросе.

вообще с таким стилем программного кода var_dump должна стать вашей любимой функцией.

Из визуальной части - сходу не вижу где определена DB_TABLE, возможно она вообще вне видимости скрипта.
ну и по мелочи:
имена полей таблиц обычно заключают в апострофы: (`mailbox`);
посмотрите как работать с подготовленными запросами, это сильно лучше чем вставлять сырые данные в запрос.

$bd_insert_query = "INSERT INTO " . DB_TABLE . " ('ID', 'mailbox') VALUES ('LAST_INSERT_ID(), " . $MailBox . "')";

вообще треш и угар, так делать не нужно. Тем более если поле id автоинкрементное. Тем более с ошибкой в полях ввода.

А какие проблемы с переносом строк в текстареа? Неужели ентер не работает?

Обычно это делается на стороне клиента, на яваскрипте.

если Это принципиально, то читайте про History.pushstate()

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

Имхо можно тупо забить, ибо еще 10 неактивных записей в базе в месяц - вообще ниочем.

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

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

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

select * from products as pd
where `searchname` like '%$words[0]%' 
and `searchname` like '%$words[1]%'
and `searchname` like '%$words[2]%'

PS: dop_name, opis_name, seriya_nasos - горите в аду.

TinyMCE , CKEditor - 2 самых популярных, масса плагинов и мануалов, есть еще куча, но они не так распространены.

php.net/manual/ru/function.system.php
php.net/manual/ru/function.passthru.php

Некоторые PhpStorm рекомендовали,

Это среда разработки, не язык. Среда разработки на PHP. Обычно в связке с MySQL.
Плюсы:
1) Низкий порог вхождения(на начальном этапе легок в освоении)
2) Хорошо подходит для веб разработки, много готовых модулей и компонент, много документации и большое коммюнити.
3) Стандарт для любого хостинга - стек ЛАМП есть практически у всех хостеров
4) Есть минимум 4 очень хорошо поддерживаемых фреймворка, позволяющие быстро создать основу приложения.
5) Хорошая масштабируемость.
6) Дебаггер вполне нормальный, как и у любого другого языка, то что вы не разобрались это уже другой вопрос.
Минусы:
1) Это "не модно", коллеги с вейпами на гироскутерах с подворотами будут смеяться, "ведь есть го, раст, нода в конце концов"...
2) скорость работы некритично ниже сопоставимых питона и ноды (надо учитывать что, как всегда, скорость веб приложения чаще всего упирается в скорость обмена данными с клиентом + скорость работы бд, ЯП особых нагрузок обычно не несет).

кто-то хвалит – Python,

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

а как насчет Java?

Ява это отдельный мир, в основном заточенная на энтерпрайз решения, хотя конечно же и просто сайтики на ней пилят, да, но это больше экзотика, нежели правило.

Короче, вопрос ВСЕМ! Какой язык программирования и какая база данных лучше подходит тут?

В корне вопроса у вас "большой объем данных", однако что за данные, какие реальные объемы (хотя бы примерно в количестве записей) и какого типа(преимущественно текст / преимущественно цифровые данные / смешанное содержимое) не обозначено. В любом случае я бы ориентировался на возможности БД, а не ЯП.

Чтобы был там отслеживание программы (debugger)

Любой современный язык имеет инструменты отладки, ищите и обрящете.

и в будущем с объемом данных не было проблем (построение ключа для поиска, кодировка текст для разных языков).

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

есть подозрение что с подгрузкой блоков происходит "переподгрузка" вашего лика на котором висит евент клика. Как вариант решения - найти место где вешается листенер и перевесить его на документ, с проверкой таргет элемента. На jquery примерно так:

$(document).on('click','.pickpvz',function(e){
e.preventDefault();
// код обработчика
});