Александр

Нужно отталкиваться от тематики и направления сайта. Лично я бы сделал первый вариант - рега + авторизация.

У меня в связке с django-allauth отлично работает стандартное
{{ user.get_full_name }}

Напишите свою функцию для вывода имени пользователя и пропишите путь к ней в настройках settings.py.

ACCOUNT_USER_DISPLAY (=a callable returning user.username)
A callable (or string of the form 'some.module.callable_name') that takes a user as its only argument and returns the display name of the user. The default implementation returns user.username.

Например:

ACCOUNT_USER_DISPLAY = lambda user: u'%s %s' % (user.first_name, user.last_name)

или

ACCOUNT_USER_DISPLAY = lambda user: user.get_full_name()

или

ACCOUNT_USER_DISPLAY = 'myapp.somemodule.utils.user_display'

urlparse есть только в 2 питоне. У вас точно на 2 питоне крутится django?
И вообще, это устаревший модуль. Лучше использовать python-social-auth

В дебиане бинарник называется nodejs, а не node

sudo ln -s /usr/bin/nodejs /usr/bin/node

в последнее время юзаю sapegin.github.io/social-likes/ru все локально, следовательно быстро и выглядит симпатично

Сам озадачен этим вопросом. Долгое время пользовался кнопками от Яндекса. Но что-то недавно они не работали некоторое время. И клиенты жалуются на то, что картинки прикрепляются не те, что надо. Заменил на Pluso, настроил вывод og тегов - беда с картинками осталась. Причём оригинальная кнопка, например, одноклассников работает правильно, а кнопки сторонних сервисов нет. Потому что оригинальная кнопка и кнопка pluso генерируют разные адреса. Вероятно дело в том, соц. сети что-то у себя время от времени подкручивают, а сервисы поздно на это реагируют. Зоопарк из оригинальных кнопок разводить не хочется. Так что думаю придётся делать что-то своё. Например, вроде этого: habrahabr.ru/post/156185

Я эволюционно шел:

1. Сначала просто вбивал переменные в методе формирования контекста.
   
2. Добавил стандартные мета-теги в модель с настройками (на случай, если нечего вбивать).
   
3. Добавил мета-теги в модель, допустим, с категорией и понял, что стоит создать абстрактный класс, от которого позже наследовал и базовые настройки и эту модель.
   
4. Понял, что вьюхи сильно дублируют код: постоянно присваиваю переменным одно и то же.
   
5. В базовой вьюхе определил переменную, которая определяет, какие мета-теги используются, для каждой из них сделал метод ее получения, теперь во вьюхах пишу просто список мета-тегов, оно пытается выгрузить их из модели, либо найти метод, который их вернет (такой метод нужен на случай, если мета-теги не заполнены и нужно вместо seo_title подставить просто name).
   
6. Понял, что, по-хорошему, тут нужно создать приложение, которое сможет расширять любую вьюху. То есть отвязать его от моей базовой вьюхи и подарить сообществу.
   
7. Наконец-то решил погуглить: нашел django-meta, которое делает все то же самое, только чуть более изящно, автор явно прошел дальше по эволюционной ветке.
   
8. Приуныл, собираюсь использовать вот буквально завтра.
   

Оно выглядит хорошо: предоставляет базовый класс с мета-тегами, миксин для вьюхи (который экземпляр класса добавит в context). Можно забить мета-тег либо статично во вьюху, либо сделать метод для его динамического получения. Вкупе с абстрактной моделью это получается удобно, в данный момент я не могу придумать лучше.

Да, что касается админки. Если там нужны какие-то стандартные действия с полями SEO, типа как добавление их в fieldsets, лучше тоже создать миксин, который переопределил get_fieldsets, например (или что там у вас).

p.s. Я не думаю, что все это имеет смысл на сайте-визитке, например. Я бы делал такое начиная с масштаба интернет-магазина и более.

https://docs.djangoproject.com/en/1.7/howto/legacy...

python manage.py inspectdb > models.py