Dasturchilar orasida "Googling is a skill." degan ajoyib gap bor.
Ya'ni qanday izlashni bilish ham bilim, hatto san'at.
Bu ishingizni nohoyatda yengillashtiradi.
Google bilan do'stlashib oling :-)

urls.py ni ko'rsatingchi.
Aftidan, delete urldan teparoqda dynamic (slug, id kabi) url bor va siz jo'natgan request o'sha urlga "tiqilib" qolgan.
Ya'ni urlda "delete/" deb yozgan bo'lsangiz ham shu urlga kelayotgan request teparoqdagi "<int:id>/" dan o'tib keta olmayapti.
Agar shunday bo'lsa, dynamic urldan oldin boshqa kalit so'z(masalan, "detail/<int:id>/") ishlating yoki dynamic urlni eng oxiriga qoldiring.

Bu fikrlar faqat bir tomonlama.
Javaning qanchalik stabil va kuchli til ekanidan xabarim bor(ko'p bo'lmasa ham). Lekin bu degani boshqa tillar "axlat" degani emas.

Pythonda faqat rasm-videolarni yuklash mumkin? Yo'q, siz(muallif) pythonda faqat shuni qilishni bilasiz. Bizning firmada Banklar, Zavodlarning boshqaruv tizimlari kabilar Pythonda qilinadi va hozircha hammasi yaxshi ishlab turibdi.

Python platforma tanlaydi? Sizga kim aytdi projectni tog'ridan to'g'ri serverda yuriting deb? Container, virtual machine degan narsalar bor.

Shu o'rinda "ortiqcha vaqt, harajat" haqida. Siz serverga qo'yish uchun ba'zi qo'shimcha sozlashlarga ketadigan vaqt va harajatlarni aytdingiz. Normal jamoa javada 6 oyda tayyor qiladigan loyihani xuddi shu darajadagi jamoa Pythonda 2 oyda qilishi mumkin. Bu ham o'sha "ortiqcha ish, ortiqcha pul, ortiqcha vaqt"ga kiradimi?

Pythonda faqat Instagram kabi kichkina vebsaytlar yoziladi, Javada IBM SPSS kabi katta tizimlar yoziladi debsiz. Shu joyida shunchaki texnologiya giganti bo'lgan googlening bir shiorini keltirib o'taman:  “Python where we can, C++ where we must.”
Yoki bu ham kichkina vebsaytmi?

P.S. Tepadagilarni yozishdan maqsad python javadan kuchli yoki java kuchsiz deyish emas. Shunchaki har bir tilning o'z vazifasi va imkoniyatlari bor ekanini eslatib qo'yish. Faqat bir tomonlama analiz qilmaslikka chaqirish.
Agar siz biror tilning imkoniyatlarini bilmasangiz o'sha til kuchsiz degani emas.

Authentication uchun butun table bo'yicha unique bo'lgan field(column)dan foydalanish kerak bo'ladi.
Djangoning default User modelida username fieldi unique, ya'ni takrorlanmas. Bitta username bilan 2 kishi ro'yxatdan o'tolmaydi.
Agar buni o'zgartioqchi bo'lsangiz custom user model yozishingiz kerak bo'ladi. Shunda email, telefon raqam yoki boshqa biror field bilan authentication qilsangiz bo'ladi.

Assalomu aleykum password ni hash lash securityni qaysi jihatini oshiradi?

Ya'ni security ga qanday yordam beradi demoqchiman har xil attack lar bor ekan shularni biron tasini oldini oladimi ? Xss nimi yoki sql injectionni oldini oladimi shuni nazarda tutgandim?

Masalan, passwordni "chiqarib olish"ni oldini oladi.
Hash qilingan password bilan tekshirishda kiritilgan password o'sha key bo'yicha hash qilinib, natija databaseda saqlangan password bilan tekshiriladi, ya'ni databasedagi passwordni o'z holiga qaytarib bo'lmaydi.
Admin panel orqali boshqa userlarning passwordini ko'rsangiz, sizga hash holatida ko'rsatiladi.

Saytdagi url namunalari, ya'ni "yo'llar".
Masalan, "login/" yoki "posts/14/" url bu yo'l. Siz o'sha yo'ldan borganingizda sizni qaysidir view kutib oladi. U esa manzil deyishingiz mumkin. Masalan, "products/" nomli url patternga biriktirilgan view sizga barcha productlar ro'yxatini chiqarishi mumkin.

Agar siz borgan "yo'l" oxirida hech kim sizni "kutib" olmasa, 404 error chiqadi :-)

Redis in-memory database bo'lgani uchun, juda tezkor va asinxron ishlay oladi. Odatda, caching yoki async messanging(xuddi biz hozir yozishib turgan telegram chat) uchun ishlatiladi. Bir kishi yozgan xabar parallel ravishda qolganlarga ham yetib boradi, yangilash shart emas.

Celery esa message queue uchun ishlatiladi(lekin ishlatib ko'rmaganman). Ya'ni guruhda hozir birdaniga 50 kishi yozsa, ularni tartib bilan handle qilish uchun.

Bir narsani tushuning, hozir men u kishining muammosini yechim berganim bilan, uning ildizi o'z holicha qoladi. Ertaga rekursiyaga bog'liq yana biror error chiqqanda, yana yordam so'rashga majbur bo'ladi.
Maqsadim, xatoni qanday tuzatishni emas, u qayerdan kelganini ko'rsatish. Shunda keyingi safar o'zi muammoni topa oladi.
Agar qarmoq bo'lmasa baliqlar albatta bir kun tugaydi.

Bo'ldi, ortiq flood qilmoqchi emasman. Fikringizni hurmat qilaman.

Yana bir maslahat, dynamic urlpattern bilan ishlaganda ehtiyot bo'ling. Iloji bo'lsa, static pathdan keyin ishlating. Tartibda ham static urllarni birinchi qo'yganingiz yaxshi.
'',
'detail/<int:pk>/',
'results/<int:pk>',

shaklida. Bo'lmasa, so'rov yuborgan url'ingiz aytgan manzilingizga yetib bormasidan boshqa dynamic urlpatternga "tiqilib" qolishi mumkin.

Authentication uchun biror unique, ya'ni butun table bo'yicha takrorlanmaydigan column kerak bo'ladi. Umuman olganda har bir userning takrorlanmas id'si bor, lekin bu userning o'zi uchun eslab qoishga noqulay va sensitive data hisoblanadi(kimdir shu joyini noto'g'ri deyishi mumkin).
Shuning uchun birorta unique column qo'yish kerak. Bu turli xil: email, username, telefon raqam va hokazo bo'lishi mumkin.
Django default User modelida auth uchun username ishlatilgan. Agar boshqa biror narsadan foydalanib auth qilmoqchi bo'lsangiz, custom User model yozsangiz bo'ladi.

Function-based viewlarda renderga context dicrionary o'tkazasiz. Bu dictionary backenddan templatega jo'natiladigan hamma datani ichiga oladi.
Class-based(generic) viewlarda bu ishni get_context_data() methodi bajaradi. Default holda bu yerda faqat get_queryset() methodi qaytargan queryset bo'ladi. Qo'shimcha context qo'shish uchun methodni override qilish kerak:

posts = Post.objects.all()
authors = Author.objects.all()

def get_context_data(self, **kwargs):
context = super().get_context_data(**kwargs)
context["authors"] = authors
context["posts"] = posts
return context

Templateda {{posts}}, {{authors}} ko'rinishida ishlataverasiz.

ManyToMany relationship aslida databaseda simmetrik bo'lsa-da, yordamchi tableni djangoning o'zi tuzgani uchun biz faqat bir tarafdan reference qilamiz. Shuning uchun, ikkinchi model bu relationshipdan "bexabar" bo'ladi. Shuning uchun admin panelda ko'rinmaydi.

InlineModelAdmin orqali siz aytgan natijani olish mumkin, lekin bu unchalik yaxshi fikr emas deb o'ylayapman.
Yaxshisi, ModelAdminga filter qo'ying. Shunda, narigi model orqali "aylanib" kirishga hojat qolmaydi.

Birorta rich editor ishlatib ko'ring.

Agar manual markdown qilmoqchi bo'lsangiz(ya'ni html taglarni o'zingiz yozib) buning ham iloji bor.
https://docs.djangoproject.com/en/3.2/ref/templates/builtins/#safe
Mana buni qarab ko'ring.
Lekin buni ishlatishda ehtiyot bo'lishni tavsiya qilaman. Bu xavfsizlik bo'yicha bir qancha muammolar(masalan, XSS attack)ni keltirib chiqarishi mumkin.

Bu form adashmasam, registration uchun.
Va bilishimcha, TemplateViewdan inherit qilgansiz.
TemplateView faqat GET requestga javob beradi.
Yaxshisi, boshlanishiga function-based viewdan boshlang. Nima sodir bo'layotganini yaxshiroq tushunasiz. Yangi boshlaganda muhimi murakkab narsalar qilish emas, nima qilayotganingizni, kodingiz aslida qanday ishlayotganini tushunish.
Keyinchalik class basedga o'tsangiz bo'laveradi.

Form orqali modelga field qo'shib bo'lmaydi.
Formni xuddi qutidek tasavvur qilishingiz mumkin:
Siz uni templatega bo'sh holda chiqarasiz. User esa unga ma'lumot kirgizib, yana o'zingizga qaytarib beradi.

Djangoda ikki xil form bor: Form va ModelForm.

Form bu shunchaki oddiygina 'quti'. Unga xohlagancha field kiritasiz va xohlagan ma'lumotingizni olasiz.
Bu faqat ma'lumot o'tkazish uchun. Bu yerda Modelga aloqador narsa yo'q.

ModelForm esa eng ko'p ishlatiladigan kodlarni kamaytirish uchun ishlab chiqilgan.
Ya'ni siz har bir fieldni qo'lda kiritib chiqish o'rniga faqat bir modeldagi fieldlardan qaysilarini "quti"ga chiqarishni tanlaysiz.
Natijada, bu form faqat sizdagi modelga mos ma'lumot qabul qiladi.

Bu offtopic bo'lsa ham vijdonim qiynalgani uchun yozayapman.

Eng avval sizga ba'zi savollarni bermoqchiman:

Aynan nega sizga Professionali kerak?
Community version sizning talablaringizga javob bermayaptimi?
Nega boshqa tekin editorlardan foydalanmaysiz?
Nega Professionalni pullik qilib qo'yishgan?

Javoblar katta ehtimol bilan ko'pchilikda o'xshash bo'ladi:
Bu narsa bizga "ODAT" bo'lib qolgan.
Hamma joyda crack version.
Copyright oyoq osti bo'lib bo'lgan.
Yana kamiga crack versiyani chiqarish, uni ishlatishdan faxrlanishadi. Tan olasizmi yoki yo'q, biz, O'zbeklar mana shunday "O'ZBEKCHILIK"larni odat qilganmiz.

Sotib olishga pulim yo'q deysizmi?
Bilasizmi kim ferrari minadi?
Ferrari sotib olishga puli va xohishi bor odam. Agar puli yetmasa sekin boshqa variantlarni ko'radi.

Sizga ham tavsiyam shu. Xohlasangiz narxiga sotib oling.
Sotib olmasangiz o'sha "luxury class" versiondan hozircha voz kechib, oddiyroq biror narsa ishlatib turing.

P.S. Tepadagi gaplarim ba'zilarga shunchaki yetib bormaydi. Kimdir menga aql o'rgatishni ham boshlashi mumkin.
Shunchaki odam bo'laylik. Ertaga kattaroq loyiha ishlab chiqqan vaqtingiz xuddi shu narsa sizning boshingizga tushmasin.
Vijdonni ham ishlatib turaylik...

Hammaga salom. Pythonni bilmaydiganlarga yordam berishinglar yaxshi, ammo tanganing ikkinchi tarafini ham hisobga olsanglar yomon bo'lmasdi. Hozir siz yordam berayotgan(student)lar aslida shu narsani vaqtida o'rganishi kerak edi(Universitetga kirishdan maqsad nima?). Hozir sizning "sharofatingiz" bilan imtihondan o'tishyapti. Ular xursand, siz xursand, ularning kelajagi esa ... Ertaga 4 yil vaqtini bekorga sarflab, universitetdan diplom bilan chiqishadi, bilim esa yo'q.
Siz ham qaysidir ma'noda ularga vaqtini isrof qilish va o'z-o'zini aldashda ko'maklashayapsiz. Sababi, agar ular bugun o'ta olmasa, ertaga o'zlari o'rganishadi.
Yordam berayapman deb o'ylab, aslida ularning ziyoniga ishlamang, azizlar. Qolgani vijdoningizga havola.

Agar siz biror loyiha ustida yillab ishlasangiz-u, uni bittasi chiqib tekinga tarqatsa sizga yoqqan bo'larmidi? Pro versiyani tekinga tarqatish yoki umuman, tekinini topishga urinishdan oldin o'ylab ko'ring, shu ishingiz to'g'rimi?
Dinimiz bu ishingizni ma'qullaydimi yoki vijdoningiz?
Muallif mehnati va mualliflik huquqini hurmat qiling.