Создание Sitemap.xml для Django-проектов


Разработка на языке Python 3 (для web-приложений используем Django Framework) Хостинг провайдеры (обзоры, бесплатный хостинг, облачный хостинг) Мое портфолио, сертификаты и разработки
blog cms cv django https sitemap web xml
 
 

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


(последние правки 1 месяц)

Для чего нужен файл sitemap.xml я думаю объяснять не стоит и все кто знаком с web-разработкой понимают, что этот файл так же важен как и robots.txt. Если вы используете полноценную CMS, то там за вас всю работу уже проделали и например в Django CMS поддержка Sitemap.xml и Robots.txt есть что называется из коробки, но в чистых Django Framework-проектах все эти операции придется проделать самостоятельно.

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

Давайте рассмотрим пример файла sitemap.xml из википедии:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="https://www.sitemaps.org/schemas/sitemap/0.9">
   <url>
      <loc>http://example.com/</loc>
      <lastmod>2013-11-18</lastmod>
      <changefreq>monthly</changefreq>
      <priority>0.8</priority>
   </url>
</urlset>

В простейшем виде файл sitemap - это один файл содержащий набор <url>-записей для каждой страницы вашего сайта. У него есть основной атрибут <loc> - полный URL-страницы и необязательные параметры lastmod/changefreq/priority. Более подробно про каждый из параметров вы можете прочитать в той же википедии (https://ru.wikipedia.org/wiki/Sitemaps), а нас интересует практика и поэтому погнали.

Если вы следуете стандартной MVC-модели Django, то у вас наверняка есть несколько объектов которые описывают все типовые страницы вашего проекта и несколько страниц которые отдельно, поэтому лочично, что нам надо как-то передать информацию о SLUG и прочих атрибутах в Sitemap.xml.

Прежде всего импортируйте объект Sitemap из набора которых мы и будем строить Sitemap.xml для нашего сайта.

from django.contrib.sitemaps import Sitemap

Следующим этапом создаем класс потомок от этого объекта (вот рабочий пример):

class BlogPostSitemap(Sitemap):
  changefreq = "daily"
  priority = 0.9

  def items(self):
    return BlogPost.objects.filter(record_active=True, is_category = False)
   
  def location(self, obj):
    return '/blog/'+obj.slug+'/'

  def lastmod(self, obj):
    return obj.last_modify_date

Как вы видите функция items(self) возвращает отфильтрованный набор элементов которые будут использованы для построения этого блока sitemap.xml и именно эти элементы необходимо трансформировать в набор параметров для блока <url>. Как вы видите мы задали для блока blog статичные параметры для:

changefreq = "daily"
priority = 0.9

И теперь самое интересное. Мы создаем представления для элементов location и lastmod исходя из полей объектов переданных в items (наши отфильтрованные):

def location(self, obj):
   return '/blog/'+obj.slug+'/'

def lastmod(self, obj):
   return obj.last_modify_date

В итоге, получается примерно вот так.

Ок, думаю как из объекта сделать кусок файла Sitemap.xml вы теперь поняли, но у вас наверное появился вопрос, что делать со страницами для которых не предусмотрен собственный объект (разного рода статичные лэндинги и т.п.). В принципе ничего сложного и я например создаю массив статических страниц:

static_links = [{'url':'/','last_mod':datetime.datetime(2018, 8, 2, 0, 0)},
        {'url':'/skillz/','last_mod':datetime.datetime(2018, 8, 2, 0, 0)},
        {'url':'/blog/','last_mod':datetime.datetime(2018, 2, 8, 0, 0)},]

И просто передаю его как items все тому же объекту Sitemap:

class StaticSitemap(Sitemap):
  changefreq = "weekly"
  priority = 0.5

  def items(self):
    return static_links
   
  def location(self, obj):
    return obj['url']

  def lastmod(self, obj):
    return obj['last_mod']

Кажется, все круто и у нас есть пачка объектов каждый из которых описывает свой блок sitemap, но возникает вопрос, а как теперь сделать, чтобы склеенные объекты отображались при запросе http://<url-сайт>/sitemap.xml.

Во первых, в файл settings.py в раздел INSTALLED_APPS необходимо добавить приложение:

INSTALLED_APPS = [
  'django.contrib.auth',
  'django.contrib.contenttypes',
  'django.contrib.sessions',
  'django.contrib.messages',
  'django.contrib.staticfiles',
  'django.contrib.sitemaps',
  'admin',   
  ...

Во вторых, в файл urls.py мы импортируем все наши объекты унаследованные от Sitemap:

from blog.sitemap_models import BlogPostSitemap, StaticSitemap

В блок urlpatterns = [ добавляем соответственно запись:

path('sitemap.xml', sitemap, {'sitemaps': {'blog':BlogPostSitemap,'static':StaticSitemap,}}, name='django.contrib.sitemaps.views.sitemap'),

Как вы наверное догадались, мы передали наши объекты в виде пар ключ значение записью:

{'sitemaps': {'blog':BlogPostSitemap,'static':StaticSitemap,}},

В чистом виде этого вполне достаточно, а разного рода нюансы можно почитать в официальной документации.

Моя официальная страница на FaceBook
Мой микроблог в твиттер

Запуск Web-приложений Django в Production-режиме (UWSGI/Nginx)

Запуск Web-приложений Django в Production-режиме (UWSGI/Nginx)

Django-приложения довольно сильно отличаются от php-приложений как структурой проекта, так и методом запуска.  Django-приложения по методу запуска больше похожи на Java, чем на PHP и классические ASP-проекты. Сегодня мы будем строить классическую связку из python-приложения и web-сервера Nginx обслуживающего реверс-проксирование запросов к приложению и предоставление файлов из каталогов media и static. LXC-изоляция в моем случае используется для поддержания python-окружения проекта и именно таким способом я предпочитаю изолировать проекты, а виртуальное окружение я предпочитаю не использовать, так как пару раз уже были проблемы при переносе Django-проектов.


Отправка оповещений Django-приложения в приватный чат Rocket.Chat

Отправка оповещений Django-приложения в приватный чат Rocket.Chat

Вчера я подумал, что если я все же вернулся к использованию Rocket.Chat и он меня уже не так бесит как предыдущие версии, то можно настроить систему оповещений о событиях на сайте и сбоях в работе Django-приложения в приватный чат Rocket.Chat. Для Python быстро нашелся вполне работоспособный модуль который идеально подошел для отправки сообщений в приватные чаты.


Создание и публикация Django-приложения (Часть первая, создание типового Django-приложения)

Создание и публикация Django-приложения (Часть первая, создание типового Django-приложения)

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


Использование jQuery Ajax для отправки данных Django-форм без обновления WEB-страницы

Использование jQuery Ajax для отправки данных Django-форм без обновления WEB-страницы

Я последнее время довольно активно использую Java Script в своих проектах. 21-ый век все таки на дворе и надо соответствовать. Хотя почему то считается, что использовать чистый Ajax для работы с формами не стоит и необходимо предоставить возможность работы и с перезагрузкой страницы, но мне кажется, что врят ли сейчас кто-то пользуется IE6, ну и если и пользуется, это его персональное горе.


Логирование ошибок в Django-проекте на боевом сервере

Логирование ошибок в Django-проекте на боевом сервере

Как вы наверное знаете у Django Framework имеется отличная система отладки и вывода отладочной информации при ошибке WEB-приложения и включается режим отладки простым DEBUG = True. Естественно, что на продакшн (боевых) сервера такое поведение недопустимо и в случае сбоя клиенту отображается лишь страница 500 с соответствующим кодом возврата и конечно клиенту этого вполне достаточно, но нам то необходимо оперативно отреагировать на сбой web-приложения и принять меры.


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


Есть вопросы?
Спрашивайте и я обязательно вам отвечу!

* Поля обязательные для заполнения .