v2.0.0
New / updated features
- The
use_specific
menu tag argument can now be one of 4 integer values, allowing for more fine-grained control over the use ofPage.specific
andPageQuerySet.specific()
when rendering menu tags. MainMenu
andFlatMenu
models now have ause_specific
field, to allow the defaultuse_specific
setting when rendering that menu to be changed via the Wagtail admin area. Find the field in the collapsed ADVANCED SETTINGS panel at the bottom of the edit formMainMenu
andFlatMenu
models now have amax_levels
field, to allow the defaultmax_levels
setting when rendering that menu to be changed via the admin area. Find the field in the collapsed ADVANCED SETTINGS panel at the bottom of the edit form- Developers not using the
MenuPage
class or overriding any of wagtailPage
methods involved in URL generation can now enjoy better performance by choosing not to fetch any specific pages at all during rendering. Simply passuse_specific=USE_SPECIFIC_OFF
oruse_specific=0
to the tag, or update theuse_specific
field value on yourMainMenu
orFlatMenu
instances via the Wagtail admin area. - Dropped support for the
WAGTAILMENUS_DEFAULT_MAIN_MENU_MAX_LEVELS
andWAGTAILMENUS_DEFAULT_FLAT_MENU_MAX_LEVELS
settings. Default values are now set using themax_levels
field on the menu objects themselves. - Dropped support for the
WAGTAILMENUS_DEFAULT_MAIN_MENU_USE_SPECIFIC
andWAGTAILMENUS_DEFAULT_FLAT_MENU_USE_SPECFIC
settings. Default values are now set using theuse_specific
field on the menu objects themselves. - The
max_levels
,use_specific
,parent_page
andmenuitem_or_page
arguments passed to all template tags are now checked to ensure their values are valid, and if not, raise aValueError
with a helpful message to aid debugging. - The
has_submenu_items()
method onMenuPage
no longer accepts thecheck_for_children
argument. - The
modify_submenu_items()
andhas_submenu_items()
methods on theMenuPage
model now both accept an optionalmenu_instance
value, so that menu_instance might be called to access pre-fetched page data without hitting the database. - Added the
WAGTAILMENUS_ADD_EDITOR_OVERRIDE_STYLES
setting to allow override styles to be disabled.
Under the hood
- When rendering a multi-level
MainMenu
orFlatMenu
, those models now pre-fetch all of pages needed for menu generation and allow menu tags to request the desired pages from them as they are needed, reducing the need to hit the database multiple times. If you need to use specific pages in main or flat menus, you should see a significant improvement in performance. - Eliminated a lot of code duplication in template tags by adding the
get_sub_menu_items_for_page
method, which is used bysub_menu
,section_menu
andchildren_menu
to do most of their work. - The default
show_multiple_levels
value for theflat_menu
tag is nowTrue
instead ofFalse
. The defaultmax_levels
field value forFlatMenu
instances is1
, which has the same effect. Only, the value can be changed via the admin area, and the changes will reflected immediately without having to explicitly addshow_multiple_levels=True
to the tag in templates. - Other minor performance improvements.
Upgrade considerations
1. Run migrations
New fields have been added to MainMenu
and FlatMenu
models, so you'll need to run the migrations for those. Run the following from your console:
django manage.py migrate wagtailmenus
2. Set max_levels
and use_specific
on your existing menus
Edit your existing MainMenu
and FlatMenu
instances via the Wagtail admin area. There's a new collapsed ADVANCED SETTINGS panel at the bottom of each form, where both of these fields live.
Default values for MainMenu
are max_levels=2
and use_specific=AUTO
.
Default values for FlatMenu
are max_levels=1
and use_specific=AUTO
.
3. Understanding changes to use_specific
template tag options
If you're passing use_specific=True
or use_specific=False
to the any of the menu tags, you'll need to change that to one of the following:
use_specific=USE_SPECIFIC_OFF
(oruse_specific=0
)use_specific=USE_SPECIFIC_AUTO
(oruse_specific=1
)use_specific=USE_SPECIFIC_TOP_LEVEL
(oruse_specific=2
)use_specific=USE_SPECIFIC_ALWAYS
(oruse_specific=3
)
See the following section of the README for further info: https://github.com/rkhleics/wagtailmenus/blob/v2.0.0/README.md#using-menupage
4. Changes to MenuPage.has_submenu_items()
and MenuPage.modify_submenu_items()
If you're extending these methods on your custom page types, you will likely need to make a few changes.
Firstly, the check_for_children
argument is no longer supplied to has_submenu_items
, and is not accepted as a value.
Secondly, both the modify_submenu_items()
and has_submenu_items()
methods both accept an optional menu_instance
argument, which you'll need to factor in.
See the updated section of the README for corrected code examples:
https://github.com/rkhleics/wagtailmenus/blob/v2.0.0/README.md#11-manipulating-sub-menu-items-for-specific-page-types
5. Adding the context_processor
to settings
If you're upgrading from wagtailmenus version 1.5.1
or lower, you'll need to update your settings to include a context_processor from wagtailmenus. Your TEMPLATES
setting should look something like the example below:
TEMPLATES = [
{
'BACKEND': 'django.template.backends.django.DjangoTemplates',
'DIRS': [
os.path.join(PROJECT_ROOT, 'templates'),
],
'APP_DIRS': True,
'OPTIONS': {
'context_processors': [
'django.contrib.auth.context_processors.auth',
'django.template.context_processors.debug',
'django.template.context_processors.i18n',
'django.template.context_processors.media',
'django.template.context_processors.request',
'django.template.context_processors.static',
'django.template.context_processors.tz',
'django.contrib.messages.context_processors.messages',
'wagtail.contrib.settings.context_processors.settings',
'wagtailmenus.context_processors.wagtailmenus',
],
},
},
]