[WIP] Proxy page models

[kaedroho]

This PR includes some tweaks to Wagtail core to allow users to define new page types using proxy models instead of multi-table inheritance. The implementation is currently only for demonstration purposes (not much time).

There's two use-cases I think this would be useful for

• Defining new page types that extend another (which don't need model changes) without introducing a third level of MTI
• Creating page types that don't use multi-table inheritance at all (I can see this becoming much more useful when we introduce an abstract base page class)

Currently (Wagtail 1.1), if you define a proxy page model. Wagtail would add another entry into the "add subpage" view, except it's an exact duplicate of the parent class.

Implementation

To implement this, I've simply gone through wagtailcore/models.py and added for_concrete_model=False to each call to get_for_model. This fixes the issues with "add subpage" and allows pages to be created for these models.

By default, proxy models objects attribute returns all instances of their parent class, so I've added a ProxyPageManager which filters the pages to only include instances of the proxy model, emulating behaviour of multi-table inheritance. (this manager is currently forced on the proxy model, but I'd like to make this opt-in).

Example

Finally, here's the code I created to test this:

from django.db import models

from wagtail.wagtailcore.models import Page
from wagtail.wagtailadmin.edit_handlers import FieldPanel


class BlogEntryPage(Page):
    date = models.DateTimeField()
    body = models.TextField()

    content_panels = Page.content_panels + [
        FieldPanel('date'),
        FieldPanel('body'),
    ]


class AwesomeBlogEntryPage(BlogEntryPage):
    class Meta:
        proxy = True

Both content types can be created in the admin:

Pages appear to be two distinct types to the user:

And in the shell:

# Proxy models appear in their parent classes objects
>>> BlogEntryPage.objects.all()
[<BlogEntryPage: blog>, <BlogEntryPage: Awesome blog entry>]

# When using PageProxyManager, only instances of the proxy are included in the proxy models objects
>>> AwesomeBlogEntryPage.objects.all()
[<AwesomeBlogEntryPage: blog>]

Underneath, there is one database table for both models (they are told apart by the content_type field)

[balazs-endresz]

Calling .type(self.model) is not enough here because that will return all the objects for the concrete model. This does work however:

return super(ProxyPageManager, self).get_queryset().filter(content_type=ContentType.objects.get_for_model(self.model, for_concrete_model=False))

Or even PageQuerySet.type could take a for_concrete_models=False argument too, which would make it return proxy objects instead of concrete ones. And I wonder if returning proxy objects by default would make sense: I think that's what people would expect but might have some effects on some internal wagtail code (and it's not what django does by default either).

[kaedroho]

super().get_queryset() should return pages with the proxy model class and type(self.model) should filter them to only include items that are members of that proxy model.

But you're right, I missed for_concrete_models=False in the .type() implementation causing that type filter to select pages with the parent type (but still return instances of the proxy model).. Doh!

.type() just filters the queryset and cannot change the type. So for example, running Page.objects.type(BlogPage) will return a queryset of Page objects.

[kaedroho]

This could be used to simplify the page types rules with the root page. We could create a new RootPage model that is a proxy of Page (so no new table would be created). This would act as a marker for the "root" page in the tree. For example:

from wagtail.wagtailcore.models import Page, RootPage

class HomePage(Page):
    # Homepages can only be created at the root level
    parent_page_types = [RootPage]

[gasman]

This could be used to simplify the page types rules with the root page. We could create a new RootPage model that is a proxy of Page (so no new table would be created).

I like this idea! This fits nicely with the is_creatable = False mechanism to stop the new page type from cluttering up the 'add subpage' list - and unlike tinkering with the initial 'welcome' page, it's something we can do neatly in a migration without causing problems with existing sites.

I wonder if we're subverting the purpose of proxy models a bit here - if they're meant to be wrappers that you can freely apply to any instance of the concrete model, rather than an object specifically identifying itself as an instance of the proxy model. Clearly the latter works, though, and it's almost certainly the more useful behaviour for Wagtail to adopt (because allowing page types to appear as multiple types simultaneously is bound to create bigger problems) - so happy to go with this.

[jhrr]

Hi all, any update on if/when this feature might land?

[timonweb]

Any update on this? What kind of help may be needed here?

[robslotboom]

I’m playing with a proxy Page model in Wagtail 2.0.
To make it work I had to add the following code to the model class:

def __init__(self, *args, **kwargs):
    super().__init__(*args, **kwargs)
    if not self.id:
        content_type = ContentType.objects.get_for_model(self, for_concrete_model=False)
        self.content_type = content_type

[allcaps]

If anyone likes to push this further. TODO:

• Conflicts must be resolved
• Allow users to opt-in to using this manager (see comment in the code)
• Add tests
• Add docs

[probabble]

I'd be interested in helping to move this forward, it would be so nice to specify different Python behavior for pages without having to create new DB entities...

[robslotboom]

@allcaps

Can you tell me where the code can be found?

[allcaps]

@robslotboom https://github.com/kaedroho/wagtail/tree/proxy-page-models

[timonweb]

Any update?

[ababic]

Hi all. I just wanted to highlight that using for_concrete_model=False actually results in the creation of a new ContentType, which might not be desired.

I don't think this is such an issue for Page models, because the Django permission system isn't being used, but this does create a bit of an odd situation, where Permission objects exist for the proxy model, but remain tied to the concrete model's ContentType.

[ababic]

@kaedroho / @gasman, in relation to my last comment, I've created a new issue (#4973) that aims to provide a more consistent approach for supporting proxy models throughout (as pages, snippets, or other models registered via contrib.modeladmin). Would appreciate your thoughts on that.

[ababic]

Superseded by #5202

[brylie]

We could create a new RootPage model that is a proxy of Page (so no new table would be created). This would act as a marker for the "root" page in the tree.

@kaedroho and @gasman, I've incorporated this idea into RFC 68