wagtail | A Django content management system focused on flexibility and user experience | Content Management System library

You didn't mention wagtail versions or if this is an upgrade. But that error sounds like this: https://docs.wagtail.org/en/stable/releases/2.11.3.html#run-before-declaration-needed-in-initial-homepage-migration

This is going to be quite difficult, since in current Wagtail versions (>=2.13) the StreamField editing UI is populated client-side in Javascript - as such, there are some extra steps to make the necessary data available to the client-side code, and the standard Django form / template mechanisms won't be available.

A simple workaround, if the fields aren't too long, would be to define the snippet's __str__ method to include the desired data - this will then display any time the snippet is shown in the admin.

For a full solution, I'd suggest this approach:

• Set up a custom form_template for your StructBlock as detailed in Custom editing interfaces for StructBlock, with placeholder

  elements to contain your additional data.

• Override the StructBlock's get_form_state so that the returned dict (which will be used to populate the form template on the client side) includes your additional fields - something like:

The include(wagtail_urls) pulls in Wagtail's page handling logic for selecting which page should be returned for a given URL. If you swap that line out with your own code, you're effectively swapping out all of Wagtail...

First, consider whether you're reinventing the page privacy feature that Wagtail already provides. If you want the site as a whole to require a login, and non-logged-in users to be given a blanket generic login form, you can enable this using the Privacy control under the Settings tab (or in the top right corner on older Wagtail releases) when editing the homepage, and set WAGTAIL_FRONTEND_LOGIN_TEMPLATE = "home/not_authenticated.html" in your project settings file.

If you just want to swap the template for the homepage specifically, you can do that by defining a get_template method on your HomePage model:

This is a result of the Django template language's auto-escaping behaviour, and can be overridden by adding a |safe filter:

Below is how I organize templates and static assets. I have a themes folder that is located in the main project folder with named theme subfolders within the themes folder. I then have the following in settings/base.py:

The after_create_page hook doesn't work for this, as it's one of the last things to run during the Wagtail admin's page creation view, and the confirmation message (including the old URL) has already been constructed by that point. This can be remedied by using the post_save signal provided by Django instead - being a more low-level mechanism, it's more closely tied to the act of saving the database record, without Wagtail's admin logic getting in the way.

(It's also a bit more future-proof: Wagtail's after_create_page hook is designed to only be called when a user goes through the page creation area of the Wagtail admin, so that it can be used to customise that user's path through the admin if appropriate. If there's ever any other route by which a page might be created - like, say, a data import, or using translation tools for a multi-language site - then after_create_page will be bypassed, but the post_save signal will still be triggered.)

Assuming your project has a properties app where you're defining a PropertyPage model, your code can be rewritten to use post_save as follows - in properties/signals.py:

Every block type has a corresponding 'native' data type for the data it expects to work with - for the simpler blocks, this data type is what you'd expect (e.g. a string for CharBlock, an Image instance for ImageChooserBlock) but for a few of the more complex ones, there's a custom type defined:

• for RichTextBlock, the native type is wagtail.core.rich_text.RichText (which behaves similarly to a string, but also has a source property where e.g. page IDs in page links are kept intact)
• for StreamBlock, the native type is wagtail.core.blocks.StreamValue (a sequence type, where each item is a StreamValue with block_type and value properties).

The render method will generally be quite forgiving if you use the wrong types (such as a string for RichTextBlock or a list of dicts for StreamBlock), since it's really just invoking your own template code. The clean method will be more picky, since it's running Python logic specific to each block.

Unfortunately the correct types to use for each block aren't really formally documented, and some of them are quite fiddly to construct (e.g. a StructValue needs to be passed a reference to the corresponding StructBlock) - outside of test code, there isn't much need to create these objects from scratch, because the data will usually be coming from some outside source instead (e.g. a form submission or the database), and each block will be responsible for converting that to its native type.

With that in mind, I'd recommend that you construct your data by piggybacking on the to_python method, which converts the JSON representation as stored in the database (consisting of just simple Python data types - integers, strings, lists, dicts) into the native data types:

Images in Wagtail don't use WagtailAdminModelForm or the base_form_class attribute - these are used by pages, snippets and ModelAdmin to support Wagtail-specific features like inline children and panels, but images work through plain Django models and forms.

You can customise the form by subclassing BaseImageForm and setting WAGTAILIMAGES_IMAGE_FORM_BASE in your project settings. As long as you define your form class somewhere outside of models.py (e.g. in a separate forms.py module), you'll avoid the circular dependency that leads to the "Models aren't loaded yet" error.

The errors in the browser console show that the Javascript files included in the wagtail.contrib.table_block app are not loading. Most likely, these are missing from your S3 file hosting (S3 returns 403 Forbidden for missing files).

After adding wagtail.contrib.table_block to INSTALLED_APPS and deploying to your server, you'll need to re-run ./manage.py collectstatic to ensure these JS files are uploaded to S3.