5

My team and I have created a section to allow our company to add landing pages. We'd like to include some additional columns to the index view of the associated model, as illustrated in this image.

Custom index view

I've found a few old posts (2014-ish) that indicate this wasn't possible, but I can't find anything newer that makes that claim invalid. Is it possible to do this, and if so can someone point me in the right direction?

commadelimited
  • 5,656
  • 6
  • 41
  • 77

2 Answers2

1

You can do this with ModelAdmin for a specific model, but it won't appear in the Pages Explorer view as in your screenshot. Instead, it will appear in a new menu item on the left sidebar. I also find that Hooks is a great place to store this logic. Just be aware of how ModelAdmin differs from modeladmin. The Bakery Demo has some good examples of how this all works.

Preston Horn
  • 231
  • 2
  • 9
  • Preston, this is good information. I actually have a working implementation using ModelAdmin. I like that it shows up in the left nav, but the display for the listing isn't as full bodied as the standard list. Thanks! – commadelimited Jun 13 '19 at 19:12
1

If you are willing to patch the view and template for the Page Explorer, you should be able to do this. My group isn't patching the Page Explorer so I don't have example code for that but our general approach is as follows:

  1. We have a django app called wagtail_patches which is listed in our INSTALLED_APPS before the wagtail apps.
  2. In wagtail_patches/apps.py we have:

    from django.apps import AppConfig
    
    class WagtailPatchesConfig(AppConfig):
        name = 'wagtail_patches'
        verbose_name = 'Wagtail Patches'
        ready_is_done = False
    
        def ready(self):
            """
            This function runs as soon as the app is loaded. It executes our monkey patches to various parts of Wagtail
            that change it to support our architecture of fully separated tenants.
            """
            # As suggested by the Django docs, we need to make absolutely certain that this code runs only once.
            if not self.ready_is_done:
                # The act of performing this import executes all the code in monkey_patches.
                from . import monkey_patches  
                # Unlike monkey_patches, the code of wagtail_hook_patches is in the function patch_hooks().
                from .wagtail_hook_patches import patch_hooks
                patch_hooks()
    
                self.ready_is_done = True
            else:
                print("{}.ready() executed more than once! This method's code is skipped on subsequent runs.".format(
                    self.__class__.__name__
                ))
    
  3. Then in wagtail_patches/monkey_patches.py we import the module to be patched, then write a new method, and then replace the stock version with the new method. For example:

    from wagtail.admin.forms.collections import CollectionForm
    def collection_form_clean_name(self):
        if <weird custom condition>:
            raise ValidationError('some error message')
    CollectionForm.clean_name = collection_form_clean_name
    
  4. Overriding templates is just like normal django template overriding, place your customized version of some file in a folder hierarchy matching it's usual position within Wagtail.
cnk
  • 981
  • 1
  • 5
  • 9
  • Interesting approach. Preston mentioned the ModelAdmin approach, and we got that working, but it's not quite what we were hoping for. That said, the monkey patch approach is a clever idea, and one I'm not opposed to. Thanks for the suggestion! – commadelimited Jun 13 '19 at 19:19
  • We have some models we manage as models with ModelAdmin but for most things we want to have the data in pages because that automatically gives you publish/unpublish and revision history - in addition to ways to display as a web page. – cnk Jun 14 '19 at 21:40