Snippets generalisation: bringing features from SnippetViewSet into generic ViewSet/ModelViewSet

[laymonage]

As a continuation of RFC 85: Snippets parity with ModelAdmin and following the discussion on Wagtail Slack, there are concerns about how Snippets is replacing ModelAdmin, yet the term "snippet" doesn't always fit all models.

From the docs:

Snippets are pieces of content which do not necessitate a full webpage to render. They could be used for making secondary content, such as headers, footers, and sidebars, editable in the Wagtail admin. Snippets are Django models which do not inherit the Page class and are thus not organised into the Wagtail tree. However, they can still be made editable by assigning panels and identifying the model as a snippet with the register_snippet class decorator or function.

Models such as "shopping cart orders", "feedback submissions", "taxonomies", and other descriptive data do not really fit the above description. However, it still makes sense to manage these models in the Wagtail admin.

As @ababic put it:

I’m fully on-board with the old code being removed, but I do think Wagtail needs some version of modeladmin to cater for these scenarios... Even if it’s just a ‘slightly more generic’ version of the snippet view/chooser code that

• Puts a menu item at the top level
• Doesn’t list the model on the ‘Snippet index’ page
• Gives URLS their own namespace
• Has a similar (but separate) registration mechanism.

Meanwhile, Wagtail has a generic ModelViewSet that can be used to build basic CRUD views in the admin. The ModelViewSet class is built on top of the base ViewSet class, which is "Wagtail’s mechanism for defining a group of related admin views with shared properties, as a single unit".

In fact, as of #10294, SnippetViewSet is now a subclass of ModelViewSet. That said, most of the features for Snippets (including the ones listed by Andy) are implemented in SnippetViewSet, which makes it necessary to register the models as snippets in order to use the features.

To solve this problem, we have two main options:

• Rename the term "Snippets" to something else (as raised by Tom Usher).
• Move code that is not snippets-specific from SnippetViewSet to ModelViewSet, and providing a similar registration mechanism.

As the term "snippet" is used in code and the admin interface, renaming it is non-trivial and will likely require a transitional period. The second option is much more feasible, and allows us to have the separation between the current "snippet" concept and models in general, while still avoiding code duplication. It also doesn't keep us from dropping/renaming the term "snippet" in the future.

Hence, this discussion proposes that we start "lifting" the code from SnippetViewSet to the ModelViewSet, or even the base ViewSet class. The discussion will be broken down into these sections:

• Features that could be in the base ViewSet
• Features that could be in ModelViewSet without requiring mixins on the model
• Features that could potentially be in ModelViewSet but depend on mixins applied on the model
• Other things to be considered
• Conclusion

To be in base ViewSet

The following are features in SnippetViewSet that we could bring to ModelViewSet or potentially base ViewSet. These can be useful even for non-model based ViewSets, though we currently don't have any that's built-in:

Admin URL configuration

Relevant snippets PR: #10235.

This concerns the customisation of the URL namespace that's used when doing reverse(), e.g. myownmodel:edit instead of wagtailsnippets_myapp_mymodel:edit, and the base path in the admin, e.g. /admin/myownmodel/ instead of /admin/snippets/myapp/mymodel/.

The base ViewSet class (and by extension ModelViewSet) already supports this, but it's done during the instantiation of the class. On SnippetViewSet, you can customise this using class attributes. See:

wagtail/wagtail/snippets/views/snippets.py

Lines 1364 to 1377 in 801eccc

	def get_admin_url_namespace(self):
	"""Returns the URL namespace for the admin URLs for this model."""
	if self.admin_url_namespace:
	return self.admin_url_namespace
	return f"wagtailsnippets_{self.app_label}_{self.model_name}"
	def get_admin_base_path(self):
	"""
	Returns the base path for the admin URLs for this model.
	The returned string must not begin or end with a slash.
	"""
	if self.base_url_path:
	return self.base_url_path.strip().strip("/")
	return f"snippets/{self.app_label}/{self.model_name}"

wagtail/wagtail/snippets/views/snippets.py

Lines 852 to 856 in 801eccc

	super().__init__(
	name=self.get_admin_url_namespace(),
	url_prefix=self.get_admin_base_path(),
	**kwargs,
	)

If we want to add the same support, we'll likely need to change ViewSet.__init__'s signature:

wagtail/wagtail/admin/viewsets/base.py

Lines 12 to 14 in 801eccc

	def __init__(self, name, **kwargs):
	self.name = name
	self.url_prefix = kwargs.pop("url_prefix", self.name)

So that both name and url_prefix are optional, or at least fall back to the same methods/attributes used on the SnippetViewSet. See the "Viewset registration" section much further in this discussion for more details.

Menu registration

Relevant snippets PR: #10330.

Menu-related methods and properties

We need to move the following methods and properties to the base ModelViewSet class if we want to allow a quick way to register a menu item for the model. This might be useful if people create a custom ViewSet subclass that does not rely on a model, so it seems to make sense to put this in the base ViewSet class instead.

wagtail/wagtail/snippets/views/snippets.py

Lines 1232 to 1275 in 801eccc

	def get_menu_label(self):
	"""Returns the label text to be used for the menu item."""
	return self.menu_label or self.model_opts.verbose_name_plural.title()
	def get_menu_name(self):
	"""Returns the name to be used for the menu item."""
	return self.menu_name
	def get_menu_icon(self):
	"""Returns the icon to be used for the menu item."""
	return self.get_icon()
	def get_menu_order(self):
	"""Returns the ordering number to be applied to the menu item."""
	# By default, put it at the last item before Reports, whose order is 9000.
	return self.menu_order or 8999
	@property
	def menu_item_class(self):
	def is_shown(_self, request):
	return self.permission_policy.user_has_any_permission(
	request.user, ("add", "change", "delete")
	)
	return type(
	f"{self.model.__name__}MenuItem",
	(MenuItem,),
	{"is_shown": is_shown},
	)
	def get_menu_item(self, order=None):
	"""
	Returns a ``MenuItem`` instance to be registered with the Wagtail admin.
	The ``order`` parameter allows the method to be called from the outside (e.g.
	:class:`SnippetViewSetGroup`) to create a sub menu item with the correct order.
	"""
	return self.menu_item_class(
	label=self.get_menu_label(),
	url=reverse(self.get_url_name("index")),
	name=self.get_menu_name(),
	icon_name=self.get_menu_icon(),
	order=order or self.get_menu_order(),
	)

wagtail/wagtail/snippets/views/snippets.py

Lines 1552 to 1556 in 801eccc

	def register_menu_item(self):
	if self.add_to_settings_menu:
	hooks.register("register_settings_menu_item", self.get_menu_item)
	elif self.add_to_admin_menu:
	hooks.register("register_admin_menu_item", self.get_menu_item)

Note

If moved to base ViewSet, it may not make sense for ChooserViewSet to inherit these methods.

For register_menu_item, it's probably useful to make the hook name configurable (defaults to "register_admin_menu_item"), so it can be put in other top-level menu e.g. the help menu item.

Generic ViewSetGroup

It would be nice to turn SnippetViewSetGroup (if you're not familiar, think ModelAdminGroup) into a generic ViewSetGroup that works with any ViewSets (maybe except ChooserViewSets) to ease registration of viewsets under a single top-level menu item.

wagtail/wagtail/snippets/views/snippets.py

Lines 1568 to 1657 in 801eccc

	class SnippetViewSetGroup:
	"""
	A container for grouping together multiple SnippetViewSet instances. Creates
	a menu item with a submenu for accessing the listing pages of those instances.
	"""
	#: A list or tuple of :class:`SnippetViewSet` classes to be grouped together
	items = ()
	#: Register a custom menu item for the group in the admin's main menu.
	add_to_admin_menu = True
	# Undocumented for now, but it is technically possible to register the group's
	# menu item in the Settings menu instead of the main menu.
	add_to_settings_menu = False
	#: The icon used for the menu item that appears in Wagtail's sidebar.
	menu_icon = None
	#: The displayed label used for the menu item.
	#: If unset, the title-cased version of the first model's :attr:`~django.db.models.Options.app_label` will be used.
	menu_label = None
	#: The ``name`` argument passed to the ``MenuItem`` constructor, becoming the ``name`` attribute value for that instance.
	#: This can be useful when manipulating the menu items in a custom menu hook, e.g. :ref:`construct_main_menu`.
	#: If unset, a slugified version of the label is used.
	menu_name = None
	#: An integer determining the order of the menu item, 0 being the first place.
	menu_order = None
	def __init__(self):
	"""
	When initialising, instantiate the classes within 'items', and assign
	the instances to a ``viewsets`` attribute.
	"""
	self.viewsets = [
	viewset_class(menu_item_is_registered=True) for viewset_class in self.items
	]
	def get_app_label_from_subitems(self):
	for instance in self.viewsets:
	return instance.app_label.title()
	return ""
	def get_menu_label(self):
	"""Returns the label text to be used for the menu item."""
	return self.menu_label or self.get_app_label_from_subitems()
	def get_menu_name(self):
	"""Returns the name to be used for the menu item."""
	return self.menu_name
	def get_menu_icon(self):
	"""Returns the icon to be used for the menu item."""
	return self.menu_icon or "folder-open-inverse"
	def get_menu_order(self):
	"""Returns the ordering number to be applied to the menu item."""
	return self.menu_order or 8999
	def get_submenu_items(self):
	menu_items = []
	item_order = 1
	for viewset in self.viewsets:
	menu_items.append(viewset.get_menu_item(order=item_order))
	item_order += 1
	return menu_items
	def get_menu_item(self):
	"""Returns a ``MenuItem`` instance to be registered with the Wagtail admin."""
	if not self.viewsets:
	return None
	submenu = Menu(items=self.get_submenu_items())
	return SubmenuMenuItem(
	label=self.get_menu_label(),
	menu=submenu,
	name=self.get_menu_name(),
	icon_name=self.get_menu_icon(),
	order=self.get_menu_order(),
	)
	def register_menu_item(self):
	if self.add_to_settings_menu:
	hooks.register("register_settings_menu_item", self.get_menu_item)
	elif self.add_to_admin_menu:
	hooks.register("register_admin_menu_item", self.get_menu_item)
	def on_register(self):
	self.register_menu_item()

Icons

Relevant snippets PR: #10178.

wagtail/wagtail/snippets/views/snippets.py

Lines 1228 to 1230 in 801eccc

	def get_icon(self):
	"""Returns the icon to be used for the admin views."""
	return self.icon

It might make sense to put icon and get_icon() in the base ViewSet class. However, worth noting that ViewSet has no views configured so it will only be used by subclasses and not ViewSet itself. Still, just like with the menu, this might be useful if people create a custom ViewSet subclass that does not rely on a model.

Currently, the ModelViewSet already supports the icon attribute but not the get_icon() method.

To be in ModelViewSet

Template customisation points

Relevant snippets PR: #10271.

• get_template()
  • The method for resolving template fallbacks to allow using directories with the app_label and model_name as namespaces. See:

    wagtail/wagtail/snippets/views/snippets.py

    Lines 1291 to 1304 in 801eccc

    	def get_templates(self, action="index", fallback=""):
    	"""
    	Utility function that provides a list of templates to try for a given
    	view, when the template isn't overridden by one of the template
    	attributes on the class.
    	"""
    	templates = [
    	f"{self.template_prefix}{self.app_label}/{self.model_name}/{action}.html",
    	f"{self.template_prefix}{self.app_label}/{action}.html",
    	f"{self.template_prefix}{action}.html",
    	]
    	if fallback:
    	templates.append(fallback)
    	return templates

• template_prefix
  • What would be the default prefix for non-snippet models? Internally, we put the templates under the "wagtailadmin/generic/".
• {foo}_template_name
  • Snippets (and ModelAdmin) allow some of the essential views' template names to be overridden on SnippetViewSet, e.g. index_template_name, edit_template_name, etc. We might want to put this on ModelViewSet as well.

Filter definitions

Relevant snippets PR: #10256.

The automatic FilterSet class generation is already in the generic IndexView, so we only need to allow list_filter/filterset_class to be defined on ModelViewSet and pass it down to the IndexView kwargs.

Custom columns

Relevant snippets PR: #9147.

As with filters, this is mostly handled by the generic IndexView so we only need to pass list_display from ModelViewSet.

Search configuration

Relevant snippets PR: #10290.

As with filters and columns, this is mostly handled by the generic IndexView. We need to pass search_fields and search_backend_name from ModelViewSet.

Listing export

Relevant snippets PR: #10626.

This requires SpreadsheetExportMixin and list_export to be defined on the IndexView. The question is, where should SpreadsheetExportMixin be applied? It can be applied dynamically in the ModelViewSet just before the IndexView.as_view() call based on list_export, or we might as well apply it to the generic IndexView.

QuerySet override

Relevant snippets PR: #10275.

This allows the queryset used on the index view to be customised on a per-request basis. To support this, we can move the get_base_queryset() override in snippets' IndexView:

wagtail/wagtail/snippets/views/snippets.py

Lines 170 to 175 in 4d870af

	def get_base_queryset(self):
	# Allow the queryset to be a callable that takes a request
	# so that it can be evaluated in the context of the request
	if callable(self.queryset):
	self.queryset = self.queryset(self.request)
	return super().get_base_queryset()

to the generic IndexView, spefically moving the if check to an elif after the isinstance check here:

wagtail/wagtail/admin/views/generic/models.py

Lines 188 to 191 in 4d870af

	if self.queryset is not None:
	queryset = self.queryset
	if isinstance(queryset, models.QuerySet):
	queryset = queryset.all()

Then, we pass ModelViewSet.get_queryset(request) as the queryset attribute for the index view during as_view().

That said, only using the override on the index view may not be very useful, as outlined in #10746. This likely needs more thought, so we'll probably tackle this customisation separately.

Edit handler

Relevant snippets PR: #10299.

wagtail/wagtail/snippets/views/snippets.py

Lines 1518 to 1541 in 801eccc

	def get_edit_handler(self):
	"""
	Returns the appropriate edit handler for this ``SnippetViewSet`` class.
	It can be defined either on the model itself or on the ``SnippetViewSet``,
	as the ``edit_handler`` or ``panels`` properties. Falls back to
	extracting panel / edit handler definitions from the model class.
	"""
	if hasattr(self, "edit_handler"):
	edit_handler = self.edit_handler
	elif hasattr(self, "panels"):
	panels = self.panels
	edit_handler = ObjectList(panels)
	elif hasattr(self.model, "edit_handler"):
	edit_handler = self.model.edit_handler
	elif hasattr(self.model, "panels"):
	panels = self.model.panels
	edit_handler = ObjectList(panels)
	else:
	exclude = self.get_exclude_form_fields()
	panels = extract_panel_definitions_from_model_class(
	self.model, exclude=exclude
	)
	edit_handler = ObjectList(panels)
	return edit_handler.bind_to_model(self.model)

This allows edit handlers/panels to be defined on the ModelViewSet instead of the model, allowing for better separation between models and view-related code.

Inspect view

Relevant snippets PR: #10621.

When inspect view was added to snippets, we implemented a generic InspectView as well, so this just needs to be added to the ModelViewSet.

The challenge is that we now have to show the "Inspect" button somewhere, and the generic IndexView currently has no mechanism to add arbitrary buttons on the listing. We may have to introduce a way to customise the listing buttons via the ModelViewSet (and consequently, SnippetViewSet) class. Snippets currently rely on hooks to customise the listing buttons, which is against the goal of making the viewset class the "one customisation point". Adding support for customising the listing buttons on the viewset class also brings us somewhat closer to how ModelAdmin did it.

Usage view

Relevant snippets PR: #10007.

When usage view was added to snippets, we implemented a generic InspectView as well, so this just needs to be added to the ModelViewSet.

The challenge is that this is normally accessed via the status side panel. The generic views currently have no support for the status side panel, so we need to add it somehow. Consequently, the status side panel is normally accessed via the header/breadcrumbs, which is also not available in the generic views. As a result, we may also have to add the breadcrumbs.

History view

We've always had a history view for snippets, but we don't yet have a generic HistoryView class. We need to implement a generic HistoryView and include it in ModelViewSet. The history view is also typically accessed via the header/breadcrumbs, so we will also have to add it.

Left in SnippetViewSet

There are additional features supported in SnippetViewSet that requires the model to extend from certain model mixins. Due to the complexities of the possible model mixin combinations, and the fact that this also requires the generic views to be enhanced with additional view mixins, we'll likely leave these features as snippets-only:

• Automatic handling of latest revision's str representation on the IndexView
• Revision, publishing, and workflow handling in the create/edit view
• Preview views
• Revisions compare view
• Unpublish view
• Lock/unlock views
• Workflow-related views

That said, it should technically still be possible to selectively enable these features by extending ModelViewSet and cherry-picking the overrides from SnippetViewSet.

Other points

Viewset registration

Currently, registration of viewsets is handled by the register_admin_viewset hook. For a ModelViewSet, the relationship between the viewset and model is only from ModelViewSet to the model, and not the other way around. This means that you can register as many ModelViewSets as you want for a given model, but as a consequence you cannot get a specific ModelViewSet instance given a particular model.

Certain features for snippets require a 'canonical' viewset, which is attached to the model as model.snippet_viewset, mostly to get the URL configuration:

• Workflow reports/dashboard panel – used for getting URLs for the snippet
• Translations – used for getting URLs (e.g. redirect URL after translating)
• Choosers – for getting the icon and URLs
• Bulk actions – for getting the icon and URLs
• Action menu in create/edit views – for the menu's action URL
  • Generic create/edit views do not use this "footer" action menu, so we can skip this
• Listing button hooks – for getting the URLs
  • We can probably work around this by introducing the customisation point at the viewset-level

As the above features are not relevant or have other workarounds for non-snippet models, having a "canonical" viewset is probably not necessary. If we do need it, a better approach would probably be using a registry instead of patching it on the model.

That said, the way register_admin_viewset hook works is slightly different to how the register_snippet and modeladmin_register function work.

ModelViewSet registration

The following is currently how a ModelViewSet can be registered:

from wagtail.admin.viewsets.model import ModelViewSet
from .models import Person


class PersonViewSet(ModelViewSet):
    model = Person
    form_fields = ["first_name", "last_name"]
    icon = "user"


person_viewset = PersonViewSet("person")


@hooks.register("register_admin_viewset")
def register_viewset():
    return person_viewset

SnippetViewSet registration

Meanwhile, the following is how a SnippetViewSet can be registered:

from wagtail.admin.panels import FieldPanel
from wagtail.snippets.models import register_snippet
from wagtail.snippets.views.snippets import SnippetViewSet

from .models import Person


class PersonViewSet(SnippetViewSet):
    model = Person
    panels = [
        FieldPanel("first_name"),
        FieldPanel("last_name"),
    ]
    icon = "user"
    base_url_path = "person"


register_snippet(AdvertViewSet)

Keep in mind that the SnippetViewSet approach is very similar to the ModelAdmin approach.

Making the ModelViewSet registration similar to SnippetViewSet

If we want to make ModelViewSet registration similar to SnippetViewSet, then we need to:

• Modify ModelViewSet.__init__() (or ModelViewSet.__init__()) to allow the base URL path and the URL namespace to be defined on the ModelViewSet class.
• Introduce a register_viewset function that:
  • Instantiates the ModelViewSet subclass without any argument, e.g. viewset_instance = MyModelViewSet()
  • Call wagtail.admin.viewsets.viewsets.register(viewset_instance)
  • Call ReferenceIndex.register_model(viewset_instance.model)
  • Optionally, register the mapping from MyModel to MyModelViewSet to a registry.

Choosers

Worth noting that a generic ChooserViewSet is also available, and optionally can be used in tandem with ModelViewSet. With SnippetViewSet, the SnippetChooserViewSet is registered alongside with it through composition. I think it makes sense for generic ChooserViewSet to be separate from the ModelViewSet so that it's opt-in rather than opt-out, especially with how ModelAdmin didn't support choosers.

Also worth noting that if desired, allowing to disable the chooser widget in SnippetViewSet is probably as simple as extracting the viewsets.register(self.chooser_viewset) line in the following method into a separate method that can be overridden into a no-op:

wagtail/wagtail/snippets/views/snippets.py

Lines 1558 to 1565 in 801eccc

	def on_register(self):
	super().on_register()
	# For convenience, attach viewset to the model class to allow accessing
	# the configuration of a given model.
	self.model.snippet_viewset = self
	viewsets.register(self.chooser_viewset)
	self.register_model_check()
	self.register_menu_item()

Questions

Summarising open questions from above:

• Should we update ViewSet.__init__()'s signature to make the name and url_prefix optional?
  • Likely yes, but it would be nice if we ensure the attributes must be specified if the init args are not passed.
• Should we support ModelViewSet.get_queryset(request)?
  • If so, how are we going to handle Allow base queryset to be overridden via ModelViewSet to be used in the views #10746?
• Where should we apply SpreadsheetExportMixin?
  • This is probably a bit too into the implementation detail, we can cross the bridge when we get there.
• What would be the default template directory prefix?
  • Also likely an implementation detail, for now we can probably settle on "wagtailadmin/generic/".

Conclusion

Once all of the above is done, we can say that:

• ModelViewSet is the direct replacement to the ModelAdmin class.
• SnippetViewSet is a ModelViewSet subclass that adds support for snippets-only features, e.g. revisions, publishing, previews, choosers, etc.
• For models that do not inherit any of the snippets mixins, using SnippetViewSet instead of ModelViewSet only means:
  • Making the model show up on the "Snippets" model index view.
  • Registering a SnippetChooserViewSet for the model (and the chooser widget that comes with it).

[gasman]

Thanks @laymonage - this is looking good to me! Happy we're going with revisions etc being standard features of snippets specifically rather than models in general - as I recall, those were briefly part of the generic model views during the development of those features for snippets, and ended up swamping the codebase in ways that were counter-productive for simpler models. Also, the models making use of those features are more likely to be ones that fit with the existing perception of snippet as "a chunk of web content", rather than arbitrary business objects where people would be more hesitant about the name Snippet, so that works out nicely 👍

Just a small point on the admin URL configuration part: for viewsets in general, I think specifying the URL namespace during instantiation is most natural, since there could conceivably be situations where there are multiple instances of the same viewset class registered within the urlconf, at different URL paths and namespaces. Of course, that doesn't fit naturally with how snippet viewsets are configured, since the URL registration (and thus instantiating the viewset) is hidden from the developer via register_snippet. So, ideally we want something that works both ways, perhaps having a class-level default that can be overridden during instantiation.

[laymonage]

Thanks @gasman, good to see that we're on the same page!

as I recall, those were briefly part of the generic model views during the development of those features for snippets, and ended up swamping the codebase in ways that were counter-productive for simpler models

Correct, they are then separated into the {Foo}OptionalFeaturesMixin, which lives in wagtail.admin.generic.mixins, so not entirely snippets-specific and can be used in a custom ModelViewSet. That said, I wouldn't mind if they move to wagtail.snippets... Probably unnecessary though.

So, ideally we want something that works both ways, perhaps having a class-level default that can be overridden during instantiation.

Yep, I think that makes sense, and would be nice to add a check to ensure that the class-level default must exist if you instantiate it without an argument. For ModelViewSet specifically, this can also fall back to the {app_label}_{model_name} and app_label/model_name combo like ModelAdmin.

---

By the way, I missed the SnippetViewSet.get_queryset(request) override earlier and have added it to the main discussion post. I've also added a "Questions" section to summarise bits I'm still undecided on (though I think I've answered most of them already). The only thing that's still uncertain is the queryset override as described in #10746, would love to hear your thoughts on that one.

[seb-b]

That said, it should technically still be possible to selectively enable these features by extending ModelViewSet and cherry-picking the overrides from SnippetViewSet.

Without really knowing what's involved it'd be great if this worked like snippets instead of needing custom code, i.e. your model extends RevisionMixin and then the revision comparison views are just enabled automatically. I've used this mixin specifically with generic models but then had to try create a custom view for revision comparison via modeladmin which was an incredible pain. Is there something special about snippets compared to generic models that makes this possible?

[laymonage]

Hey, sorry for the late reply.

I think there are a few reasons for this:

• The code required to support these features (mainly the view logic and templates) is quite complex. Wagtail's generic model views (and by extension, ModelViewSet) are also used for Wagtail's internal models like Redirect, Site, Locale, etc. that don't really need the supporting code for those features. Having the logic for those features in the generic model views makes the code harder to follow and maintain as we'll have to account for all the different combinations.
• Some features require the model to have URLs that can be linked from different places (e.g. workflow actions on the dashboard). Only one SnippetViewSet can be registered with each model, so we can have a "canonical" set of links for that model. Meanwhile, you can register as many ModelViewSets as you want for the same model. (I'm sure we can also add the option to "mark" a ModelViewSet as the canonical one and use it to resolve URLs within the admin, but that's not something we have as of now.)
• I'd also argue that in cases where people would rather use ModelViewSet than SnippetViewSet, it's mostly with models that don't need the extra features. Maybe RevisionMixin is a popular feature that people would want to use with these models, but if we made the exception then it would raise the question of why we don't do this with the other mixins...

[SebCorbin]

We're in the process of migrating from modeladmin to ModelViewset for our non-page models, so far we've been blocked by the fact that edit_handler is not implemented in ModelViewset.
As I could not find this in any issue/PR, I'm wondering if this is in the roadmap?

[gasman]

There's a draft PR covering this - #10830

[SebCorbin]

Thanks! Github search seemed to have failed me

[laymonage]

Copying the following: #8609 (comment) for visibility.

---

@th3hamm0r:

Are there any plans to actually get rid of the "Snippets" term and/or this extra level (e.g. in the URL, breadcrumbs,...)?

We've actually never used snippets before, we've only used the ModelAdmin, since this extra level of "Snippets" (and the term itself) created much confusion in the beginning ("Everything is basically a model, why are pages, images, documents, forms,... in the root or in custom submenus, and some other models below 'Snippets'"?).

Since this has been improved a lot by your amazing work, we are now trying to migrate everything (new) to the ModelViewSets, but mostly to SnippetViewSets, to get all the features (e.g. panels/edit_handlers, bulk actions).

But even with add_to_admin_menu = True it does not feel the same as with the ModelAdmin. On the first view, e.g. if you look at the bakerydemo, the navigation looks good. But if you're at the index view of one of the models, beside the "snippets"-path, you have the "Snippets"-breadcrumb item, and the title bar shows "Snippets [Modelname]", which is all a bit confusing.

Currently, we use the following tweaks for our SnippetViewSets to get this experience without "Snippets" (and a bit more parity with ModelAdmin 😉 ):

• remove the Snippet-breadcrumb-item (by overriding breadcrumbs_items)
• remove "snippets" from the url (by overriding get_admin_base_path())
• override wagtailsnippets/snippets/index.html to get rid of "Snippets" in the titletag-block (by setting a custom index_template_name)
• allow a user only with "view"-permission to open the IndexView
  This is more a ModelAdmin-parity-thing, which I assume just hasn't been tackled yet.
  If a user can only view an object, he should still be able to open the index view.
  • override menu_item_class to also take the "view"-permission into consideration
  • add "view" to the IndexViews any_permission_required
  • We've also adapted the TitleColumn to fallback to the inspect-url or None, if the user cannot edit the object (by overriding IndexView._get_title_column()).
  • add "view" to the InspectViews any_permission_required (optional, if inspect_view_enabled = True)

So I'm thinking of making the snippet-less configuration the default, but still allow to switch to the old setup (for a deprecation period vs. just keep the option).
Another option would be to move most of the snippets-logic into the ModelViewSet, and only keep the Snippets to get this extra level of hierarchy.

[brylie]

I am trying to migrate from ModelAdmin to ModelViewset and encountered a model that uses an Orderable related field. How should I define the form_fields or form_class property of the primary model so that Wagtail will render the Orderable field?

[brylie]

Honestly, while I support making Snippets more powerful and generalized, I am surprised at the choice to deprecate ModelAdmin. The ModelAdmin class is really useful and capable. It is one of the main selling points of WagtailCMS, since it makes Wagtail so developer friendly.

I hope Torchbox can reconsider the decision to deprecate ModelAdmin and reverse course, as we are losing a powerful and well-known tool with the current decision.

[brylie]

Our website also makes use of the ModelAdmin button_helper_class and url_helper_class:

https://github.com/WesternFriend/WF-website/blob/d070c69a0f5e751462163cca9711db9e7885fb1d/magazine/wagtail_hooks.py#L120-L125

So, clear guidance on how to define custom buttons or URLs on ModelViewsets would be really important for our project to transition to Wagtail 6.

[htabar]

Hi there, I've started a related discussion. Didn't post it here, as it is kinda different subject, though I've written about ModelAdmin depreciation.

wagtail.core and wagtail.admin.edit_handlers depreciation