Джанго-КМВ

1. ... или как повторно использовать ваши плагины внутри разделов с различным дизайном Проблема: часто...
2. ... или как сделать редактируемой пользователем страницу 404, которая остается в дереве страниц CMS
3. ... это " Разместить по запросу "за февраль 2011
4. ... или как использовать расширенную модель в ваших шаблонах и особенно во встроенной навигации
5. ... или как добавить некоторые поля к модели страницы в админке без изменения Джанго CMS ядро

... или как повторно использовать ваши плагины внутри разделов с различным дизайном

Проблема: часто на разрабатываемых веб-сайтах мне необходимо отображать один и тот же набор данных несколькими различными способами. Например, если у меня есть новостная лента, которая должна появляться в разных разделах сайта, например, на боковой панели, в основном содержимом и т. Д. Использование Джанго CMS плагины делают это довольно легко.
Для простоты возьмем следующий случай. Кортеж изображения / текста с двумя вариантами компоновки - изображение слева от текста и изображение справа.

Те же данные, но разное расположение. Все, что вам нужно сделать, это просто позволить вашим пользователям изменять шаблон плагина в соответствии с их потребностями. Если у вас нет опыта работы с плагинами Django CMS, я советую вам проверить, как создавать собственные плагины Django CMS прежде чем продолжить с решением.

Решение: Сначала вам нужно будет создать кортеж, содержащий ваши шаблоны (и их удобочитаемые имена), и добавить поле, которое будет содержать выбранный шаблон в модель плагина.

# models.py PLUGIN_TEMPLATES = (('image_on_left.html', 'Изображение слева'), ('image_on_right.html', 'Изображение справа'),) класс SamplePlugin (CMSPlugin): # свойства вашего плагина здесь template = models , CharField ('Template', max_length = 255, choices = PLUGIN_TEMPLATES) Теперь пришло время настроить метод визуализации шаблона: # cms_plugins.py class CMSSamplePlugin (CMSPluginBase): model = SamplePlugin name = 'Пример плагина' render_template = PLUGIN_PLEM_PLEM_PLEM_PLEM ] [0] def render (self, context, instance, placeholder): если экземпляр и экземпляр. Шаблон: сам. render_template = экземпляр. шаблон # ваши вещи здесь возвращают контекст

Заключительные слова: да , это все. Просто не так ли? Удивительно, как иногда такие мелочи так полезны. Если у вас больше различий в макете ваших шаблонов, вам, вероятно, придется добавить немного больше контекста, который может не понадобиться некоторым вашим шаблонам, но это нормально. Не стесняйтесь комментировать, и если вы используете этот «трюк», пожалуйста, добавьте свой вариант использования - будет интересно посмотреть, во сколько разных случаев это работает.

... или как избежать дублирования контента, сохраняя текущий язык в URL

Предисловие: Ранее в этом году я писал о Особенности Django CMS 2.2, которые я хочу увидеть и одна из упомянутых вещей состояла в том, что после того, как вы выбрали язык сайта, не имеет значения, откроете ли вы «/ my_page /» или «/ en / my_page /» - он просто показывает тот же контент. Проблема в том, что это может рассматриваться как дублирующий и противоречивый контент.
Дублируйте, потому что вы видите одно и то же содержимое с и без языкового кода в URL-адресе и несовместимо, потому что для одного и того же URL-адреса можно получить разные языковые версии, т.е. разный контент

Решение. Это можно легко исправить с помощью специального промежуточного программного обеспечения, которое будет перенаправлять URL-адрес, не содержащий языкового кода. В моем случае промежуточное программное обеспечение хранится в «middleware / URLMiddlewares.py» (путь указан относительно корневого каталога моего проекта) и содержит следующий код.

из cms.middleware.multilingual import MultilingualURLMiddleware из django.conf настройки импорта из django.http import HttpResponseRedirect из django.utils класс импорта импорта дорожка . split ('/') [1] если lang_path в настройках. URLS_WITHOUT_LANGUAGE_REDIRECT: вернуть Нет язык = само. get_language_from_request (запрос) перевод. активировать (языковой) запрос. LANGUAGE_CODE = language if lang_path == '': вернуть HttpResponseRedirect ('/% s /'% language), если len ([z для z в настройках. LANGUAGES, если z [0] == lang_path]) == 0: вернуть HttpResponseRedirect ( '/% s% s'% (language, request. path)) Теперь небольшое объяснение того, что происходит в этом промежуточном программном обеспечении. Примечание. Если вы не знакомы с работой промежуточного программного обеспечения, проверьте и Джанго Middlewares , Вернуться к коду. Сначала мы разбиваем URL-адрес на «/» и берем второй элемент (именно здесь должен быть наш языковой код) и сохраняем в lang_path (8). URLS_WITHOUT_LANGUAGE_REDIRECT - это просто список URL-адресов, которые не должны перенаправляться, если lang_path соответствует любому из URL-адресов, которые мы возвращаем, Нет, т. Е. Запрос не изменяется (9-10). Это используется для тех разделов сайта, которые не относятся к конкретному языку, например, материалы для СМИ. Затем мы получаем язык на основе запроса (11-13). Если lang_path пуст, то пользователь запросил домашнюю страницу, и мы перенаправили его на правильную языковую версию (14-15). Если lang_path не соответствует ни одному из объявленных языков, это означает, что код языка отсутствует в URL, и пользователь перенаправляется на правильную языковую версию этой страницы (16-17). Чтобы промежуточное программное обеспечение работало, вы должны обновить файл settings.py. Сначала добавьте промежуточное программное обеспечение к вашему MIDDLEWARE_CLASSES - в моем случае это путь «middleware.URLMiddlewares.CustomMultilingualURLMiddleware» . Во-вторых, добавьте список URLS_WITHOUT_LANGUAGE_REDIRECT и поместите туда URL-адреса, которые не следует перенаправлять, например: URLS_WITHOUT_LANGUAGE_REDIRECT = ['css', 'js',] Особенности: если код языка отсутствует в URL-адресе и отсутствует языковой файл cookie, настройте параметры браузера будет использоваться для определения вашего предпочтительного языка. К сожалению, большинство пользователей не знают об этой опции, и для нее часто остается значение по умолчанию. Если вы хотите, чтобы этот параметр игнорировался, просто добавьте следующий код после строки 10 в промежуточном программном обеспечении выше: if request. МЕТА. has_key ('HTTP_ACCEPT_LANGUAGE'): запрос del. META ['HTTP_ACCEPT_LANGUAGE']
Он удалил заголовок HTTP_ACCEPT_LANGUAGE, отправленный из браузера, и Django использует язык, установленный в его настройках по умолчанию.

URLS_WITHOUT_LANGUAGE_REDIRECT чрезвычайно полезен, если вы разрабатываете с использованием встроенного сервера разработки и обслуживаете мультимедийные файлы через него. Но как только вы запускаете свой веб-сайт в производство, я настоятельно рекомендую вам использовать эти файлы непосредственно веб-сервером, а не использовать статическую подачу Django.

Заключительные слова: в Django 1.4 будут большие изменения в многоязычных URL, но до тех пор вы можете использовать этот код, чтобы улучшить SEO вашего сайта. Любые идеи по улучшению будут оценены.

... как сделать выпадающие списки на страницах Django CMS

Проблема: иногда, когда вы создаете пользовательские приложения или плагины для Django CMS, вам нужно свойство, которое связывает текущий элемент со страницей в CMS. Нет ничего проще, чем это - вы просто добавляете ForeignKey в вашу модель, которая указывает на модель Page, и все (почти) в порядке. Пример:

из cms.models import Класс страницы MyModel (models. Model): # некоторые атрибуты модели здесь page = models. ForeignKey (Page) Если вы зарегистрировали свою модель в админке Django или просто добавили в нее форму модели, вы увидите что-то вроде этого:

Круто верно? Не совсем. Проблема в том, что эти страницы имеют иерархическую структуру, и перечисление их в едином списке может / немного сбивает с толку. Итак, давайте сделаем отступ в соответствии с их уровнем в иерархии. Решение. Самый простой способ добиться этого отступа - переписать список выбора поля ForeignKey в методе ModelForm __init__. класс MyModelForm (формы. ModelForm): класс Meta: model = MyModel def __init__ (self, * args, ** kwargs): super (MyModelForm, self). __init__ (* args, ** kwargs) выборы = [self. поля ['страница']. выбор __iter__ (). next ()] для страницы в себе. поля ['страница']. queryset: выбор. append ((page. id, ''. join (['-' * page. level, page. __unicode__ ()]))) self. поля ['страница']. выбор = выбор
Волшебство лежит между строками 7 и 11, в строке 7 мы создаем список с одним элементом - пустая опция по умолчанию для выпадающего списка. Необходимость использования «__iter __ (). Next ()» обусловлена ​​тем фактом, что атрибут choices полей является объектом django.forms.models.ModelChoiceIterator, который является итеративным, но не индексируемым, т.е. вы не можете просто использовать self.fields [ 'URL']. выбор [0].
После того, как у нас был пустой выбор, пришло время добавить реальные, поэтому мы перебираем набор запросов (8-я строка), в котором они содержатся, и для каждого элемента мы добавляем кортеж в наш список выбора (10). Первый элемент кортежа - это идентификатор страницы - ничего особенного, но второй ... здесь появляется магия питона . Мы умножаем знак минус ('-') на уровень страницы и объединяем результат с заголовком страницы. Осталось только заменить выбор полей (строка 12) и вот результат:

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

... или как сделать редактируемой пользователем страницу 404, которая остается в дереве страниц CMS

Основы: да, вам это нужно! Вам нужна страница 404, потому что вы никогда не знаете, что может случиться со ссылкой: плохая вставка ссылки, устаревшая или удаленная статья, кто-то просто играет с вашими URL-адресами и т. Д. Лучше, чтобы и вы, и посетители вашего сайта имели красивую страницу, которая следует за дизайн веб-сайта вместо веб-сервера по умолчанию, который обычно содержит информацию о сервере, что является возможной проблемой безопасности. С Django это легко, просто создайте HTML-шаблон с именем файла 404.html, поместите его в корневой каталог шаблонов и вуаля - все готово. У вас также будет автоматически определена переменная request_path в контексте, которая содержит URL, который не был найден.

Проблема: иногда клиентам требуется возможность редактировать свои 404 страницы. Или в других случаях вам нужно использовать какой-либо пользовательский контекст или вы хотите интегрировать плагины и иметь возможность легко изменять их через администрацию CMS. Например: вы хотите отобразить свой новый удивительный «Плагин Sitemap» на этой странице 404.

Решение: Django позволяет вам указать пользовательский вид обработчика 404, поэтому вам просто нужно определить его, установить его в urls.py и сделать так, чтобы он отображал нужную страницу:

# in urls.py handler404 = 'site_utils.handler404' # в site_utils.py из cms.views сведения об импорте def handler404 (запрос): вернуть сведения (запрос, '404-page-url') где '404-page-url' URL страницы, которую вы хотите показать при 404 ошибках. Так что все выглядит хорошо, и здесь есть подводный камень. Если вы используете его таким образом, ваша веб-страница будет возвращать «200 OK» вместо «404 Not Found». Это может убить вашего SEO (кроме случаев, когда вы хотите, чтобы ваша страница 404 была первым результатом для вашего сайта). Поэтому вам просто нужно добавить заголовок 404 в ответ: def handler404 (request): response = details (request, 'novini') ответ. status_code = 404 ответ

Заключительные слова: почему они HTTP коды состояния очень важно. Причина в том, что они сообщают поисковым системам и другим службам автоматического сканирования, каков статус страницы. Это нормальная страница, редирект, не найден, ошибка или что-то еще. Предоставление неправильных кодов состояния может / будет иметь негативное влияние на SEO вашего веб-сайта, поэтому старайтесь сохранять их правильными, особенно когда это легко сделать, как в примере выше.

Примечание: если приведенный выше код не работает для вас, пожалуйста, проверьте решение Аллана в комментариях

... это " Разместить по запросу "за февраль 2011

Предисловие: Я должен признать, что ожидал большего интереса к теме «Пост по запросу», но, вероятно, мой блог слишком молод для этого, но я думаю, что попробую снова (скоро или нет). Более важно то, что Йонас Обрист является бесспорным победителем этого «конкурса» этого месяца.

Особенности: одна из самых полезных функций в следующем Джанго CMS должна быть возможность копирования содержимого заполнителя между версиями одной страницы на разных языках. Например, представьте, что у вас есть домашняя страница с несколькими местозаполнителями, на каждом из которых есть несколько плагинов / фрагментов (последние новости, популярные продукты и т. Д.), Когда вы создаете новую языковую версию страницы, это действительно раздражает, когда вы добавляете ее по одной.

Еще одна функция, запрошенная моим коллегой Miro немного противоположен тому, что я хочу, он хочет иметь возможность добавлять различные шаблоны страниц для каждой языковой версии страницы. Я также считаю это полезным, потому что иногда ваша языковая версия не полностью отражается даже на одной странице.

Ошибки: я не уверен, что это на самом деле ошибка, но я думаю, что это плохо для SEO, поэтому я отмечу это. Если у вас многоязычный веб-сайт, после того, как вы установили язык в файле cookie, эта страница будет отображаться независимо от того, есть ли у вас код языка в URL. Например, "/ en / news /" равно "/ news /". Это приводит к дублированию контента, который считается плохим для SEO, а также вводит в заблуждение, потому что каждый визит "/ news /" с другим языком в cookie возвращает различный контент. Я сделал некоторые исправления для этого, которые будут представлены в следующем посте.

Заключение: Спасибо всем участникам и ребятам из Django CMS - вы проделали потрясающую работу, я надеюсь, что вам понравятся функции, которые я предложил, и что мы сможем увидеть их в следующей версии. Комментарии и ответы приветствуются как всегда.

В последние несколько недель я был немного занят (и страдает от недостатка вдохновения), поэтому в моем блоге не хватает новых постов, но я вижу, что его посещают люди (особенно для Джанго CMS материал), поэтому я готов начать практику "Пост по запросу".

Идея проста - я буду собирать запросы на пост-темы в первые три недели (или 21 дня) каждого месяца, и после выбора на основе ваших голосов (и моего решения) я отправлю пост на выбранную тему конец недели Пожалуйста, оставьте свой вопрос в следующих областях - Django, Django CMS, Web Development. Вопрос в других областях тоже будет рассмотрен, но может выделиться из моей области знаний. Вы можете разместить свой запрос Вот или проверьте список и проголосуйте за другой или просто прокомментируйте этот пост.
Я надеюсь, что вы найдете эту инициативу интересной и присоединитесь к ней.

Прежде всего, примите мои извинения, что я не мог предупредить вас об этом недостатке ранее, но я был очень занят в последние несколько недель, поэтому давайте перейдем непосредственно к проблеме.
Если вы помните в Расширение модели Django CMS Page - часть II мы добавили метод в класс NavigationNode, который возвращает экземпляр соответствующего объекта Page. Если мы будем использовать его так, как показано здесь:

из menus.base импортировать NavigationNode NavigationNode. page_instance = lambda u: Page. объекты . фильтр (pk = u. id) [0]

Лямбда-функция выполняется каждый раз, когда вызывается page_instance, так что это определенно увеличивает количество выполненных SQL-запросов (+1 за каждый вызов page_instance). Хотя этот запрос выполняется с использованием первичного ключа, и он действительно быстрый, это может доставить вам неприятности. Особенно, если ваш хостинг-провайдер дает вам ограничение по количеству запросов за раз.
Хорошим моментом является то, что это не такая большая проблема, если вы делаете это один или два раза на страницу, и это может быть действительно полезным. Все зависит от того, как вы его используете. Также, если вы кешируете выходной HTML, вы пропустите накладные расходы на базу данных (но вы должны быть осторожны и создать механизм, который сделает недействительным кеш после модификации страницы)

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

... или как использовать расширенную модель в ваших шаблонах и особенно во встроенной навигации

Проблема: как вы можете видеть в предыдущий пост Существует очень простой способ расширить модель страницы с помощью некоторых настраиваемых полей без изменения кода ядра. Но как использовать ваши настраиваемые поля внутри ваших шаблонов? Если у вас есть экземпляр модели Page, все в порядке. Вы можете просто получить доступ к его свойствам, и все в порядке. К сожалению, есть проблема, если вы попробуете это внутри собственного шаблона, используемого для тега шаблона show_menu.

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

Решение: Прежде всего я решил упростить доступ к созданным ранее пользовательским свойствам, поэтому добавил к нему следующий код:

Класс PageAvatars (модели. модель): страница = модели. ForeignKey (Page, unique = True, verbose_name = _ ("Page"), editable = False, related_name = 'extended_fields') big_avatar = FileBrowseField (_ (u'Big Avatar '), max_length = 255, пробел = True) small_avatar = FileBrowseField (_ (u'Small Avatar '), max_length = 255, blank = True) def _big_avatar (obj): для e_f в obj. extended_fields. all (): вернуть e_f. big_avatar вернуть Нет. _big_avatar = _big_avatar Page. big_avatar = property (lambda u: u. _big_avatar ()) Для простоты я пропустил импорт, но вы можете проверить его в предыдущий пост Итак, теперь у меня есть «ярлык» для доступа к big_avatar, и пришло время сделать объект Page доступным в NavigationNode. из menus.base импортировать NavigationNode NavigationNode. page_instance = lambda u: Page. объекты . filter (pk = u. id) [0] Строка 2 определяет свойство ("page_instance"), которое возвращает объект Page на основе первичного ключа NavigationNode.id, равного соответствующему первичному ключу Page. Теперь вы можете использовать его в своих пользовательских шаблонах навигации следующим образом. {% для ребенка в детях%} {{child. страница_экземпляр big_avatar}} {% endfor%}

Заключительные слова: я должен признаться, что я действительно поражен тем, как просто все можно сделать в Джанго а также Джанго CMS , Это действительно потрясающе. Я надеюсь, что вы найдете этот пост действительно полезным и полезным. И, как всегда, не бойтесь предложить лучшее решение или попросить более глубокого объяснения, если что-то недостаточно ясно.

... или как добавить некоторые поля к модели страницы в админке без изменения Джанго CMS ядро

Проблема: иногда модели Пейдж просто не хватает того, что вам нужно. В моем случае это были «аватары страниц». Короче говоря - мне нужно изображение / аватар для каждой страницы в моей CMS. Поэтому мне нужно было добавить в модель страницы поле, в котором будет храниться информация о пути к аватару.

Специальность: Конечно, самым простым решением было просто отредактировать файл (pagemodel.py), содержащий модель страницы. К сожалению, в общем случае (и в моем тоже) несколько разных приложений находятся на одном сервере и используют одну и ту же CMS Django. Таким образом, изменение кода ядра неудобно, поскольку каждое его изменение будет влиять на все приложения, использующие одно и то же ядро ​​CMS. И что? Копировать целые файлы Django CMS в мое приложение и изменять их? Это тоже не похоже на хорошее решение. К счастью, есть простой способ сделать это и оставить основной код без изменений.

Решение. Сначала необходимо создать новую модель, которая будет содержать новые необходимые поля и внешний ключ к модели страницы.

из django.db импортировать модели из django.utils.translation импортировать ugettext_lazy как _ из cms.models.pagemodel импортировать страницу из filebrowser.fields импортировать FileBrowseField как класс FBF PageAvatars (models. Model): page = models. ForeignKey (Page, unique = True, verbose_name = _ ("Page"), редактируемый = False, related_name = 'extended_fields') big_avatar = FBF (_ (u'Big Avatar '), max_length = 255, пусто = True) small_avatar = FBF (_ (u'Small Avatar '), max_length = 255, blank = True) После того, как вы определили модель, пришло время сделать администратора. из extended_pages.models. Импорт PageAvatars из cms.admin.pageadmin. Импорт PageAdmin из cms.models.pagemodel. Импорт страницы из django.contrib. Импорт класса администратора PageAvatarsAdmin (admin. TabularInline): model = PageAvatars PageAdmin. встроенные Приложение (PageAvatarsAdmin) админ. сайт. отменить регистрацию. сайт. зарегистрироваться (Page, PageAdmin)
Последние две строки (11 и 12) используются, чтобы заставить Django перезагрузить администратора модели Page.
Теперь у вас есть новое поле в качестве встроенного в администраторе страницы.

Заключительные слова: Как видите, решение простое, быстрое и основной код не подвержен влиянию. Существует уникальное ограничение для поля страницы в модели PageAvatars, поэтому вы не сможете добавить более одного аватара на страницу.
Если в коде есть что-то непонятное или у вас есть идея получше, я готов это услышать.