Развёртывание Wagtail

Статические файлы

Как и во всех проектах Django, статические файлы не обслуживаются сервером приложений Django в рабочей среде (т.е. вне manage.py runserver команды); их необходимо обрабатывать отдельно на уровне веб-сервера. См. документацию Django по развёртыванию статических файлов.

Файлы JavaScript и CSS, используемые административной панелью Wagtail, часто меняются между выпусками Wagtail — важно избегать подачи устаревших версий этих файлов из-за кэширования на стороне браузера или сервера, так как это может привести к трудно диагностируемым проблемам. Рекомендуем включить ManifestStaticFilesStorage в настройках STATICFILES_STORAGE — это гарантирует, что различным версиям файлов будут присвоены разные URL-адреса.

Файлы, загруженные пользователем

Wagtail следует конвенциям Django для управления загружаемыми файлами. Поэтому по умолчанию Wagtail использует встроенный класс Django FileSystemStorage, который хранит файлы на сервере сайта в каталоге, указанном в настройке MEDIA_ROOT. В качестве альтернативы, Wagtail можно настроить для хранения загруженных изображений и документов в облачной службе хранения, такой как Amazon S3; это делается через настройку DEFAULT_FILE_STORAGE в сочетании с пакетом дополнений, таким как django-storages.

При использовании FileSystemStorage, URL-адреса изображений формируются, начиная с пути, указанного в MEDIA_URL. В большинстве случаев вы должны настроить веб-сервер для непосредственного предоставления файлов изображений (без передачи через Django/Wagtail). При использовании одного из облачных хранилищ, ссылки на изображения ведут непосредственно к URL-адресу файла в облачном хранилище. Если вы хотите обслуживать изображения с отдельного сервера ресурсов или CDN, вы можете настроить представление image serve view для перенаправления вместо этого.

Обслуживание документов контролируется методом WAGTAILDOCS_SERVE_METHOD. При использовании FileSystemStorage, документы хранятся в подкаталоге documents в вашем каталоге сайта MEDIA_ROOT. Если все ваши документы публичны, вы можете установить WAGTAILDOCS_SERVE_METHOD на direct и настроить веб-сервер на непосредственное предоставление файлов. Однако, если вы используете настройки приватности Wagtail (настройки приватности коллекции), чтобы ограничить доступ к некоторым или всем документам, вам может или не может потребоваться настроить веб-сервер на прямое предоставление документов. Значение по умолчанию равно redirect, что позволяет Wagtail выполнять любые настроенные проверки приватности, прежде чем передать предоставление документа вашему веб-серверу или CDN. Это означает, что Wagtail создает ссылки на документы, которые проходят через Wagtail, но конечный URL в браузере пользователя обслуживается непосредственно вашим веб-сервером. Если это неприемлемо, вы можете установить WAGTAILDOCS_SERVE_METHOD на serve_view и настроить веб-сервер таким образом, чтобы он не предоставлял файлы документов сам. Если вы предоставляете документы из облака и вам нужно применить настройки приватности, убедитесь, что документы недоступны для публичного доступа через URL-адрес облачной службы.

Облачное хранилище

Помните, что настройка удалённого хранилища не полностью переложит задачи обработки файлов с сервера приложения — некоторые функции Wagtail требуют, чтобы файлы считывались обратно сервером приложения. В частности, оригинальные файлы изображений необходимо считывать обратно всякий раз, когда создаётся новая изменённая версия, и документы могут быть настроены на обслуживание через представление Django для применения проверок разрешений (см. WAGTAILDOCS_SERVE_METHOD).

Обратите внимание, что модули django-storages Amazon S3 (storages.backends.s3boto.S3BotoStorage и storages.backends.s3boto3.S3Boto3Storage) не обрабатывают правильно дублирующиеся имена файлов в своей конфигурации по умолчанию. При использовании этих модулей, AWS_S3_FILE_OVERWRITE должно быть установлено на False.

Если вы также предоставляете статические файлы Wagtail из удалённого хранилища (используя настройку Django STATICFILES_STORAGE), вам необходимо убедиться, что оно настроено на предоставление HTTP-заголовков CORS, так как текущие браузеры отклонят файлы шрифтов, размещённые удалённо, без соответствующего заголовка. Для Amazon S3 см. документацию Установление разрешений доступа к ведру и объектам, или (только для модуля storages.backends.s3boto.S3Boto3Storage): добавьте следующее в настройки Django:

AWS_S3_OBJECT_PARAMETERS = {
    "ACL": "public-read"
}

Параметр ACL принимает список предопределённых конфигураций для Amazon S3. Более подробную информацию можно найти в документации Canned ACL.

Для Google Cloud Storage создайте конфигурацию cors.json.

[
    {
      "origin": ["*"],
      "responseHeader": ["Content-Type"],
      "method": ["GET"],
      "maxAgeSeconds": 3600
    }
]

Затем примените эту конфигурацию CORS к ведру хранилища:

gsutil cors set cors.json gs://$GS_BUCKET_NAME

Для других облачных хранилищ см. документацию вашего провайдера или документацию используемой вами библиотеки Django-хранилищ.