@ababic ababic released this Jun 14, 2018 · 79 commits to master since this release

Assets 2

NOTE:

In order to keep wagtailmenus working with the latest versions of Wagtail and Django, with code that is clean and maintainable, this version will be the last feature release to support Wagtail or Django versions earlier than 2.0.

Minor changes & bug fixes

  • Optimised MenuWithMenuItems.get_top_level_items() and AbstractFlatMenu.get_for_site() to use fewer database queries.
  • Configured sphinxcontrib.spelling and used to correct spelling errors in docs.
  • Updated testing and documentation dependencies.
  • Added Latin American Spanish translations (thanks to José Luis).

Deprecations

The wagtailmenus.app_settings module is deprecated

If you're importing this in your project from it's previous location, you should update the import statements in your code to use the new import path.

So, instead of:

from wagtailmenus import app_settings

Do:

from wagtailmenus.conf import settings

The wagtailmenus.constants module is deprecated

If you're importing this in your project from it's previous location, you should update the import statements in your code to use the new import path.

So, instead of:

from wagtailmenus import constants

Do:

from wagtailmenus.conf import constants

The WAGTAILMENUS_CHILDREN_MENU_CLASS_PATH setting is deprecated

If you're using this in your project's settings to override the menu class used for rendering children menus, you'll want to change this:

# settings/base.py
WAGTAILMENUS_CHILDREN_MENU_CLASS_PATH = 'project.app.module.Class'

To this (without the "_PATH" on the end):

WAGTAILMENUS_CHILDREN_MENU_CLASS = 'project.app.module.Class'

The WAGTAILMENUS_SECTION_MENU_CLASS_PATH setting is deprecated

If you're using this in your project's settings to override the menu class used for rendering section menus, you'll want to change this:

    # settings/base.py
    WAGTAILMENUS_SECTION_MENU_CLASS_PATH = 'project.app.module.Class'

To this (without the "_PATH" on the end):

WAGTAILMENUS_SECTION_MENU_CLASS = 'project.app.module.Class'

Upgrade considerations

FLAT_MENU_MODEL_CLASS has been removed from app settings

If you're referencing FLAT_MENU_MODEL_CLASS directly from wagtailmenus' app settings module, then you may need to make some changes.

If you only need the 'model string' for the model (for example, to use in a
ForeignKey or ManyToManyField field definition), you should use
wagtailmenus.get_flat_menu_model_string() instead.

If you need the Django model class itself, use wagtailmenus.get_flat_menu_model().

MAIN_MENU_MODEL_CLASS has been removed from app settings

If you're referencing MAIN_MENU_MODEL_CLASS directly from wagtailmenus' app settings module, then you may need to make some changes.

If you only need the 'model string' for the model (for example, to use in a ForeignKey or ManyToManyField field definition), you should use wagtailmenus.get_main_menu_model_string() instead.

If you need the Django model class itself, use wagtailmenus.get_main_menu_model().

The CHILDREN_MENU_CLASS app setting no longer returns a class

If you're referencing CHILDREN_MENU_CLASS attribute on wagtailmenus' app settings module, then you may need to make some changes.

The attribute still exists, but now only returns the import path of the class as a string, rather than the class itself.

If you need to access the class itself, you can use the app settings module's new get_object() method, like so:

from wagtailmenus.conf import settings
menu_class = settings.get_object('CHILDREN_MENU_CLASS')

The SECTION_MENU_CLASS app setting no longer returns a class

If you're referencing SECTION_MENU_CLASS attribute on wagtailmenus' app settings module, then you may need to make some changes.

The attribute still exists, but now only returns the import path of the class as a string, rather than the class itself.

If you need to access the class itself, you can use the app settings module's new get_object() method, like so:

from wagtailmenus.conf import settings
menu_class = settings.get_object('SECTION_MENU_CLASS')

@ababic ababic released this May 6, 2018 · 101 commits to master since this release

Assets 2

What's new?

Menu tags will now automatically identify level-specific templates

To make it easier to define templates for menus with three or more levels, each menu class has been updated to look for and use level-specific templates in your template directory. For example, for a main menu with three levels, you could arrange your templates like so:

templates
└── menus
    └── main
        ├── level_1.html
        ├── level_2.html
        └── level_3.html

With this the arrangement, the {% main_menu %} tag would find and use level_1.html to render the first level of menu items, then any calls made to {% sub_menu %} from within that template would use level_2.html, then any further calls to {% sub_menu %} from that template would use level_3.html.

See the updated documentation for more information and examples:
http://wagtailmenus.readthedocs.io/en/v2.9.0/rendering_menus/custom_templates.html#custom-templates-auto

New 'sub_menu_templates' menu tag option allows you to specify templates for multiple levels

To complement the new level-specific template functionality, a new sub_menu_templates option has been added to the main_menu, flat_menu, section_menu and children_menu tags to allow you to specify multiple templates to use at different levels.

For example, if you had a template (e.g abc.html) that you'd like to use for the 2nd level of a section menu, and another (e.g. xyz.html) that you'd like to use for the 3rd, you could specify that by doing the following:

{% section_menu max_levels=3 sub_menu_templates="path/abc.html, path/level_3.html" %}

See the updated doumentation form more information:
http://wagtailmenus.readthedocs.io/en/v2.9.0/rendering_menus/template_tag_reference.html#template-tag-reference

Disable 'Main menu' or 'Flat menu' management options in the Wagtail admin area

Implmented by Michael van de Waeter (mvdwaeter).

Projects come in all shapes and sizes, and not all call for both types of menu. So, to reduce potential confusion for users in the CMS, you can now hide either (or both) the 'Flat menus' and 'Main menu' items from the 'Settings' menu in the admin area (and disables the underlying CMS functionality for each).

See the settings documentation for more information:

@ababic ababic released this Mar 29, 2018 · 112 commits to master since this release

Assets 2

What's new?

Smarter 'active class' attribution for menu items that link to custom URLs

By default, menu items linking to custom URLs are currently only attributed with the 'active' class if their link_url value matches the path of the current request exactly, producing unexpected results when GET parameters or fragments are added to the end of a link_url value.

A new and improved approach to active class attribution for custom URL links has now been implemented (by Joshua C. Jackson and Andy Babic), which you can enable by adding WAGTAILMENUS_CUSTOM_URL_SMART_ACTIVE_CLASSES = True to your project's settings.

With the new approach, only the 'path' part of the link_url value is used for comparision with request.path, which produces far more consistent results. The new approach also allows the 'ancestor' class to be attributed to menu items where the link_url looks like an ancestor of the current request URL. For example, if a menu item's link_url value is '/news/', and the request path is '/news/boring-news-article/', then the menu item will be attributed with the 'ancestor' class.

The previous behaviour is now deprecated in favour of this new approach, and will be removed in version 2.10, with the new approach becoming the default (and only) option.

Minor changes & bug fixes

  • Various documentation spelling/formatting corrections (thanks to Sergey Fedoseev and Pierre Manceaux).

Deprecations

  • The current 'active class' attribution behaviour for menu items linking to custom URLs is deprecated (see above for details). Add WAGTAILMENUS_CUSTOM_URL_SMART_ACTIVE_CLASSES = True to your project's settings to enable the new and improved behaviour and silence the deprecation warning.

Upgrade considerations

Following the standard deprecation period, the following classes, methods and
behaviour has been removed:

@ababic ababic released this Mar 6, 2018 · 142 commits to master since this release

Assets 2

This is a maintenence release to fix a bug that was resulting in content_panels and setting_panels being ignored by Wagtail’s editing UI when editing main or flat menus.

There have also been a few minor tweaks to the documentation, including:

  • Removing the ‘alpha’ notice and title notation from the 2.7.0 release notes.
  • Adding a badge to README.rst to indicate the documentation build status.
  • Adding a missing ‘migrate’ step to the Developing locally instructions in the contribution guidelines.
  • Updating the code block in the .po to .mo conversion step in the packaging guidelines to the find command with execdir.

@ababic ababic released this Mar 1, 2018 · 157 commits to master since this release

Assets 2

What's new?

  • Added support for Wagtail 2.0 and Django 2.0
  • Dropped support for Wagtail versions 1.8 to 1.9
  • Dropped support for Django versions 1.5 to 1.10
  • Dropped support for Python 2 and 3.3

Minor changes & bug fixes

Various 'Python 3 only' code optimisations:

  • Removed future unicode handling imports throughout.
  • Replaced 'old style' class definitions with 'new style' ones.
  • Simplified super() syntax throughout to the cleaner Python 3 implementation.
  • Fixed deprecation warnings pertaining to use of TestCase.assertRaisesRegexp.
  • Fixed an issue that was preventing translated field label text appearing for the handle field when using the FLAT_MENUS_HANDLE_CHOICES setting (Contributed by @jeromelebleu)

Upgrade considerations

  • This version only officially supports Wagtail and Django versions from
    1.10 to 2.0. If you're using anything earlier than that, you should consider
    updating your project. If upgrading Wagtail or Django isn't an option, it might be
    best to stick with wagtailmenus 2.6 for now (which is a LTS release).
  • This version also drops support for anything earlier than Python 3.4.

Following the standard deprecation period, the following classes, methods and
behaviour has been removed:

  • The wagtailmenus.models.menus.MenuFromRootPage class was removed.
  • The __init__() method of wagtailmenus.models.menus.ChildrenMenu no
    longer accepts a root_page keyword argument. The parent page should be
    passed using the parent_page keyword instead.
  • The root_page attribute has been removed from the
    wagtailmenus.models.menus.ChildrenMenu class. Use the parent_page
    attribute instead.
  • The sub_menu template tag no longer accepts a stop_at_this_level
    keyword argument.
  • The get_sub_menu_items_for_page() and prime_menu_items() methods
    have been removed from wagtailmenus.templatetags.menu_tags.
  • The get_attrs_from_context() method has been removed from
    wagtailmenus.utils.misc.
  • The get_template_names() and get_sub_menu_template_names() methods
    have been removed from wagtailmenus.utils.template and the redundant
    wagtailmenus.utils.template module removed.

@ababic ababic released this Dec 22, 2017 · 186 commits to master since this release

Assets 2

Wagtailmenus 2.6 is designated a Long Term Support (LTS) release. Long Term Support releases will continue to receive maintenance updates as necessary to address security and data-loss related issues, up until the next LTS release (for at least 8 months).

Wagtailmenus 2.6 will be the last LTS release to support Python 2 or Python 3.3.

Wagtailmenus 2.6 will be the last LTS release to support Wagtail versions 1.5 to 1.9.

What's new?

Improved compatibility with alternative template backends

Wagtailmenus has been updated to use backend-specific templates for rendering, making it compatible with template backends other than Django's default backend (such as jinja2).

Although the likelihood of this new behavior introducing breaking changes to projects is minute, it is turned OFF by default for now, in order to give developers time to make any necessary changes. However, by version 2.8 the updated behaviour will replace the old behaviour completely, becoming non optional.

To start using wagtailmenus with an alternative backend now (or to test your project's compatibility in advance), you can turn the updated behaviour ON by adding the following to your project's settings:

WAGTAILMENUS_USE_BACKEND_SPECIFIC_TEMPLATES = True

Thank you to Nguyễn Hồng Quân (hongquan) for contributing this!

New tabbed interface for menu editing

In an effort to improve the menu editing UI, Wagtail's TabbedInterface is now used to split a menu's fields into two tabs for editig: Content and Settings; with the latter including panels for the max_levels and use_specific fields (which were previously tucked away at the bottom of the edit page), and the former for everything else.

Two new attributes, content_panels and settings_panels have also been added to AbstractMainMenu and AbstractFlatMenu to allow the panels for each tab to be updated independently.

If for any reason you don't wish to use the tabbed interface for editing custom menu models, the panels attribute is still supported, and will setting that will result in all fields appearing in a single list (as before). However, the panels attribute currently present on the AbstractFlatMenu and AbstractMainMenu models is now deprecated and will be removed in the future releases (see below for more info).

Built-in compatibility with wagtail-condensedinlinepanel

In an effort to improve the menu editing UI, wagtailmenus now has baked-in compatibility with wagtail-condensedinlinepanel. As long as a compatible version (at least 0.3) of the app is installed, wagtailmenus will automatically use CondensedInlinePanel instead of Wagtail's built-in InlinePanel for listing menu items, giving menu editors some excellent additional features, including drag-and-drop reordering and the ability to add a new item into any position.

If you have custom Menu models in your project that use the panels attribute to customise arrangement of fields in the editing UI, you might need to change the your panel list slightly in order to see the improved menu items list after installing. Where you might currently have something like:

class CustomMainMenu(AbstractMainMenu):
    ...

    panels = (
        ...
        InlinePanel('custom_menu_items'),
        ..
    )


class CustomFlatMenu(AbstractFlatMenu):
    ...

    panels = (
        ...
        InlinePanel('custom_menu_items'),
        ..
    )

You should import MainMenuItemsInlinePanel and FlatMenuItemsInlinePanel from wagtailmenus.panels and use them instead like so:

from wagtailmenus.panels import FlatMenuItemsInlinePanel, MainMenuItemsInlinePanel


class CustomMainMenu(AbstractMainMenu):
    ...

    panels = (
        ...
        MainMenuItemsInlinePanel(),  # no need to pass any arguments!
        ..
    )


class CustomFlatMenu(AbstractFlatMenu):
    ...

    panels = (
        ...
        FlatMenuItemsInlinePanel(),  # no need to pass any arguments!
        ..
    )

Minor changes & bug fixes

  • Updated tests to test compatibility with Wagtail 1.13.

Deprecations

Menu.get_template_engine()

This method is deprecated in favour of using Django's generic 'get_template' and 'select_template' methods, which return backend-specific template instances instead of django.template.Template instances.

AbstractMainMenu.panels and AbstractFlatMenu.panels

If you are referencing AbstractMainMenu.panels or AbstractFlatMenu.panels anywhere, you should update your code to reference the content_panels or settings_panels attribute instead, depending on which panels you're trying to make use of.

If you're overriding the panels attribute on a custom menu model in order to make additional fields available in the editing UI (or change the default field display order), you might also want to think about updating your code to override the content_panels and settings_panels attributes instead, which will result in fields being split between two tabs (Content and Settings). However, this is entirely optional.

Upgrade considerations

@ababic ababic released this Dec 18, 2017 · 237 commits to master since this release

Assets 2

There are no changes in this release

@ababic ababic released this Oct 28, 2017 · 237 commits to master since this release

Assets 2

This is a maintenence release to fix a bug that was resulting in Django creating additional migrations for the app when running the makemigrations command after changing the project's default language to something other than "en".

Thanks to @philippbosch from A Color Bright for submitting the fix.