Migrate to wagtail.snippets or wagtail-modeladmin

[UDAR-TomH]

Seeing as how wagtail.contrib.modeladmin is going away in Wagtail 6.0, are there plans to update this package to support either wagtail.snippets or move to wagtail-modeladmin? Would be interested to know the roadmap here.

[MrCordeiro]

We will likely transition to snippets as it's more aligned to the overall Wagtail 6 architecture.

wagtail-modeladmin feels more like a maintenance package and may not be updated in the future.

[frague59]

I'm working on it : https://github.com/frague59/wagtailmenus

[dkirkham]

Is it perhaps worth a quick fix to make use of the decoupled wagtail_modeladmin package, as per the instructions at https://github.com/wagtail-nest/wagtail-modeladmin/blob/main/docs/installation.md?

This will at least remove the annoying deprecation messages while the more substantial changes are made to use snippets.

I'm happy to do this, and to assist (maybe with testing if you are making progress @frague59) with the snippet version.

[JanMalte]

I'm working on it : https://github.com/frague59/wagtailmenus

Hi, are you still on it? Do you need any help?

[frague59]

... I'm on another project right now, I'm missed up in the templates used by the admin - I assume I'm a bit lazy on investigating on it.

And I've used the wagtail-modeladmin external package for my project.

I've not gone so far !

[MrCordeiro]

I feel this migration won't be an easy change for a single person. Wagtailmenus is very coupled with wagtail-modeladmin and its base views. A few wheels will have to be reinvented for snippets.

Maybe we could split the problem into smaller issues and create a milestone for it.

[dkirkham]

Now that I have some other projects out of the way, I’m going to dive into this to remove dependence on wagtail_modeladmin and move to snippets and SnippetViewSet, etc.

My aim is to target Wagtail 5.2 LTS and later, as both 4.1 LTS and 5.1 drop from support in a couple of months.

If it looks like the problem can or should be split up, as commented by @MrCordeiro, I’ll report back with suggestions on how this can be done. I have migrated a couple of other models and the viewsets in other projects, and it wasn’t too painful.

Some thought may be required on how to manage the transition for downstream users, for instance, incorporate these changes into a new v4.0. We may also need to setup some deprecations.

[dkirkham]

I'm making good progress with extracting modeladmin from wagtailmenus. I'm not seeing an obvious way to split up the work at the moment, other than splitting off updates to the documentation.

There are, however, a few design decisions, one of which is whether or not to retain the existing behaviour when viewing and editing the site main menus. The MainMenu model has a OneToOneField relationship with wagtailcore.Site, so there can at most be one MainMenu for each Site. When going to Settings->Main Menu, there is code that will redirect to the editor page for one of the main menus. That editor page then has a "site switcher" at the top right as documented at https://wagtailmenus.readthedocs.io/en/stable/managing_main_menus.html, which redirects to the relevant editor page for the selected main menu:

The question is, do we want to retain this behaviour, or alternatively, expose the site field when editing a main menu? In this latter behaviour, it becomes the admin's responsibility to set that field, and if they duplicate a site, there will be a form error on submission:

My feeling is the latter is more consistent with other ViewSet behaviour, and will therefore be more robust as Wagtail evolves. That said, I think the existing behaviour could be retained, but I haven't yet attempted to fully code it and assess how fragile the solution might be.

End-user views are of course welcome.

[MrCordeiro]

As an end user, I prefer the 2nd option. I feel it's more explicit.

[dkirkham]

Despite my comment above, I am presently pursuing the first option.

Two reasons:

• in a single site deployment, it avoids the distracting intermediate index view which will only ever have one entry
• the PR I create should as much as possible retain existing behaviour, focusing on the ModelAdmin to Snippet change; we can look at UX and editor workflow changes as a separate issue and PR.

I'm just working through the template issues, trying to minimise or eliminate duplication of Wagtail templates that might create an ongoing maintenance burden. I'm also waiting on exactly what happens in wagtail/wagtail#11270 to make sure the FlatMenu copy is consistent - I'll have to backport some code to support Wagtail 5.2 LTS, but hopefully that can be bypassed in Wagtail 6, making for a fairly short deprecation cycle (once 5.2 LTS drops from support).

[vdboor]

Is it perhaps worth a quick fix to make use of the decoupled wagtail_modeladmin package, as per the instructions at https://github.com/wagtail-nest/wagtail-modeladmin/blob/main/docs/installation.md?

This will at least remove the annoying deprecation messages while the more substantial changes are made to use snippets.

I'm happy to do this, and to assist (maybe with testing if you are making progress @frague59) with the snippet version.

This workaround might just do that:

import sys
import wagtail_modeladmin

sys.modules["wagtail.contrib.modeladmin"] = wagtail_modeladmin

Place this in an file that's loaded early (either the settings, or some __init__.py)

[Krxplx]

I installed the third party library wagtail_modeladmin. The main menu is working well, but i cant edit flat menus in cms. Is there anyone with the same problem?

[dkirkham]

@vdboor, release 3.1.9 provides a transition to wagtail_modeladmin which works with Wagtail 5.1.

I have also prepared a PR to completely remove dependence on wagtail_modeladmin in Wagtail 5.2 LTS and 6.0. See #472. It is undergoing final testing and only needs a few documentation updates before it is ready.