ThunderCat

// в оба обработчика формы онсубмит добавлено:
var $inputFiles = $('.inputfile');
// то есть ВСЕ инпуты с классом инпутфайл будут добавлены в отправляемые данные,
//независимо от того в какой части документа они находятся

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

Если коротко:
>>Строгая типизация.
до жопы, ибо с клиента чаще всего приходят нетипизированные данные, их все равно надо валидировать и приводить к нужному типу.
>>Быстродействие.
От задачи к задаче вы получите разное быстродействие на разных языках (сарказм по асм поскипан)
>>Язык должен быть компилируемого, а не интерпретируемого типа.
не совсем ясна мотивация, ну да ладно, хозяин барин...
>>Он должен быть кросс-платформенным
основные грабли кроссплатформенных яп - оконный интерфейс, в вебе будет проще, по этому почти любой современный яп подойдет.
>>Он не должен тянуть за собой[поскипано многабукаф]
Все что-то за собой тянет, и объем тянущегося зависит от возраста/развитости платформы, соответственно смотрите в сторону зеленых новичков, получив в придачу сыроватый функционал и слабо развитое коммюнити/доки.
>>Этот язык должен быть стабилен
стабилен в вашей интерпретации - мертв(ибо без изменеий нет развития), либо противоречит предыдущему пункту. Почти любое серьезное обновление ведет к изменениям в коде(и в частности пропадание/появление старых/новых либ нормальный процесс)
>>Язык должен подходить для веб-разработки
Почти все уже адаптировали под веб, ибо народу всегда интересно завести своего уродца под новую задачу (снова поскипан сарказм про асм)
>>Хотелось бы, чтобы синтаксис такого языка был логичен и интуитивно понятен
Бейсик в руки и вперед... Вы же понимаете что для каждого разработчика эти слова несут совершенно разный смысл, что одному логично и красиво - для другого велосипед на костылях...
>>Программа, написанная на таком языке, не должна есть много памяти из-за каких-нибудь там виртуальных машин
ВМ и прочие накладные расходы присущи своей группе языков, кроме прочего они обеспечивают повышение быстродействия в кроссплатформенной среде, часто превосходя по быстродействию даже компилируемые аналоги без ВМ, тут уже выбор будет прирост производительности/потребление памяти (впрочем, это верно и в целом, все крутится вокруг баланса потребления быстрой памяти и приемлемостью скорости обработки данных при снижении лимита ее потребления).
>>Должно быть более-менее легко производить дебаг
Сложнее найти современный язык без таковой возможности...

Если кто то сталкивался с подобной проблемой - что вы делали???

Искал корень проблемы, а именно на первом этапе смотрим что физически приходит с сервера через девтулз хрома, если данные приходят с сервера - копаем в сторону кеша сервера/кукисов, иначе смотрим что из ресурсов тянется из кеша браузера, настраиваем соответствующим объектам время жизни.

прописать гет параметр, примерно так:
<img src="/img/someimage.jpg?1">

1) href в кнопке лишний атрибут
2) за адрес перехода отвечает атрибут action тега form, если оставить его пустым по умолчанию страница будет делать субмит на текущий урл.
3) если задача именно не покидать текущую страницу, тогда отправлять данные Аяксом.

реально ли заниматься web разработкой на Python, не соприкасаясь с front-end?

Реально, но гораздо менее профитно, как по финансам, так и по объему заказов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

cron? по крону меняйте содержимое index.php (или просто копируйте заранее заготовленный из другой папки), потом обратно.

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

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

Не понимаю в чем проблема, ставьте сторм, он работает вполне прилично на такой конфигурации. По поводу загрузки: 3 минуты не критично, после загрузки все довольно шустро работает. Если вы не выключаете его то работа вполне комфортна.