Edited at

Wagtailのすすめ(1) DjangoベースのCMSを比較・検討してWagtailを選択した話


はじめに

何年か前に,webインタラクションやシリアスゲーム実験などのために自前のサイトがあれば便利だなと思いたち,ベースとなるCMSについての情報収集を始めた.ラボにはDjangoが根付いてきていたので,条件は,DjangoベースのCMSであること,そして,他の自作のDjangoアプリとの連携が容易なことである.

少し調べてみて,すぐに,Djangoベースの主なCMSは,

の3つであることがわかった.

Django-CMSは,CMSとしての完成度は高そうだけど,細かなカスタマイズが難しそうだったため最初に候補から外れた.Mezzanineは,WordPressと似ていて馴染みやすく,機能も充実しており,ある程度カスタマイズもできそうだった.それで,Mezzanineを選ぼうかとも考えたんだけど,Wagtailを触ってみて,その柔軟性の高さに驚き,すぐにそちらに心変わりした.

目的や嗜好によってどれが適しているかは変わると思うけれど,少なくとも自分にはWagtailがぴったりだった(ので,是非オススメしたい).本稿では,自分のための備忘録も兼ねて,Wagtailの基礎知識を整理しておこうと思う.


Wagtailとは

WagtailはDjangoベースのCMSライブラリの1つで,サイトを構築するために自分で書かなければならないコードは他の類似のライブラリと比べると多くなるが,その分,Djangoとのつながりがわかりやすく,カスタマイズしやすいという特長がある.

一方,ライブラリを利用せずに,純粋にDjangoのみでサイトを構築する場合と比べると,Wagtailを上にかぶせるメリットとして,すぐに思いつくものだけでも,次のような点が挙げられる.


  • Wagtailの管理サイトでウェブページのコンテンツを編集できる

  • その際に,リッチテキストエディタが利用できる

  • 下書き,公開など,ページの状態を管理できる

  • ページがツリー構造に整理されており,それに沿ってurlルーティングが自動的に行われる(標準的な使い方ではurls.pyの編集は不要)

  • ページはview関数を介さずにテンプレートに対応付けられている(標準的な使い方ではviews.pyの編集は不要)

  • Wagtailの管理サイトで画像も簡単に管理できる

  • 画像をページに含める際のサイズ調整などのちょっとした操作がテンプレートタグだけで処理できる


はじめの一歩

公式ドキュメントの説明に従ってWagtailをインストールしたとする.サイトを構築するには,最初に次のコマンドを打ち込む.

$ mkdir mysite

$ cd mysite
$ wagtail start config .

3行目のコマンドは,

$ django-admin.py startproject config .

を拡張したものである.これによって,mysiteディレクトリの中にconfigという名称のDjangoのプロジェクトが作成され,homeとsearchという2つのアプリケーションがデフォルトで追加される.また,settingsはファイル(pythonモジュール)からディレクトリ(pythonパッケージ)に変更される.

続いて,自作のページを定義していくために,それ用のアプリケーションを追加する.アプリケーションの追加の仕方は素のDjangoと同じである(cmsはアプリケーションの名称).

$ python manage.py startapp cms

この段階で,ディレクトリ構成は次のようになる.

mysite/

manage.py
cms/
__init__.py
admin.py
apps.py
models.py
tests.py
views.py
migrations/
__init__.py
templates/ *
cms/ *
home/
__init__.py
models.py
migrations/
__init__.py
templates/
home/
home_page.html
config/
__init__.py
urls.py
wsgi.py
settings/
__init__.py
base.py
dev.py
production.py
static/
css/
config.css
js/
config.js
templates/
404.html
500.html
base.html
search/
__init__.py
views.py
templates/
search/
search.html

ただし,*のついた2つは手動で追加したものである.この段階でDjangoの開発用サーバを

$ python manage.py runserver

で立ち上げて,

http://localhost:8000/

にアクセスすると,簡単なWelcomeページが表示される.このページはどこから来たのだろう.

config/urls.pyをみてみると,urlルーティングは,

from search import views as search_views

urlpatterns = [
url(r'^django-admin/', admin.site.urls),
url(r'^admin/', include(wagtailadmin_urls)),
url(r'^documents/', include(wagtaildocs_urls)),
url(r'^search/$', search_views.search, name='search'),
url(r'', include(wagtail_urls)),
]

のようになっている.上から順にみていくと,djangoの管理サイトはdjango-admin/に割り当てられており,admin/にはWagtailの方の管理サイトが対応付けられていることがわかる.documents/は,pdfファイルなどのドキュメントをサーブするためにWagtailが利用するアドレスであり,search/には,searchアプリケーションのview関数search()が割り当てられている(このview関数は,search/views.pyの中に定義されている).

それら以外のアドレスはすべてinclude(wagtail_urls)で処理されている.ここでのルーティングは,基本的には,これから作成していくページ間のツリー構造に従って決められていく.初期状態では,home/models.pyにあるHomePageクラスのインスタンス(ページ)が1つだけ作成されており,上ではそのページが表示された.

この際に利用されたテンプレートが,home/templates/home/home_page.htmlである.例えば,このファイルを次のように書き換えてみると,それが確かめられる.

{% extends "base.html" %}

{% block content %}
<h1>Hello World!</h1>
{% endblock %}

なお,1行目は,このテンプレートがbase.htmlを拡張したものであることを示している.このbase.htmlは,config/templatesの中にあるので,確認しておこう.

HomePageはサイト全体の表紙ページのためのクラスである.home/models.pyをみればわかるように,現時点では,デフォルトのPageモデルから何ら拡張されていないが,実際にサイトを構築するときには必要に応じて拡張していくことになる.また,対応するテンプレートもあわせて修正していく.

表紙ページ以外のページのためのクラスは,通常,別のアプリケーションの中で定義していく.上の例では,cmsアプリケーションがそれにあたる.cms/models.pyにページのクラスを作成し,cms/templates/cmsの中に,それに対応するテンプレートを置く,というのが基本的な流れである.

実際のページ(ページクラスのインスタンス)の生成や,そのコンテンツの編集,ページ間のツリー構造の定義などは,Wagtailの管理サイトで行う.純粋なDjangoの場合,管理サイトの構成(何を編集できるようにするか)はcms/admin.pyなどの中で指定していたが,Wagtailの管理サイトの構成はcms/models.pyでページクラスを定義するときにあわせて指定する.

$ python manage.py createsuperuser

で管理者アカウントを作成して,

http://localhost:8000/admin/

でWagtailの管理サイトの感触を確認してみてほしい.


おわりに

今回は,DjangoベースのCMSライブラリ,Wagtailのはじめの一歩について紹介した.実際にサイトを構築するためにはまだ情報が不十分だと思うが,次回以降の記事で少しずつ補足していきたい.

さっと一通りイメージをつかみたい場合は,公式サイトのYour first Wagtail siteを作ってみるといいだろう.発展的な話題については,ここのチュートリアルがわかりやすいと思う.