wagtail/docs/reference/management_commands.md

(management_commands)=

Management commands

(wagtail_start)=

start

By default, the start command creates a project template, which contains your models.py, templates, and settings files. For example, to create new Wagtail project named mysite, use the command like this:

wagtail start mysite

You can also use the --template option with the start command to generate a custom template. See The project template for more information on how the command works with default and custom templates.

(publish_scheduled)=

publish_scheduled

./manage.py publish_scheduled

This command publishes, updates, or unpublishes objects that have had these actions scheduled by an editor. We recommend running this command once an hour.

(fixtree)=

fixtree

./manage.py fixtree

This command scans for errors in your database and attempts to fix any issues it finds.

(move_pages)=

move_pages

manage.py move_pages from to

This command moves a selection of pages from one section of the tree to another.

Options:

• from This is the id of the page to move pages from. All descendants of this page will be moved to the destination. After the operation is complete, this page will have no children.

• to This is the id of the page to move pages to.

(purge_revisions)=

purge_revisions

manage.py purge_revisions [--days=<number of days>] [--pages] [--non-pages]

This command deletes old revisions which are not in moderation, live, approved to go live, or the latest revision. If the days argument is supplied, only revisions older than the specified number of days will be deleted.

To prevent deleting important revisions when they become stale, you can refer to such revisions in a model using a ForeignKey with {attr}on_delete=models.PROTECT <django.db.models.PROTECT>.

If the pages argument is supplied, only revisions of page models will be deleted. If the non-pages argument is supplied, only revisions of non-page models will be deleted. If both or neither arguments are supplied, revisions of all models will be deleted. If deletion of a revision is not desirable, mark Revision with on_delete=models.PROTECT.

(purge_embeds)=

purge_embeds

manage.py purge_embeds

This command deletes all the cached embed objects from the database. It is recommended to run this command after changes are made to any embed settings so that subsequent embed usage does not from the database cache.

(update_index)=

update_index

./manage.py update_index [--backend <backend name>]

This command rebuilds the search index from scratch.

It is recommended to run this command once a week and at the following times:

• whenever any pages have been created through a script (after an import, for example)
• whenever any changes have been made to models or search configuration

The search may not return any results while this command is running, so avoid running it at peak times.

Specifying which backend to update

By default, update_index will rebuild all the search indexes listed in WAGTAILSEARCH_BACKENDS.

If you have multiple backends and would only like to update one of them, you can use the --backend option.

For example, to update just the default backend:

python manage.py update_index --backend default

The --chunk_size option can be used to set the size of chunks that are indexed at a time. This defaults to 1000 but may need to be reduced for larger document sizes.

Indexing the schema only

You can prevent the update_index command from indexing any data by using the --schema-only option:

python manage.py update_index --schema-only

Silencing the command

You can prevent logs to the console by providing --verbosity 0 as an argument:

python manage.py update_index --verbosity 0

If this is omitted or provided with any number above 0 it will produce the same logs.

(wagtail_update_index)=

wagtail_update_index

An alias for the update_index command that can be used when another installed package (such as Haystack) provides a command named update_index. In this case, the other package's entry in INSTALLED_APPS should appear above wagtail.search so that its update_index command takes precedence over Wagtail's.

rebuild_references_index

./manage.py rebuild_references_index

This command populates the table that tracks cross-references between objects, used for the usage reports on images, documents, and snippets. This table is updated automatically saving objects, but it is recommended to run this command periodically to ensure that the data remains consistent.

Silencing the command

You can prevent logs to the console by providing --verbosity 0 as an argument:

python manage.py rebuild_references_index --verbosity 0

show_references_index

./manage.py show_references_index

Displays a summary of the contents of the references index. This shows the number of objects indexed against each model type and can be useful to identify which models are being indexed without rebuilding the index itself.

(wagtail_update_image_renditions)=

wagtail_update_image_renditions

./manage.py wagtail_update_image_renditions

This command provides the ability to regenerate image renditions. This is useful if you have deployed to a server where the image renditions have not yet been generated or you have changed the underlying image rendition behavior and need to ensure all renditions are created again.

This does not remove unused rendition images, this can be done by clearing the folder using rm -rf or similar, once this is done you can then use the management command to generate the renditions.

Options:

• --purge-only : This argument will purge all image renditions without regenerating them. They will be regenerated when next requested.

(convert_mariadb_uuids)=

convert_mariadb_uuids

./manage.py convert_mariadb_uuids

For sites using MariaDB, this command must be run once when upgrading to Django 5.0 and MariaDB 10.7 from any earlier version of Django or MariaDB. This is necessary because Django 5.0 introduces support for MariaDB's native UUID type, breaking backwards compatibility with CHAR-based UUIDs used in earlier versions of Django and MariaDB. New sites created under Django 5.0+ and MariaDB 10.7+ are unaffected.