Exploding

Когда я делал свой первый магазин: первый - вообще первый да и еще и без движка (без cms, как-то сразу я опенсорс не взлюбил). Я php знал на уровне первый раз взял в руки книжку, но прочитал только "от автора".
Админку долгое время не мог написать переписать на php... т.к. в качестве админки (не сложной, но управлять всем можно было) служило постоянно допиливаемое приложение под win... хз, работало конечно оно тогда гораздо быстрее сравнительно с админками на php, ведь был просто прямой коннект к БД и огонь, но и минусы были типа отсутствия висивьюга...
Это я к тому, что магазин - это не есть что-то крайней степени сложное. От обычного дерьмосайта-статейника его отделяет пару нюансов, а так - те же яйца по сути...

Дополнение Еще вот подумал, что чего-то не хватает в ответе и понял чего: главных сущностей любого ресурса - полезность, интересность, удобство. А на чем вы его напишете, какой уровень вашего php и к нему примыкающих - для конечного посетителя абсолютно пофигу! Если вы сможете наделить ресурс (не конкретно магазин) данными качествами - вперед! Хоть на голом статичном html - админить его вам потом.

Песня - она (женского рода). Песня не "играл", а "играла".
<audio><source src="my_song.mp3"></audio>

~4-5 товаров / сек - это ахренеть как довольно быстро. Видимо мало картинок или вы миниатюры сохраняете только... В принципе основное время уходит на скачивание полноразмерных изображений, а все остальное так... пыль))
Я как-то помню качественно парсил качественный магазин, в котором на каждом товаре ~3-6 фоток в приличном разрешении, при ~15Мбитах получалось в среднем 2-4 сек/товар, т.к. получил html, разобрал и распихал данные по запросам, и скачиваю большие фотки, получил фотки, и каждую програмно:
- уникализировал
- налепил ватермарки (вообще нагло конечно, но так клиент захотел:))
- сгенерил миниатюры
- ну и плюс время на сохранение на диск (hdd 7200rpm)
Так что вы со своими 350 секундами радуйтесь! Наверно... т.к. скорее всего вы не настолько качественно парсите...

0. Можете внятно объяснить какой смысл в контроллере pages?
1. Лучше domain/pages/123-hello-world, чем domain/pages/123/hello-world, т.к. во втором случае из-за доп. слеша уровень "вложенности" страницы увеличивается, что незначительно, но влияет на вес страницы.
2. Эта страница по сути будет практически бесполезной для ПС (продвижения). Ссылки на "категории" или что там у вас, где бы они не находились - должны быть идентичны, иначе на "Тостере" опять появится вопрос про дубли страниц.

Ну и вообще, урл должен максимально доступно отражать инфу о странице, ее местоположении в структуре сайта, не говоря уже о его длине (<80 симв.), вхождениях ключей и их позиции относительно начала урла и т.д.

UPD чтобы и другие видели и по меньше повторяли вопросы такие
Ну вот этого я и хотел добиться! Как правило, контроллер в урле указывается для того, чтобы не путаться и понимать, что это за страница и какой модуль для ее формирования нужно использовать! Но если у вас контроллер "первого уровня" всего один - какой тогда смысл его использовать вообще? Это лишняя "вложенность" страницы для ПС, да и вообще абсурдно))
Для примера, чтобы понятно было, что я имею ввиду, приведу аналогию, а то я смотрю что как-то вы не въезжаете все равно в то, о чем я пытаюсь вам втолковать))):
Зашли вы на какой-то магазин и видите там такие ссылки:
domain/shop/info/contacts
domain/shop/info/delivery
domain/shop/categories/all
domain/shop/categories/cars
domain/shop/product/subaru-forester

Как по-вашему, есть ли какой-то смысл в контроллере shop? Вот и в вашем случае vacancies в такой же ситуации получается.

И еще, возможно у вас возникнет вопрос в том, стоит ли в урле отображать полный путь к конечной странице типа:
domain/vacancies/category/sub-category/sub-sub-category/sub-...-category/vacancy
Нет, так лучше не делать! Выводите только транслит последней категории. Все дерево - вредно.
Еще может прийти в голову поднаеб..ть ПС и фигануть урлы такого вида, чтобы все страницы были первого уровня:
domain/vacancies-category-sub-category-vacancy
или такого:
domain/vacancies-category_1_ura-sub_category_1_ura_ya_skazal-vacancy_omg
Работать то оно будет, но ПС в отличие от вашего сервера - не видит .htaccess и не может адекватно въехать что там и куда у вас входит и выходит. Поэтому у ПС будет путаница со структурой сайта.
Обязательно используйте "/" (слеш) для разделения разделов сайта.
Не используйте в качестве заменителя пробела "_". Используйте только "-". Чехол_гугл_понимает_это_как_одно_слово.
Помните, что страница не резиновая и гугл выделяет только 48em или 624px прежде чем могучий overflow обрежет все те важные слова, которые вы несли-несли миру, да не донесли)))
Все вроде бы.

Может быть гуглФормс подойдет?

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

Тогда уже хотя бы так:)

фейспалм

li:hover{
    border-bottom: 1px solid #000; 
}

UPD
Оно то работать будет, но насколько нормально хз...
Это напоминает мультик про чебурашку: - Гена, тебе наверно тяжело нести сумки? Давай я их буду нести, а ты понесешь меня! ))

.main{
   height: calc(100% - 50px);
   overflow: auto;
}

50px - высота темного, сырого подвала

Я не совсем понял, акцент на том, как организовать хранения данных в мускуле или что-то, что касается именно джанги?
Если первое - я бы разделил документы на типы: еще одно поле в таблице документов, которое бы определяло тип документа (enum "sale", "order", etc.). И зная тип, документа можно"на лету" формировать те же остатки по складу, не парясь о целостности данных. А в качестве уникальных идентификаторов для позиций поставки и по ним же отслеживать что продалось со склада - использовать например md5 хеш:
product_id + order_price ("плюс" тут рассматривать как канкатонацию параметров).
Другой вопрос, что будет потом через много-много времени... Т.к. такой вариант рассчета склада "на лету" рано или поздно будет увеличивать нагрузку на субд, но тут уже индивидуальный вопрос каждого. Если это не 100500 продаж в день то данная схема вполне может существовать и успешно разруливать на протяжении долгого времени. А там видно будет:)