In normal use, Wagtail will generate resized versions of images at the point that they are referenced on a template, which means that those images are not easily accessible for use outside of Wagtail, such as displaying them on external sites. Wagtail now provides a way to obtain URLs to your images, at any size.

Urlconf entries for /admin/images/, /admin/embeds/ etc need to be removed¶

If you created a Wagtail project prior to the release of Wagtail 0.3, it is likely to contain the following entries in its urls.py:

# TODO: some way of getting wagtailimages to register itself within wagtailadmin so that we# don't have to define it separately hereurl(r'^admin/images/',include(wagtailimages_urls)),url(r'^admin/embeds/',include(wagtailembeds_urls)),url(r'^admin/documents/',include(wagtaildocs_admin_urls)),url(r'^admin/snippets/',include(wagtailsnippets_urls)),url(r'^admin/search/',include(wagtailsearch_admin_urls)),url(r'^admin/users/',include(wagtailusers_urls)),url(r'^admin/redirects/',include(wagtailredirects_urls)),

These entries (and the corresponding fromwagtail.wagtail*import... lines) need to be removed from urls.py. (The entry for /admin/ should be left in, however.)

Since Wagtail 0.3, the wagtailadmin module automatically takes care of registering these URL subpaths, so these entries are redundant, and these urlconf modules are not guaranteed to remain stable and backwards-compatible in future. Leaving these entries in place will now cause an ImproperlyConfigured exception to be thrown.

Several new fields have been added to the Image and Rendition models to support Feature Detection. These will be added to the database when you run ./manage.pymigrate. If you have defined a custom image model (by extending the wagtailimages.AbstractImage and wagtailimages.AbstractRendition classes and specifying WAGTAILIMAGES_IMAGE_MODEL in settings), the change needs to be applied to that model’s database table too. Running the command:

In preparation for Django 1.7 support in a future release, Wagtail now depends on South 1.0, and its migration files have been moved from migrations to south_migrations. Older versions of South will fail to find the migrations in the new location.

If your project’s requirements file (most commonly requirements.txt or requirements/base.txt) references a specific older version of South, this must be updated to South 1.0.