marazmiki

Поди, таблица в mysql создана в LATIN1?

Попробуйте так:

# urls.py
url(r'^rozdil/true', 'wiki.views.stats', kwargs={'is_main': True}),
url(r'^rozdil/false', 'wiki.views.stats', kwargs={'is_main': False}),

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

Добавьте в контекст шаблона список слайдов:

# views.py
def slider(request):
    slides = Slide.objects.all()
    return render(request, 'main.html', {'slides': slides})

а в шаблоне обращайтесь к каждому из слайдов списка

{# main.html #}
{% for slide in slides %}
<div class="item lifted">
    <img class="lazyOwl" data-src="{{ slide.image.url }}">
    <div class="caption-content">
        <h1 class="caption lifted">{{ slide.header }} </h1><br>
        <p class="caption2 lifted">{{ slide.caption }}</p>
    </div>
</div>
{% endfor %}

Ключевое слово — API :)

Пусть rails-приложение будет, к примеру, сервером и по оговоренному адресу ожидать входящих данных. А php-приложение вместо того, чтобы слать email, шлёт HTTP-запрос на сервер rails.

request.path, либо request.path_info

Мне кажется, что "лучше" или "удобнее" — субъективные метрики. И не очень абсолютные. К примеру, меня бесит grappelli (приложение, изменяющее внешний вид админки), а кому-то она наоборот нравится. Mezzanine, насколько я помню, grappelli использует. Мне это покажется дичайшим минусом, а кому-то плюсом.

Личный опыт: довелось довольно плотно поработать с django-cms и fein. Они, в общем-то работают по одному принципу, хотя и используют разную терминологию (django-cms для расширения функциональности страницы плагины, которые помещаются в плейсхолдеры, а fein — контент-тайпы и области соответственно), суть примерно одна. Хоть и слегка по-разному реализовано.

Сейчас ключевое отличие djnago-cms и fein в том, что первая, начиная вроде бы с версии 3.х, перешла целиком на фронтэнд-редактирование контента. Админки как таковой нет, вместо неё редирект на страницу с включенным редактированием. А Фейн управляется из админки, как и django-cms ранних версий.

Для программиста обе cms относительно удобны и легки для разработки и предоставляют интерфейс для написания плагинов (или контент-тайпов, в зависимости от). Но если лезть глубоко под капот, то в django-cms всё гораздо сложнее в плане моделей и отношений. Поэтому очень мудрым шагом со стороны её разработчиков было предоставить "низкоуровневое" апи с функциями вида create_page(), которое на деле создаёт десяток записей в десяти таблицах :-)

По поводу удобства редактирования контента, опять же субъективно: оба ужасны. Наверное, фейн даже в большей степени. Но при этом он более очевиден. Чего не скажешь о фронтэнд-редактировании django-cms, где вообще без поллитры не разобраться: сначала перевести страницу в режим редактирования, потом переключить непонятный тумблер контент\структура (или что-то такое, сейчас точно не помню), потом выбрать редактируемый плагин... потом не запутаться в кнопках сохранения и публикации, и так далее. Мой коллега придерживается мнения, что показывать такое пользователям просто нельзя.

Кстати, пользователь легко сможет сломать дерево сайта (вплоть до вызова 500-й вместо захода на любую из страниц), просто активно перетаскивая в админке ноды дерева туда-сюда. Это касается и fein, и django-cms.

Что до mezzanine. Запомнилось так: использует grappelli, зачем-то есть встроенные магазин и блог, которые сааавсем не на каждом сайте нужны. Плюсов не запомнил, снёс. Хотя сейчас, открыв ради любопытства документацию, вижу что-то про custom content types, так что, вероятно, будет всё то же самое, что и fein/django-cms, но в зелевноватых тонах grappelli. И с магазином :-)

Рискну предположить, что сложность из-за кириллического юзернейма (точнее, пути к его домашней директории).

Переделать-то можно, но тогда это это поле придётся добавлять в схему. А заполнять при сохранении:

class Zzz(Superclass):
    aaa = models.ForeignKey(Aaa)
    bbb = models.ForeignKey(Bbb)
    ccc = models.ForeignKey(Ccc)
    # Объявили поле и на всякий случай запретили редактировать его из админки или через форму.
    ddd = models.IntegerField(editable=False, default=0) 

    @property
    def eee(self):
        return self.aaa, self.bbb, self.ccc

    def save(self, *args, **kwargs):
        # Непосредственно перед физическим сохранением вычисляем значение поля
        self.ddd = reduce((lambda x, y: x + y), [e.some_param for e in self.eee])
        return super(Zzz, self).save(*args, **kwargs)

Не уверен, есть ли прям такое готовое (если и есть, то это, на мой взгляд, идеологически неверно). Но легко собрать из отдельных батареек.

Например, список стран есть в django-countries. Там, кажется, и флаги были. Решений по связанным селектам куча. Вот несколько штук из Гугла, которые вроде бы обновляются:

—django-clever-selects
—django-smart-selects
—django-selectable (отдельно про связанные списки)

Базы городов... Вероятнее всего, искать нужно в открытых источниках типа geonames. Для него, к слову, и джанговая батарейка есть