Сейчас есть два популярных языка с очень низким порогом входа: PHP и Javascript. Большинство карьер в этой области начинаются с открывания текстового редактора и случайном изменении кода — эти языки все прощают.
Результаты можно видеть по качеству кода, качеству вопросов на тостере и StackOverflow. Собственно, Python потихоньку двигается в ту же сторону — это цена популярности.
Возможно, для кого-то это обидно, но я не вижу повода обижаться. У всех людей разные способности, и разные желания. Все чаще я вижу код на Python написанный людьми, которые не утрудили себя даже дочитать до конца tutorial из дистрибутива. Ну, что тут поделать? Философский вопрос, и каждый на него находит свой ответ. Я, например, уже 15 лет назад понял, что ни в какой PHP проект не сунусь ни за какие коврижки. Последней каплей был коммерческий продукт на PHP, продающийся за серьезные деньги, авторы которого вместо выноса общего кода в функции просто копи-пастили куски кода из файла в файл. Поиск и исправление ошибок превращался в «увлекательное» занятие: найди еще 15 экземпляров копи-пасты и исправь ту же ошибку в каждом. Или перепиши на вызов функции.
Тогда я поставил себе за правило: больше не браться никогда ни за какую работу, связанную с PHP. Даже чтение статей на Хабре по PHP, PHP-фреймворкам, и т.п., до сих пор подтверждает мою уверенность, что это был правильный выбор.
В последние 3-4 года я потихоньку вижу приток таких же программистов и методик в Python проекты. Ну а че, отрасль растет, спрос на программистов есть. Когда этот ручеек превратится в реку, перейду на другой язык окончательно (Clojure, Kotlin, Haskell, Go, еще не определился).
Наверное, нет смысла. Если потребности удовлетворяются WP, то ставят WP. Если не удовлетворяются — зачем тратить силы на инсталлятор, тот же Wagtail и так легко устанавливается, это не самая сложная задача у человека, которому надо будет сделать сайт.
В общем, у каждого продукта своя ниша. И CMS на Python появились намного позже, все места были уже заняты. За исключением Plone, но у Plone очень высокий порог входа.
Это вопрос не новичка в jQuery, а новичка в Javascript. Вам сначала надо изучить язык, а потом писать. Разработка методом копи-пасты и случайного изменения существующего кода, с исправлением ошибок по вопросам на тостере/StackOverflow - это тупиковый путь, который не поможет ни вам, ни кому-либо другому.
Начните с чтения туториалов/книг по Javascript. Выясните разницу между языком программирования Javascript, jQuery, HTML, DOM.
Как в ответах уже написали, скорее всего, это ошибка файловой системы. Или, но это менее вероятно, в имени могут быть пробелы или непечатаемые символы. Тогда можно попробовать удалить командой rm -i *, например (ответить 'n' для всех файлов, кроме удаляемого).
Нужно использовать django-crispy-forms, неважно, с Bootstrap или нет. Этот пакет решает все проблемы с версткой форм. Можно использовать стили bootstrap, можно любые другие. Для bootstrap в нем есть встроенный набор шаблонов.
Сохранять как обычную форму. Если в bootstrap modal форма, то при нажатии на submit она отправится как обычная форма, это же обычный HTML, только стилизован под модальное окно.
Если хочется отправлять форму через XMLHttpRequest, то скорее всего придется самому соответствующий код написать. Для простых случаев это элементарно, для сложных можно поискать готовый пакет (раньше не было, может быть уже появились), или переходить на какой-нибудь Frontend-фреймворк (react, angular, vue, etc).
А так как у вас написано разве не работает?
Кода формы вы не привели, поэтому не до конца понятно. И этот код делает не то, что было в оригинальном вопросе - здесь параметры взаимоисключающие.
И еще раз повторюсь, вручную писать View и код обработки форм - это хорошо только для обучения. Но для обучения продуктивнее читать документацию и размышлять, по вопросам на toster/StackOverflow менее эффективно будет - это как Google Translate воспользоваться, вместо того, чтобы самому напрячься и перевести. Мозг не работает и не получает новые знания в таком режиме.
Если для серьезного неигрушечного сайта, то лучше сразу взять django.views.generic.ListView или какой-нибудь другой из generic. Так и количество кода будет меньше (вашего кода, что важно как для вас, так и для того, кто будет поддерживать за вами), и автоматически будут всякие удобные возможности работать, типа разбиения на страницы.
Продукты JetBrains требовательны к ресурсам, но это потому что они просто на порядок превосходят все остальное. Конкретно CLion еще не пользовался, но например PyCharm позволяет разобраться в любом самом запутанном коде на Python и Javascript. Переход от использования функции к определению, рефакторинг, и т.д. Все это конечно не так просто реализовать: приходится парсить код проекта, стандартной библиотеки, всех зависимостей, и держать это в памяти для быстрых переходов.
Все равно сложно сказать. У меня, например, индикатор загрузки CPU почти никогда не поднимается выше 10-15%. Всегда есть около 3 Гб свободной памяти, как минимум 4 под кэш.
При моей работе (у меня в основном PyCharm/Django/PostgreSQL) все индексируется быстро, все мои задачи выполняются быстро на i5. Но в общем, у меня точно так же было и на старом 10-летнем ноутбуке с каким-то древним Intel Core, там меня ограничивал только HDD и память, т.к. периодически все не влезало в память, и начинался своппинг.
В общем, я почему-то сомневаюсь, что эффект от замены процессора будет, но т.к. давным давно не работал с Java, то не поручусь. Смотря что именно не устраивает в производительности сейчас.
Например, в моем ноутбуке процессор слабоват только для обработки видео, это явно чувствуется в монтажной программе. Для всех остальных задач его хватает с лихвой.
Возможность есть всегда. Сделать свою модель, поправить код проекта. Могут возникнуть сложности с миграциями, которые довольно просто решаются. Тема обсосана со всех сторона в течении последних 5 лет. Куча блог постов в Google, StackOverflow.
Поскольку у меня такой задачи никогда не было, то советовать ничего не стану. Но думаю, что реально использовать готовый скрипт или написать свой для монтирования пользовательских каталогов перед резервным копированием.
Вообще, решений для резервного копирования очень много, я использую duplicity, потому что мне кажется, что это самый простой и при этом мощный способ. Кроме того, мне он нравится универсальностью: копирую свою машину точно таким же образом, как и удаленные сервера, не надо держать в голове разные команды для разных случаев.