wagtail.io | Source code of https : //wagtail.org/ | Web Site library

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 classname option adds the given string to the class="..." attribute on the panel's HTML within the editing interface. It does not affect the front-end rendering.

Since it's just a string, you can set any value you like there, but of course it will only have an effect if there's a corresponding CSS rule for it. full and title are the only documented styles provided by Wagtail itself, but it's possible to add your own custom styles via the insert_editor_css hook.

Don't replace the {% block content %}{% endblock %} line in base.html. This is the base template shared by all page types, so it should only contain things that are meaningful to all page types, like the </code> tag - the {% block content %} is a placeholder that the individual templates (blog_index_page.html and blog_page.html) will use to insert their own content. See Template inheritance for more explanation.

Wagtail's Chooser Modal system works a bit differently to a normal Django widget (Class used to render html content of a field), the widget itself mostly renders a button 'Choose Document' and the button then triggers a modal which is a separate view and template.

As you noted, the construct_document_chooser_queryset hook can limit the results shown in these modals but only with access to the request object of the page being viewed, not of the Widget used to trigger that modal.

There is a way to get some limited desired functionality but it will not work for search results and will not restrict any additional uploads to that file type.

• This block Class extends the DocumentChooserBlock and has a custom __init__ method that pulls out a kwarg accept and assigns it to the widget attrs.
• Django Widgets all have the ability to accept attrs and these are output on the rendered HTML element, our custom Block assigns the value we want to the widget so that other methods have access to it.
• This block can be used in the same way as any other block but will use a kwarg of accept' doc_block = SpecificDocumentChooserBlock(accept="svg,md") # uses accept kwarg
• You can confirm this is working by viewing the DOM (inspect element in the browser), just after the 'Choose a Document', there will be a hidden attribute with something like

Using Quote.objects.get(text__exact=row["text"].strip('"')) works. I expected Quote.objects.filter(text__exact=row["text"].strip('"')) to return 1 result and thought it should work but I was wrong.

I tested this in python manage.py shell and it worked.

The below solution is a way to leverage the Wagtail contrib form builder to add a field to the UI where CMS users can add custom classes and a placeholder field.

• It is assumed you have a working FormPage similar to the implementation in the Wagtail form builder docs.
• Firstly, you will need to add a new field to the FormField model, in the example below I have called this field_classname, remember to run Django migrations to update your DB.
• To ensure that the field shows up in the admin UI you will need to modify the panels, this is similar to modifying the panels in a Page model.
• At this point you should be able to open the Admin UI for a FormPage and see the new field and be able to save values to it.
• Next step is to add a custom FormBuilder class that extends the one that is normally used and then on your FormPage model set this as an attribute via form_builder, this is similar to how new fields can be added as described in the docs.
• This CustomFormBuilder will override the method get_create_field_function with a wrapper function that will return the generated field (which will be a Django Field instance).
• Each Field instance will be returned almost the same, except for an update to the widget attrs which is essentially a Dict that you can add anything to.
• IMPORTANT: Using the class attr will add the class name to the field but may not add it where you want, try this first though.
• Assuming you have more granular control of your template rending, you will need to pass this attr to the template for each field div that is rendered, in the code below I have used the same field_classname key.
• The critical change in the template is pulling out the widget attrs custom value set by our CustomFormBuilder ->

The docs section for the routablepageurl template tag is quite short and it can come across as a bit confusing due to it being quite densely packed with references to concepts in Wagtail and Django.

Let's unpack the line:

routablepageurl is similar to pageurl, but works with pages using RoutablePageMixin. It behaves like a hybrid between the built-in reverse, and pageurl from Wagtail.

• Firstly, this is a custom template tag which is a function that takes some known arguments/params in a specific order that can be made available to template tags. The important thing to note here is that context is something that gets passed into the template tag function call but you do not have to pass it in explicitly when using the template tag.
• Understanding this requires a bit of an understanding of how Django's URL system works and it would be good to read through the Django docs on this topic https://docs.djangoproject.com/en/3.2/topics/http/urls/
• pageurl here is a reference to a different template tag that has similar behaviour, you can view the docs for the pageurl template tag.
• routablePageMixin is a Page mixin that allows the use of multiple sub-page routes to be made available, each with a name with a decorator like @route(r'^past/$').
• Behaves like reverse is a reference to the django.urls.reverse function which takes a URL name and will return the URL. Reverse provides a way not only to get a URL based on a name but to pass arguments in that will build up the full URL based on those arguments.
• In all of these references, the concept of a name is also a Django concept where when you declare URL patterns (e.g. all 'blog/DD-MM-YYYY' pages) with a name to reference them elsewhere.

• context is provided by default for all template tag function calls.

• page is a modal instance, this would be the page that is using RoutablePageMixin.
• url_name is the name of the URL pattern as defined in your page, this can come across a bit unclear but it is the function name that is used to create the sub routes, in the code example below (from the docs), the url name will be current_events.

Both page and self are indeed valid when using the standard Django template engine. However, self is a reserved word in the Jinja2 template engine, so the documentation encourages page for consistency (and to make it easier for developers to switch to Jinja2 in future if they choose to).

For the record, here's the PR where the alternative variable name was introduced: https://github.com/wagtail/wagtail/pull/1571

The Page class is the base class of all page types in Wagtail, but normally it wouldn't be desirable to let users create pages that are of the type Page rather than something more specific, because there's no way to add new content fields to it. For this reason, the is_creatable attribute is set to false on Page, which means that new pages of that type can't be created through the admin interface. (This attribute is not inherited by subclasses, so any new page types you create will be is_creatable = True by default.)

The initial "Welcome" page is created as part of the migrations in the wagtail.core app. At this point, Page is the only page type that exists (since your HomePage model hasn't been defined yet), so that's the one Wagtail uses. It might seem a bit weird that the default page is not one that you can create yourself through the admin, but there's no real alternative (other than not providing a default page at all, which would make it harder for developers to see if their installation has worked).

(When setting up a brand new Wagtail project through wagtail start, the project template includes migrations to replace the initial Page instance with an instance of the supplied HomePage model, so in this case it's less confusing.)

After you defined your HomePage model, this became the only page type with is_creatable = True, and so the admin interface automatically selects this page type on adding a new page. When you add another page model alongside HomePage, you'll find that it prompts you to select a page type.