Django: извернуться и сделать кастомные редактируемые юзером сайтики

Ты ищешь одну из 9000 CMS поверх джанги?

давать к нему доступ через фтп

Можно же по хттп.

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

man git, критичные вещи тупо не включать и предусмотреть механизм заглушек. Алсо, ещё одна причина не использовать ftp (вы что там, в девяностых?).

CMS не подойдет, там все слишком кастомное, свою админку писать слишком долго и муторно.

Поясни плиз про заглушки.

А зачем изобретать велосипед? Для простеньких сайтиков есть wordpress и джумла. Оно конечно пхп, но именно для этого пхп и создавался.

Эмм. 2 конфига: для продакшна и для этого вашего юзера. По переменной, определённой в конфиге, включать продакшн-логику (например, специфические инклюды). Прикладывать скрипт с разворачиванием тестовой базы. Прикладывать .cmd (если я правильно понял мысль с денвером, хотя зачем он — джанга умеет быть веб-сервером сама), делающий git commit && git push. Прикладывать .cmd для отката предыдущего шага (юзеры скажут спасибо). Стандартно же и делается довольно быстро. Если есть предрассудки против git — есть mercurial.

Конфиг для продакшна, понятно, не в том git-репозитории, что идёт юзеру.

Есть

https://pypi.python.org/pypi/django-dbtemplates

и

https://www.djangopackages.com/grids/g/file-managers/

Если верстальщик не можыд асилить шаблоны Django (а хоть какие-то шаблоны всё равно нужны, как ни крути), то нафиг он нужен, ящетаю.

Затем, что есть бизнес-логика, связанная с.

Я не стал ее всю тут излагать для экономии моего и чужого времени.

Понятно. Не, так не пойдет, наш код утечет кому попало.

Резонно.

Пойдёт, можно будет управлять, кому что утечёт. И в любом случае не выйдет одновременно дать верстальщику поднять ваш проект (кусок его) локально и не дать ему ни строки кода.

Опять же, условный инклюд. Заворачивать продакшн-логику в модуль, инклюдить её либо заглушку в зависимости от конфига. У верстальщика в любом случае не будет продакшн-логики: она тупо не будет включена в его git-репозиторий.

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

Альтернатива одна — реализовать изменение вёрстки через тот же веб. У вас получится очередная (простая, но более мощная, чем хомячковые с гуем-на-всё) CMS с возможностью руками писать шаблоны. Тогда верстальщику не надо ничего поднимать и не нужен код. Но песочницу для него делать в любом случае. Я не в курсе, есть ли готовые решения для подобного.

Спасибо, интересное решение.