diff --git a/.travis.yml b/.travis.yml index 4063168eb..c7a73cea8 100644 --- a/.travis.yml +++ b/.travis.yml @@ -1,36 +1,34 @@ language: python cache: pip +dist: trusty matrix: - include: + include: - env: TOXENV=py34-dj111-wt2 - sudo: false - dist: trusty python: 3.4 - env: TOXENV=py35-dj111-wt2 - sudo: false - dist: trusty python: 3.5 - env: TOXENV=py36-dj111-wt2 - sudo: false - dist: trusty - python: 3.6 - - env: TOXENV=py36-dj2-wt21 - sudo: false - dist: trusty - python: 3.6 - - env: TOXENV=py36-dj2-wt22 - sudo: false - dist: trusty - python: 3.6 - - env: TOXENV=py36-dj21-wt23 - sudo: false - dist: trusty python: 3.6 + - env: TOXENV=py37-dj111-wt2 + dist: xenial + python: 3.7 + - env: TOXENV=py37-dj2-wt21 + dist: xenial + python: 3.7 + - env: TOXENV=py37-dj2-wt22 + dist: xenial + python: 3.7 - env: TOXENV=py37-dj21-wt23 - sudo: true dist: xenial python: 3.7 + - env: TOXENV=py37-dj21-wt24 + dist: xenial + python: 3.7 + - env: TOXENV=py37-dj22-wt25 + dist: xenial + python: 3.7 + install: - pip install tox codecov @@ -38,7 +36,7 @@ install: script: - tox -after_success: +after_success: - codecov deploy: @@ -50,4 +48,4 @@ deploy: tags: true branch: master repo: rkhleics/wagtailmenus - condition: "$TOXENV = py37-dj21-wt23" + condition: "$TOXENV = py37-dj22-wt25" diff --git a/CHANGELOG.md b/CHANGELOG.md index 0717e8cdb..012e0f581 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,15 +1,45 @@ Changelog ========= -2.13a (XX.XX.XXXX) ------------------- +3.0 (XX.XX.XXXX) +---------------- + + +* Added support for Django 2.2 (no code changes necessary). +* Added support for Wagtail 2.5 (no code changes necessary). +* Removed support for `get_sub_menu_templates()` methods that do not accept a **level** argument. +* Fix: [#329](https://github.com/rkhleics/wagtailmenus/issues/329), which prevented level-specific template naming from working as specified in the docs. +* Fix: [#323](https://github.com/rkhleics/wagtailmenus/issues/323), which prevented `StreamField` from working properly when creating or editing menus with custom item models. + + +2.13.1 (XX.XX.XXXX) +------------------- + +* Fix: [#329](https://github.com/rkhleics/wagtailmenus/issues/329), which prevented level-specific template naming from working as specified in the docs. +* Fix: [#323](https://github.com/rkhleics/wagtailmenus/issues/323), which prevented `StreamField` from working properly when creating or editing menus with custom item models. + -* Dropped support for ``relative_url()`` methods on custom menu item models that do not support a ``request`` keyword argument. +2.13 (16.03.2019) +----------------- + +* Dropped support for `relative_url()` methods on custom menu item models that do not support a `request` keyword argument. +* Added support for Wagtail 2.4. * Added support for Wagtail 2.3. * Added support for Django 2.1. -* Updated ``MenuPage.get_repeated_menu_item()`` to nullify `sub_menu` on the copy to reduce likelihood of infinite recursion errors. -* Updated ``Menu._prime_menu_item()`` to set `sub_menu` to None if no new value is being added, to reduce likelihood of infinite recursion errors. -* Updated ``SectionMenu.prepare_to_render()`` to augment ``root_page`` with 'text', 'href' and 'active_class' attributes, so that it no longer has to be done in ``SectionMenu.get_context_data()``. +* Minor documentation updates (OktayAltay). +* Updated `MenuPage.get_repeated_menu_item()` to nullify `sub_menu` on the copy to reduce likelihood of infinite recursion errors. +* Updated `Menu._prime_menu_item()` to set `sub_menu` to None if no new value is being added, to reduce likelihood of infinite recursion errors. +* Updated `SectionMenu.prepare_to_render()` to augment `root_page` with `text`, `href` and `active_class` attributes, so that it no longer has to be done in `SectionMenu.get_context_data()`. +* Updated `AbstractLinkPage.get_sitemap_urls()` signature to match Wagtail 2.2 (Dan Bentley). +* Documentation typo correction and other improvements (DanAtShenTech). +* Fix an issue where the `WAGTAILMENUS_USE_CONDENSEDINLINEPANEL` setting wasn't being respected. + + +2.12.1 (XX.XX.XXXX) +------------------- + +* Fix: [#329](https://github.com/rkhleics/wagtailmenus/issues/329), which prevented level-specific template naming from working as specified in the docs. +* Fix: [#323](https://github.com/rkhleics/wagtailmenus/issues/323), which prevented `StreamField` from working properly when creating or editing menus with custom item models. 2.12 (17.11.2018) @@ -26,7 +56,7 @@ indication of what the method does. * Added the ``WAGTAILMENUS_DEFAULT_ADD_SUB_MENUS_INLINE`` setting to allow developers to change the default ``add_sub_menu_items_inline`` option value for all template tags. * Fixed a bug in ``Menu.get_common_hook_kwargs()`` where the value of ``self.max_levels`` was being used as the value for ``use_specific`` (instead of ``self.use_specific``). * Changed the "Rendering setings" (typo) heading in ``panels.menu_settings_panels`` to "Render settings". -* Removed support for the deprecated ``WAGTAILMENUS_CHILDREN_MENU_CLASS_PATH`` setting. +* Removed support for the deprecated ``WAGTAILMENUS_CHILDREN_MENU_CLASS_PATH`` setting. * Removed support for the deprecated ``WAGTAILMENUS_SECTION_MENU_CLASS_PATH`` setting. * Removed the deprecated ``wagtailmenus.constants`` module. @@ -48,18 +78,23 @@ indication of what the method does. * Dropped support for Django versions 1.8 to 1.10. * Updated trove classifiers in `setup.py` to reflect Django and Wagtail version support. * Updated `runtests.py` to pass on any unparsed option arguments to Django's test method. -* Updated `runtests.py` to filter out deprecation warnings originating from other apps by default. +* Updated `runtests.py` to filter out deprecation warnings originating from other apps by default. * Updated `MenuItem.relative_url()` to accept a `request` parameter (for parity with `wagtail.core.models.Page.relative_url()`), so that it can pass it on to the page method. * Updated `Menu.prime_menu_items()` to send the current `HttpRequest` to that `MenuItem.relative_url()` and `Page.relative_url()`. * Updated admin views to utilise `wagtail.admin.messages.validation_error()` for reporting field-specific and non-field errors. -* Removed redundant `install_requires` line from `setup.py`. Compatibility is made clear in other places - there's no need to force a minimum installed Wagtail version here. +* Removed redundant `install_requires` line from `setup.py`. Compatibility is made clear in other places - there's no need to force a minimum installed Wagtail version here. * Moved custom `wagtail.contrib.modeladmin` classes out of `wagtailmenus.wagtail_hooks` and into a new `wagtailmenus.modeladmin` module. -* Added the `WAGTAILMENUS_FLAT_MENUS_MODELADMIN_CLASS` setting to allow the default `ModelAdmin` class used to enable flat menu editing in the Wagtail admin area to be swapped out for a custom one. -* Added the `WAGTAILMENUS_MAIN_MENUS_MODELADMIN_CLASS` setting to allow the default `ModelAdmin` class used to enable main menu editing in the Wagtail admin area to be swapped out for a custom one. +* Added the `WAGTAILMENUS_FLAT_MENUS_MODELADMIN_CLASS` setting to allow the default `ModelAdmin` class used to enable flat menu editing in the Wagtail admin area to be swapped out for a custom one. +* Added the `WAGTAILMENUS_MAIN_MENUS_MODELADMIN_CLASS` setting to allow the default `ModelAdmin` class used to enable main menu editing in the Wagtail admin area to be swapped out for a custom one. * Replaced custom app settings module with `django-cogwheels` and removed a lot of the tests that existed to test its workings. * Moved remaining app settings tests to `wagtailmenus.conf.tests`. +2.10.1 (XX.XX.XXXX) +------------------- + +* Fix: [#329](https://github.com/rkhleics/wagtailmenus/issues/329), which prevented level-specific template naming from working as specified in the docs. + 2.10.0 (14.06.2018) ------------------- @@ -119,13 +154,13 @@ indication of what the method does. 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* + `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 +* 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 @@ -136,12 +171,12 @@ indication of what the method does. 2.6.0 (22.12.2017) ------------------- +------------------ * Improve compatibility with alternative template backends such as `jinja2`. Implementation by @hongquan. * Added compatibility with `wagtail-condensedinlinepanel`. -* Updated the menu CMS editing UI to split rendering setting field out into +* Updated the menu CMS editing UI to split rendering setting field out into their own tab. * Updated tests to test compatibility with Wagtail 1.13. @@ -155,7 +190,7 @@ indication of what the method does. 2.5.0 (14.10.2017) ------------------- +------------------ * Added rendering logic to Menu classes and refactored all existing template tags to make use of it (massively reducing code duplication in menu_tags.py). @@ -164,7 +199,7 @@ indication of what the method does. information and examples, see the 'Hooks' section of the documentation: http://wagtailmenus.readthedocs.io/en/latest/advanced_topics/hooks.html * Updated the 'sub_menu' tag to raise an error if used in a way that isn't - supported. + supported. * Deprecated `get_sub_menu_items_for_page` and `prime_menu_items` methods from `wagtailmenus.templatetags.menu_tags` (logic moved to menu classes). * Deprecated `get_template` and `get_sub_menu_template_names` methods from @@ -177,8 +212,8 @@ indication of what the method does. * Minor tidying / renaming of tests. * Added a 'add_menu_items_for_pages()' method to the `MenuWithMenuItems` model, which adds menu item to a menu object, linking to any pages passed in as a `PageQuerySet`. -* Added the 'autopopulate_main_menus' command, that can be run as part of the - installation process to help populate main menus based on the 'home' and +* Added the 'autopopulate_main_menus' command, that can be run as part of the + installation process to help populate main menus based on the 'home' and 'section root' pages for each site. * Fixed an issue with runtests.py that was causing tox builds in Travis CI to report as successful, even when tests were failing. Contributed by @@ -191,43 +226,43 @@ indication of what the method does. original (@cached_property decorated) method calls. * Made the logic in menu classes 'pages_for_display' method easier to override by moving it out into a separate 'get_pages_for_display()' method, which the - original (@cached_property decorated) method calls. + original (@cached_property decorated) method calls. * Made the logic in menu classes 'top_level_items' method easier to override by moving it out into a separate 'get_top_level_items()' method, which the - original (@cached_property decorated) method calls. + original (@cached_property decorated) method calls. 2.4.0 (04.08.2017) ------------------- +------------------ * Adjusted Meta classes on menu item models so that common behaviour is defined once in AbastractMenuItem.Meta. * Refactored the AbstractMenuItem's `menu_text` property method to improve code readability, and better handle instances where neither link_text or link_page are set. -* Replaced overly long README.md with brand new documentation and a new - README.rst which will render better on PyPi. The documentation is kindly - hosted by readthedocs.org and can be found at +* Replaced overly long README.md with brand new documentation and a new + README.rst which will render better on PyPi. The documentation is kindly + hosted by readthedocs.org and can be found at http://wagtailmenus.readthedocs.io/ * Added Chinese translations, kindly submitted by 汇民 王 (levinewong) -* Added the 'use_absolute_page_urls' argument to all template tags. When a - value equating to `True` is provided, the menu will be rendered using the - 'full URL' for each page (including the protocol/domain derived from the +* Added the 'use_absolute_page_urls' argument to all template tags. When a + value equating to `True` is provided, the menu will be rendered using the + 'full URL' for each page (including the protocol/domain derived from the relevant `wagtailcore.models.Site` object), instead the 'relative URL' used by default. Developed by Trent Holliday of Morris Technology and Andy Babic. 2.3.2 (21.07.2017) ------------------- +------------------ * Fixed a bug that would result in {% sub_menu %} being called recursively ( - until raising a "maximum recursion depth exceeded" exception) if a + until raising a "maximum recursion depth exceeded" exception) if a 'repeated menu item' was added at anything past the 2nd level. Thanks to @pyMan for raising/investigating. 2.3.1 (01.07.2017) ------------------- +------------------ * Code example formatting fixes, and better use of headings in README.md. * Added 'on_delete=models.CASCADE' to all relationship fields on models where @@ -244,26 +279,26 @@ indication of what the method does. sub-classed and used in projects to create 'link pages' that act in a similar fashion to menu items when appearing in menus, but can be placed in any part of the page tree. -* Updated 'modify_submenu_items', 'has_submenu_items' and - 'get_repeated_menu_item' methods on MenuPageMixin / MenuPage to accept a - 'request' parameter, which is used to pass in the current `HttpRequest` +* Updated 'modify_submenu_items', 'has_submenu_items' and + 'get_repeated_menu_item' methods on MenuPageMixin / MenuPage to accept a + 'request' parameter, which is used to pass in the current `HttpRequest` object the menu is being rendered for. * Added the `WAGTAILMENUS_SECTION_MENU_CLASS_PATH` setting, which can be used to override the `Menu` class used when using the `{% section_menu %}` tag. * Added the `WAGTAILMENUS_CHILDREN_MENU_CLASS_PATH` setting, which can be used to override the `Menu` class used when using the `{% children_menu %}` tag. * All `Menu` classes are now 'request aware', meaning `self.request` will - return the current `HttpRequest` object within most methods. + return the current `HttpRequest` object within most methods. * Added a `get_base_page_queryset()` method to all `Menu` classes, that can be overridden to change the base page QuerySet used when identifying pages to - be included in a menu when rendering. For example developers could use + be included in a menu when rendering. For example developers could use `self.request.user` to only ever include pages that the current user has some permission for. * Abstracted out most model functionality from `MenuPage` to a `MenuPageMixin` model, that can be used with existing page type models. * Added wagtail 1.10 and django 1.11 test environments to tox. * Renamed `test_frontend.py` to `test_menu_rendering.py` -* In situations where `request.site` hasn't been set by wagtail's +* In situations where `request.site` hasn't been set by wagtail's `SiteMiddleware`, the wagtailmenus context processor use the default site to generate menus with. * Updated AbstractMenuItem.clean() to only ever return field-specific @@ -276,7 +311,7 @@ indication of what the method does. ------------------ * Fixed a bug that would result in {% sub_menu %} being called recursively ( - until raising a "maximum recursion depth exceeded" exception) if a + until raising a "maximum recursion depth exceeded" exception) if a 'repeated menu item' was added at anything past the 2nd level. Thanks to @pyMan for raising/investigating. @@ -298,10 +333,10 @@ indication of what the method does. * Updated travis/tox test settings to test against Wagtail 1.9 & Django 1.10. * Removed a couple of less useful travis/tox environment tests to help with test speed. -* Made use of 'extras_require' in setup.py to replace multiple requirements +* Made use of 'extras_require' in setup.py to replace multiple requirements files. -* Optimised the app_settings module so that we can ditch the questionably stuff - we're doing with global value manipulation on app load (solution inspired by +* Optimised the app_settings module so that we can ditch the questionably stuff + we're doing with global value manipulation on app load (solution inspired by django-allauth). * Added new symantic version handling to the project (solution inspired by wagtail) @@ -312,11 +347,11 @@ indication of what the method does. * Utilise Django's 'django.template.loader.select_template()' method to provide a more intuitive way for developers to override templates for - specific menus without having to explicitly specify alternative templates + specific menus without having to explicitly specify alternative templates via settings or via the `template` and `sub_menu_template` options for each menu tag. See the updated documentation for each tag for information about where wagtailmenus looks for templates. -* Added the `WAGTAILMENUS_SITE_SPECIFIC_TEMPLATE_DIRS` setting to allow +* Added the `WAGTAILMENUS_SITE_SPECIFIC_TEMPLATE_DIRS` setting to allow developers to choose to have wagtailmenus look in additional site-specific locations for templates to render menus. * Moved some methods out of `template_tags/menu_tags.py` into a new `utils.py` @@ -330,7 +365,7 @@ indication of what the method does. ------------------ * Fixed a bug that would result in {% sub_menu %} being called recursively ( - until raising a "maximum recursion depth exceeded" exception) if a + until raising a "maximum recursion depth exceeded" exception) if a 'repeated menu item' was added at anything past the 2nd level. Thanks to @pyMan for raising/investigating. @@ -339,7 +374,7 @@ indication of what the method does. ------------------ * Fixed a bug in the `section_menu` tag when attempting to apply the correct - active class to `section_root` when the `modify_submenu_items()` method has + active class to `section_root` when the `modify_submenu_items()` method has been overridden to return additional items without an `active_class` attribute (like in the example code in README). @@ -347,13 +382,13 @@ indication of what the method does. 2.1.2 (07.01.2017) ------------------ -* Fixed a bug preventing reordered menu items from retaining their new order +* Fixed a bug preventing reordered menu items from retaining their new order after saving. The Meta class on the new abstract models had knocked out the `sort_order` ordering from `wagtail.wagtailcore.models.Orderable`. 2.1.1 (02.01.2017) ------------------- +------------------ * Fixed import error on pip install from version 2.1.0 (Adriaan Tijsseling) @@ -366,10 +401,10 @@ indication of what the method does. * Added `WAGTAILMENUS_MAIN_MENU_MODEL` and `WAGTAILMENUS_FLAT_MENU_MODEL` settings to allow the default main and flat menu models to be swapped out for custom models. -* Added `WAGTAILMENUS_MAIN_MENU_ITEMS_RELATED_NAME` and +* Added `WAGTAILMENUS_MAIN_MENU_ITEMS_RELATED_NAME` and `WAGTAILMENUS_FLAT_MENU_ITEMS_RELATED_NAME` settings to allow the default menu item models to be swapped out for custom models. -* Added the `WAGTAILMENUS_PAGE_FIELD_FOR_MENU_ITEM_TEXT` setting to allow +* Added the `WAGTAILMENUS_PAGE_FIELD_FOR_MENU_ITEM_TEXT` setting to allow developers to specify a page attribute other than `title` to be used to populate the `text` attribute for menu items linking to pages. * Added german translation by Pierre (@bloodywing). @@ -383,7 +418,7 @@ Fixed migration related issue raised by @urlsangel. 2.0.2 (08.12.2016) ------------------- +------------------ This release is broken and shouldn't be used. Skip to v2.0.3 instead. @@ -408,8 +443,8 @@ Bug fix for `main_menu` template tag. default `max_levels` setting when rendering that menu to be changed via the admin area. * When rendering a multi-level `MainMenu` or `FlatMenu, the model instances for - those menus pre-fetch all of pages needed to generate the entire menu. - The menu tags then request lists of child pages from menu instance as they + those menus pre-fetch all of pages needed to generate the entire menu. + The menu tags then request lists of child pages from menu instance as they are needed, reducing the need to hit the database at every single branch. * The `max_levels`, `use_specific`, `parent_page` and `menuitem_or_page` arguments passed to all template tags are now checked to ensure their values @@ -421,10 +456,10 @@ Bug fix for `main_menu` template tag. pass `use_specific=USE_SPECIFIC_OFF` or `use_specific=0` to the tag, or update the `use_specific` field value on your `MainMenu` or `FlatMenu` instances via the Wagtail admin area. -* Dropped support for the `WAGTAILMENUS_DEFAULT_MAIN_MENU_MAX_LEVELS` and +* Dropped support for the `WAGTAILMENUS_DEFAULT_MAIN_MENU_MAX_LEVELS` and `WAGTAILMENUS_DEFAULT_FLAT_MENU_MAX_LEVELS` settings. Default values are now set using the `max_levels` field on the menu objects themselves. -* Dropped support for the `WAGTAILMENUS_DEFAULT_MAIN_MENU_USE_SPECIFIC` and +* Dropped support for the `WAGTAILMENUS_DEFAULT_MAIN_MENU_USE_SPECIFIC` and `WAGTAILMENUS_DEFAULT_FLAT_MENU_USE_SPECFIC` settings. Default values are now set using the `use_specific` field on the menu objects themselves. * Eliminated a lot of code duplication in template tags by adding the @@ -436,7 +471,7 @@ Bug fix for `main_menu` template tag. be changed via the admin area, and the changes will reflected immediately without having to explicitly add `show_multiple_levels=True` to the tag in templates. -* The `has_submenu_items()` method on `MenuPage` no longer accepts a +* The `has_submenu_items()` method on `MenuPage` no longer accepts a `check_for_children` argument. * The `modify_submenu_items()` and `has_submenu_items()` methods on the `MenuPage` model now both accept an optional `menu_instance` value, so that @@ -465,11 +500,11 @@ Bug fix for `main_menu` template tag. used to reduce the overhead as much as possible, only doing the work when the values are accessed by menu tags. * Added the `WAGTAILMENUS_GUESS_TREE_POSITION_FROM_PATH` setting to allow - developers to disable the 'guess tree position from path' functionality + developers to disable the 'guess tree position from path' functionality that comes into play when serving custom views, where the `before_serve_page` hook isn't activated, and `wagtailmenu_params_helper()` in `wagtail_hooks.py` doesn't get to add it's helpful values to the request/context. -* Updated tox environment settings to run tests against wagtail==1.7, and +* Updated tox environment settings to run tests against wagtail==1.7, and updated pinned wagtail version in `setup.py` to reflect compatibility. * Added unicode support for python 2.7 and added missing verbose_names to fields so that they can be translated (Alexey Krasnov & Andy Babic). @@ -478,15 +513,15 @@ Bug fix for `main_menu` template tag. forms into a `ChoiceField`, with that setting as the available choices. -1.5.1 (10.10.2016) +1.5.1 (10.10.2016) ------------------ -* `MenuPage.has_submenu_items()` is now only ever called if +* `MenuPage.has_submenu_items()` is now only ever called if `check_for_children` is True in `menu_tags.prime_menu_items()`. This way, the `max_levels` value supplied to the original menu tag is always - respected, with no additional levels ever being rendered. + respected, with no additional levels ever being rendered. The `check_for_chilren` value passed to `has_submenu_items()` is now always - True. Since removing would add breaking changes, it will be removed in a + True. Since removing would add breaking changes, it will be removed in a later feature release. * Fixed a migration-related issue that was Django to create new migrations for the app. @@ -508,46 +543,46 @@ Bug fix for `main_menu` template tag. * Added the ability to copy/duplicate existing FlatMenu objects between sites (or to the same site with a different handle) via Wagtail's admin area. The 'Copy' button appears in the listing for anyone with 'add' permission, and - the view allows the user to make changes before anything is saved. + the view allows the user to make changes before anything is saved. * Apply `active` classes to menu items that link to custom URLs (if `request.path` and `link_url` are exact matches). -* Added a `handle` to `MenuItem` model to provide a string which can be +* Added a `handle` to `MenuItem` model to provide a string which can be used to do specific matching of menu items in the template. (Tim Leguijt) -1.4.1 (02.10.2016) +1.4.1 (02.10.2016) ------------------ * Updated FlatMenu listing in CMS to include a column for `site`, a filter for `handle`, and a MenuItem count for each object. Also added default ordering, and output the handle value in a tag to make it stand out. * Made it easier to develop and debug wagtailmenus locally, by running it as a - Django project. See CONTRIBUTING.md for instructions. -* Added a `get_for_site` class method to the FlatMenu model, to be consistent + Django project. See CONTRIBUTING.md for instructions. +* Added a `get_for_site` class method to the FlatMenu model, to be consistent with the MainMenu model, and renamed the `for_site` method on MainMenu to `get_for_site` for consistency. `main_menu` and `flat_menu` tags now make use of these. * Fixed an minor bug in the `prime_menu_items` method, where a `depth` - value was hard-coded, instead of utilising the `SECTION_ROOT_LEVEL` setting. + value was hard-coded, instead of utilising the `SECTION_ROOT_LEVEL` setting. 1.4.0 (22.09.2016) ------------------ * Added a `has_submenu_items()` method to `MenuPage` model to compliment - `modify_submenu_items()` in version 1.3. Allows for far better control and + `modify_submenu_items()` in version 1.3. Allows for far better control and consistency when overriding `modify_submenu_items()` to add additional menu items for specific page types. * Added a `sub_menu_template` option to `main_menu`, `section_menu`, `flat_menu` and `children_menu` that will be automatically picked up by the `sub_menu` tag and used as the template (if no `template` value is provided). * Added a `fetch_specific_pages` option to all template tags, that if True, - will used PageQuerySet's `specific()` method to return instances of the + will used PageQuerySet's `specific()` method to return instances of the most specific page-type model as menu items, instead of just vanilla `Page` objects. * Added settings to allow default `fetch_specific_pages` value to be altered for each individual menu tag. -* If `fetch_specific_pages` is True, `prime_menu_items` will call the +* If `fetch_specific_pages` is True, `prime_menu_items` will call the `relative_url` method on the specific page to determine a menu item's `href` value, meaning overrides to that method will be respected. @@ -574,7 +609,7 @@ Bug fix for `main_menu` template tag. responsibility for modifying the initial menu_items list in `section_menu` and `sub_menu` tags. A DRYer approach, that is easier to extend/override to meet custom needs. - + 1.2.3 (25.07.2016) ------------------ @@ -591,5 +626,3 @@ Bug fix for `main_menu` template tag. * Added this changelog :) * Added `WAGTAILMENUS_SECTION_ROOT_DEPTH` setting support, for more consistent identification of 'section root' pages - - diff --git a/CONTRIBUTORS.md b/CONTRIBUTORS.md index f1218f8e0..fa0c55627 100644 --- a/CONTRIBUTORS.md +++ b/CONTRIBUTORS.md @@ -18,6 +18,8 @@ * Pierre Manceaux (pierremanceaux) * Michael van de Waeter (mvdwaeter) * Philipp Bosch (philippbosch) (A Color Bright) +* Oktay Altay (OktayAltay) +* Dan Bentley (danbentley) ## Translators @@ -34,3 +36,4 @@ * Clarice Bianchini (claricebbcosta) * Jérôme Lebleu (jeromelebleu) * José Luis (SalahAdDin) +* Abdulaziz Alfuhigi (3bdul3ziz) diff --git a/README.rst b/README.rst index b67ef0038..dc23c6340 100644 --- a/README.rst +++ b/README.rst @@ -9,11 +9,11 @@ .. image:: https://codecov.io/gh/rkhleics/wagtailmenus/branch/master/graph/badge.svg :alt: Code coverage :target: https://codecov.io/gh/rkhleics/wagtailmenus - + .. image:: https://readthedocs.org/projects/wagtailmenus/badge/?version=stable :alt: Documentation Status :target: http://wagtailmenus.readthedocs.io/en/stable/?badge=stable - + ============ wagtailmenus @@ -21,10 +21,10 @@ wagtailmenus wagtailmenus is an extension for Torchbox's `Wagtail CMS `_ to help you manage and render multi-level navigation and simple flat menus in a consistent, flexible way. -The current version is tested for compatiblily with the following: +The current version is tested for compatiblily with the following: -- Wagtail versions 2.0 to 2.3 -- Django versions 1.11 to 2.1 +- Wagtail versions 2.0 to 2.5 +- Django versions 1.11 to 2.2 - Python versions 3.4 to 3.7 .. image:: https://raw.githubusercontent.com/rkhleics/wagtailmenus/master/docs/source/_static/images/repeating-item.png diff --git a/docs/source/advanced_topics/custom_menu_classes.rst b/docs/source/advanced_topics/custom_menu_classes.rst index b1819dbf9..145f5c7ff 100644 --- a/docs/source/advanced_topics/custom_menu_classes.rst +++ b/docs/source/advanced_topics/custom_menu_classes.rst @@ -12,7 +12,7 @@ Using custom menu classes and models .. _custom_main_menu_models: -Overriding the models used for main menus +Overriding the models used for main menus ========================================= There are a couple of different approaches for overriding the models used for defining / rendering main menus. The best approach for your project depends on which models you need to override. @@ -23,11 +23,11 @@ Replacing the ``MainMenuItem`` model only If you're happy with the default ``MainMenu`` model, but wish customise the menu item model (e.g. to add images, description fields, or extra fields for translated strings), you can use the :ref:`MAIN_MENU_ITEMS_RELATED_NAME` setting to have main menus use a different model, both within Wagtail's CMS, and for generating the list of ``menu_items`` used by menu templates. -1. Within your project, define your custom model by subclassing +1. Within your project, define your custom model by subclassing ``AbstractMainMenuItem``: .. code-block:: python - + # appname/models.py from django.db import models @@ -71,7 +71,7 @@ If you're happy with the default ``MainMenu`` model, but wish customise the menu ) 2. Create migrations for the new model by running: - + .. code-block:: console python manage.py makemigrations appname @@ -90,7 +90,7 @@ If you're happy with the default ``MainMenu`` model, but wish customise the menu # Set this to the 'related_name' attribute used on the ParentalKey field WAGTAILMENUS_MAIN_MENU_ITEMS_RELATED_NAME = "custom_menu_items" -5. *That's it!* The custom models will now be used instead of the default ones. +5. *That's it!* The custom models will now be used instead of the default ones. .. NOTE:: Although you won't be able to see them in the CMS any longer, the default models and any data that was in the original database table will remain intact. @@ -101,11 +101,11 @@ Replacing both the ``MainMenu`` and ``MainMenuItem`` models If you also need to override the ``MainMenu`` model, that's possible too. But, because the ``MainMenuItem`` model is tied to ``MainMenu``, you'll also need to create custom menu item model (whether you wish to add fields / change their behaviour, or not). -1. Within your project, define your custom models by subclassing the +1. Within your project, define your custom models by subclassing the ``AbstractMainMenu`` and ``AbstractMainMenuItem`` model classes: .. code-block:: python - + # appname/models.py from django.db import models @@ -114,7 +114,7 @@ If you also need to override the ``MainMenu`` model, that's possible too. But, b from django.utils import timezone from modelcluster.fields import ParentalKey from wagtail.wagtailadmin.edit_handlers import FieldPanel, MultiFieldPanel, PageChooserPanel - from wagtailmenus import app_settings + from wagtailmenus.conf import settings from wagtailmenus.models import AbstractMainMenu, AbstractMainMenuItem @@ -157,11 +157,11 @@ If you also need to override the ``MainMenu`` model, that's possible too. But, b menu = ParentalKey( LimitedMainMenu, # we can use the model from above on_delete=models.CASCADE, - related_name=app_settings.MAIN_MENU_ITEMS_RELATED_NAME, + related_name=settings.MAIN_MENU_ITEMS_RELATED_NAME, ) 2. Create migrations for the new models by running: - + .. code-block:: console python manage.py makemigrations appname @@ -176,12 +176,12 @@ If you also need to override the ``MainMenu`` model, that's possible too. But, b model instead of the default one. e.g: .. code-block:: python - + # settings.py WAGTAILMENUS_MAIN_MENU_MODEL = "appname.LimitedMainMenu" -5. *That's it!* The custom models will now be used instead of the default ones. +5. *That's it!* The custom models will now be used instead of the default ones. .. NOTE:: Although you won't be able to see them in the CMS any longer, the default models and any data that was in the original database table will remain intact. @@ -200,9 +200,9 @@ Replacing the ``FlatMenuItem`` model only If you're happy with the default ``FlatMenu`` model, but wish customise the menu item models (e.g. to add images, description fields, or extra fields for translated strings), you can use the :ref:`FLAT_MENU_ITEMS_RELATED_NAME` setting to have flat menus use a different model, both within Wagtail's CMS, and for generating the list of ``menu_items`` used by menu templates. 1. Within your project, define your custom model by subclassing ``AbstractFlatMenuItem``: - + .. code-block:: python - + # apname/models.py from django.db import models @@ -246,7 +246,7 @@ If you're happy with the default ``FlatMenu`` model, but wish customise the menu ) 2. Create migrations for the new models by running: - + .. code-block:: console python manage.py makemigrations appname @@ -261,7 +261,7 @@ If you're happy with the default ``FlatMenu`` model, but wish customise the menu instead of the default one. e.g: .. code-block:: python - + # settings.py # Use the 'related_name' attribute you used on your custom model's ParentalKey field @@ -278,11 +278,11 @@ Replacing both the ``FlatMenu`` and ``FlatMenuItem`` models If you also need to override the ``FlatMenu`` model, that's possible too. But, because the ``FlatMenuItem`` model is tied to ``FlatMenu``, you'll also need to create custom menu item model (whether you wish to add fields or their behaviour or not). -1. Within your project, define your custom models by subclassing the +1. Within your project, define your custom models by subclassing the ``AbstractFlatMenu`` and ``AbstractFlatMenuItem`` model classes: - + .. code-block:: python - + # appname/models.py from django.db import models @@ -290,14 +290,14 @@ If you also need to override the ``FlatMenu`` model, that's possible too. But, b from django.utils.translation import ugettext_lazy as _ from modelcluster.fields import ParentalKey from wagtail.wagtailadmin.edit_handlers import FieldPanel, MultiFieldPanel, PageChooserPanel - from wagtailmenus import app_settings + from wagtailmenus.conf import settings from wagtailmenus.panels import FlatMenuItemsInlinePanel from wagtailmenus.models import AbstractFlatMenu, AbstractFlatMenuItem class TranslatedField(object): """ - A class that can be used on models to return a 'field' in the + A class that can be used on models to return a 'field' in the desired language, where there a multiple versions of a field to cater for multiple languages (in this case, English, German & French) """ @@ -358,7 +358,7 @@ If you also need to override the ``FlatMenu`` model, that's possible too. But, b menu = ParentalKey( TranslatedFlatMenu, # we can use the model from above on_delete=models.CASCADE, - related_name=app_settings.FLAT_MENU_ITEMS_RELATED_NAME, + related_name=settings.FLAT_MENU_ITEMS_RELATED_NAME, ) link_text_de = models.CharField( verbose_name=_("link text (german)"), @@ -377,7 +377,7 @@ If you also need to override the ``FlatMenu`` model, that's possible too. But, b """Use `translated_link_text` instead of just `link_text`""" return self.translated_link_text or getattr( self.link_page, - app_settings.PAGE_FIELD_FOR_MENU_ITEM_TEXT, + settings.PAGE_FIELD_FOR_MENU_ITEM_TEXT, self.link_page.title ) @@ -395,7 +395,7 @@ If you also need to override the ``FlatMenu`` model, that's possible too. But, b ) 2. Create migrations for the new models by running: - + .. code-block:: console python manage.py makemigrations appname @@ -410,12 +410,12 @@ If you also need to override the ``FlatMenu`` model, that's possible too. But, b menu model instead of the default one. e.g: .. code-block:: python - + # settings.py WAGTAILMENUS_FLAT_MENU_MODEL = "appname.TranslatedFlatMenu" -5. That's it! The custom models will now be used instead of the default ones. +5. That's it! The custom models will now be used instead of the default ones. .. NOTE:: Although you won't be able to see them in the CMS any longer, the @@ -433,7 +433,7 @@ Like the ``main_menu`` and ``flat_menu`` tags, the ``section_menu`` tag uses a ` The class ``wagtailmenus.models.menus.SectionMenu`` is used by default, but you can use the ``WAGTAILMENUS_SECTION_MENU_CLASS`` setting in your project to make wagtailmenus use an alternative class (for example, if you want to modify the base queryset that determines which pages should be included when rendering). To implement a custom classes, it's recommended that you subclass the ``SectionMenu`` and override any methods as required, like in the following example: .. code-block:: python - + # mysite/appname/models.py from django.utils.translation import ugettext_lazy as _ @@ -442,7 +442,7 @@ The class ``wagtailmenus.models.menus.SectionMenu`` is used by default, but you class CustomSectionMenu(SectionMenu): - + def get_base_page_queryset(self): # Show draft and expired pages in menu for superusers if self.request.user.is_superuser: @@ -450,9 +450,9 @@ The class ``wagtailmenus.models.menus.SectionMenu`` is used by default, but you # Resort to default behaviour for everybody else return super(CustomSectionMenu, self).get_base_page_queryset() - + .. code-block:: python - + # settings.py WAGTAILMENUS_SECTION_MENU_CLASS = "mysite.appname.models.CustomSectionMenu" @@ -468,7 +468,7 @@ Like all of the other tags, the ``children_menu`` tag uses a ``Menu`` class to f The class ``wagtailmenus.models.menus.ChildrenMenu`` is used by default, but you can use the ``WAGTAILMENUS_CHILDREN_MENU_CLASS`` setting in your project to make wagtailmenus use an alternative class (for example, if you want to modify which pages are included). For custom classes, it's recommended that you subclass ``ChildrenMenu`` and override any methods as required e.g: .. code-block:: python - + # appname/menus.py from django.utils.translation import ugettext_lazy as _ @@ -486,7 +486,7 @@ The class ``wagtailmenus.models.menus.ChildrenMenu`` is used by default, but you .. code-block:: python - + # settings.py WAGTAILMENUS_CHILDREN_MENU_CLASS = "mysite.appname.models.CustomChildrenMenu" diff --git a/docs/source/advanced_topics/specific_pages.rst b/docs/source/advanced_topics/specific_pages.rst index d4959c77b..dd3de2c44 100644 --- a/docs/source/advanced_topics/specific_pages.rst +++ b/docs/source/advanced_topics/specific_pages.rst @@ -7,14 +7,14 @@ For pages, Wagtail makes use of a technique in Django called 'multi-table inheritance'. In simple terms, this means that when you create an instance of a custom page type model, the data is saved in two different database tables: -* All of the standard fields from Wagtail's ``Page`` model are stored in one table -* Any data for additional fields specific to your custom model are saved in another one +* All of the standard fields from Wagtail's ``Page`` model are stored in one table. +* Any data for additional fields specific to your custom model are saved in another table. -Because of this, in order for Django to return 'specific' page type instance (e.g. an `EventPage`), it needs to fetch and join data from both tables; which has a negative effect on performance. +Because of this, in order for Django to return a 'specific' page type instance (e.g. an `EventPage`), it needs to fetch and join data from both tables, which has a negative effect on performance. -Menu generation is particularly resource intensive, because a menu needs to know a lot of data about a lot of pages. Add a need for 'specific' page instances to that mix (perhaps you need to access multilingual field values that only exist in the specific database table, or you want to use other custom field values in your menu templates), and that intensity is understandably greater, as the data will likely be spread over many tables (depending on how many custom page types you are using), needing lots of database joins to put everything together. +Menu generation is particularly resource intensive because a menu needs to know a lot of data about a lot of pages. Add into that mix a need to retrieve 'specific' page instances (perhaps you need to access multilingual field values that only exist in a specific database table, or maybe you want to use other custom field values in your menu templates), and that intensity is understandably greater, as the data will likely be spread over many tables (depending on how many custom page types you are using), requiring lots of database joins to put everything together. -Because every project has different needs, wagtailmenus gives you some fine grained control over how 'specific' pages should be used in your menus. When defining a ``MainMenu`` or ``FlatMenu`` in the CMS, the **Specific page use** field allows you to choose one of the following options, which can also be passed to any of the included template tags using the ``use_specific`` parameter. +Because every project has different needs, wagtailmenus gives you some fine-grained control over how 'specific' pages should be used in your menus. When defining a ``MainMenu`` or ``FlatMenu`` in the CMS, the **Specific page usage** field allows you to choose one of the following options, which can also be passed to any of the included template tags using the ``use_specific`` parameter. .. _specific_pages_values: @@ -22,7 +22,7 @@ Because every project has different needs, wagtailmenus gives you some fine grai Supported values for fetching specific pages -------------------------------------------- -* **Off** (value: ``0``): Use only standard ``Page`` model data and methods, and make the minimum number of database methods when rendering. If you aren't using wagtailmenus' ``MenuPage`` model in your project, and don't need to access any custom page model fields or methods in you menu templates, and aren't overriding ``get_url_parts()`` or other ``Page`` methods concerned with URL generation, you should use this option for optimal performance. +* **Off** (value: ``0``): Use only standard ``Page`` model data and methods, and make the minimum number of database calls when rendering. If you aren't using wagtailmenus' ``MenuPage`` model in your project, and you don't need to access any custom page model fields or methods in your menu templates, and if you aren't overriding ``get_url_parts()`` or other ``Page`` methods concerned with URL generation, you should use this option for optimal performance. * **Auto** (value: ``1``): Only fetch and use specific pages when needed for ``MenuPage`` operations (e.g. for 'repeating menu item' behaviour, and manipulation of sub-menu items via ``has_submenu_items()`` and ``modify_submenu_items()`` methods). @@ -40,7 +40,7 @@ Supported values for fetching specific pages Using the ``use_specific`` template tag argument ------------------------------------------------ -All of the template tags included in wagtailmenus accept a ``use_specific`` argument, allowing you to override any default settings, or the settings applied via the CMS to individual ``MainMenu`` and ``FlatMenu`` objects. As a value, you can pass in the integer value of any of the above options, for example: +All of the template tags included in wagtailmenus accept a ``use_specific`` argument, allowing you to override any default settings or the settings applied via the CMS to individual ``MainMenu`` and ``FlatMenu`` objects. As a value, you can pass in the integer value of any of the above options, for example: .. code-block:: html diff --git a/docs/source/contributing/index.rst b/docs/source/contributing/index.rst index 4658649ca..4c9bbef15 100644 --- a/docs/source/contributing/index.rst +++ b/docs/source/contributing/index.rst @@ -37,10 +37,10 @@ following criteria: 1. Documentation updates to cover any new features or changes. -2. If you're not in the list already, add a new line to ``CONTRIBUTORS.md`` +2. If you're not in the list already, add a new line to ``CONTRIBUTORS.md`` (under the 'Contributors' heading) with your name, company name, and an optional twitter handle / email address. -3. For all new features, please add additional unit tests to +3. For all new features, please add additional unit tests to ``wagtailmenus.tests``, to test what you've written. Although the quality of unit tests is the most important thing (they should be readable, and test the correct thing / combination of things), code coverage is important @@ -57,16 +57,17 @@ If you'd like a runnable Django project to help with development of wagtailmenus .. code-block:: console - pip install -e '.[testing,docs]' -U - pip install -r requirements/development.txt + mkvirtualenv wagtailmenus + pip install -e '.[development]' -U + setvirtualenvproject -2. Create a copy of the development settings: +2. Create a copy of the development settings: .. code-block:: console cp wagtailmenus/settings/development.py.example wagtailmenus/settings/development.py -3. Create a copy of the development urls: +3. Create a copy of the development urls: .. code-block:: console @@ -77,27 +78,27 @@ If you'd like a runnable Django project to help with development of wagtailmenus .. code-block:: console cp manage.py.example manage.py - + 5. Run the migrate command to set up the database tables: .. code-block:: console python manage.py migrate -6. To load some test data into the database, run: +6. To load some test data into the database, run: .. code-block:: console python manage.py loaddata wagtailmenus/tests/fixtures/test.json -7. Create a new superuser that you can use to access the CMS: +7. Create a new superuser that you can use to access the CMS: .. code-block:: console python manage.py createsuperuser -8. Run the project using the standard Django command: - +8. Run the project using the standard Django command: + .. code-block:: console python manage.py runserver @@ -105,14 +106,15 @@ If you'd like a runnable Django project to help with development of wagtailmenus Your local copies of ``settings/development.py`` and ``manage.py`` will be ignored by git when you push any changes, as will anything you add to the ``wagtailmenus/development/`` directory. -Testing locally -=============== +Running the test suite +====================== It's important that any new code is tested before submitting. To quickly test code in your active development environment, you should first install all of the requirements by running: .. code-block:: console - pip install -e '.[testing,docs]' -U + workon wagtailmenus + pip install -e '.[testing]' -U Then, run the following command to execute tests: @@ -136,6 +138,35 @@ Testing in a single environment is a quick and easy way to identify obvious issu You might find it easier to set up a Travis CI service integration for your fork in GitHub (look under **Settings > Apps and integrations** in GitHub's web interface for your fork), and have Travis CI run tests whenever you commit changes. The test configuration files already present in the project should work for your fork too, making it a cinch to set up. +Building the documentation +========================== + +1. First install the necessary requirements by running: + + .. code-block:: console + + workon wagtailmenus + pip install -e '.[docs]' -U + +2. ``cd`` into the ``docs`` directory to do documentation-related stuff: + + .. code-block:: console + + cd docs + +3. Check for and correct any spelling errors raised by sphinx: + + .. code-block:: console + + make spelling + +4. Check that the docs build okay, and look out for errors or warnings: + + .. code-block:: console + + make html + + Other topics ============ diff --git a/docs/source/index.rst b/docs/source/index.rst index 7ded0fd24..ad987207b 100644 --- a/docs/source/index.rst +++ b/docs/source/index.rst @@ -5,15 +5,15 @@ Welcome to the wagtailmenus documentation! wagtailmenus is an open-source extension for `Wagtail CMS `_ to help you define, manage and render menus in a consistent, yet flexible way. -The current version is tested for compatibility with the following: +The current version is tested for compatibility with the following: -- Wagtail versions 2.0 to 2.3 -- Django versions 1.11 to 2.1 +- Wagtail versions 2.0 to 2.5 +- Django versions 1.11 to 2.2 - Python versions 3.4 to 3.7 To find out more about what wagtailmenus does and why, see :doc:`overview` -To view the code, open an issue, or submit a pull request, view the `wagtailmenus project on github `_. +To view the code, open an issue, or submit a pull request, view the `wagtailmenus project on github `_. Below are some useful links to help you get you started: @@ -50,5 +50,3 @@ Full index settings_reference contributing/index releases/index - - diff --git a/docs/source/installation.rst b/docs/source/installation.rst index 3fb46e224..520360de4 100644 --- a/docs/source/installation.rst +++ b/docs/source/installation.rst @@ -4,11 +4,11 @@ Installing wagtailmenus ========================= -1. Install the package using pip: +1. Install the package using pip: .. code-block:: console - pip install wagtailmenus + pip install wagtailmenus 2. Add ``wagtailmenus`` and ``wagtail.contrib.modeladmin`` to the ``INSTALLED_APPS`` setting in your project settings: @@ -21,10 +21,10 @@ Installing wagtailmenus 'wagtailmenus', ] -3. Add ``wagtailmenus.context_processors.wagtailmenus`` to the - ``context_processors`` list in your ``TEMPLATES`` setting. The setting +3. Add ``wagtailmenus.context_processors.wagtailmenus`` to the + ``context_processors`` list in your ``TEMPLATES`` setting. The setting should look something like this: - + .. code-block:: python TEMPLATES = [ @@ -52,16 +52,16 @@ Installing wagtailmenus ] 4. Run migrations to create database tables for wagtailmenus: - + .. code-block:: console python manage.py migrate wagtailmenus 5. **This step is optional**. If you're adding wagtailmenus to an existing project, and the tree for each site follows a structure similar to the - example below, you may find it useful to run the 'autopopulate_main_menus' + example below, you may find it useful to run the 'autopopulate_main_menus' command to populate main menus for your site(s). - + However, this will only yield useful results if the 'root page' you've set for your site(s) is what you consider to be the 'Home' page, and the pages directly below that are the pages you'd like to link to in your main @@ -70,8 +70,8 @@ Installing wagtailmenus For example, if your page structure looked like the following: .. code-block:: none - - Home (Set as 'root page' for the site) + + Home (Set as 'root page' for the site) ├── About us ├── What we do ├── Careers @@ -125,18 +125,18 @@ Installing ``wagtail-condensedinlinepanel`` Although doing so is entirely optional, for an all-round better menu editing experience, we recommend using wagtailmenus together with `wagtail-condensedinlinepanel `_. -``wagtail-condensedinlinepanel`` offers a React-powered alternative to Wagtail's built-in ``InlinePanel`` with some great extra features that make it perfect for managing menu items; including drag-and-drop reordering and the ability to add new items at any position. +``wagtail-condensedinlinepanel`` offers a React-powered alternative to Wagtail's built-in ``InlinePanel`` with some great extra features that make it perfect for managing menu items; including drag-and-drop reordering and the ability to add new items at any position. If you'd like to give it a try, follow the installation instructions below, and wagtailmenus will automatically use the app's ``CollapsedInlinePanel`` class. 1. Install the package using pip. - If your project uses Wagtail ``2.0`` or later, run: + If your project uses Wagtail ``2.0`` or later, run: .. code-block:: console - pip install wagtail-condensedinlinepanel==0.5.0 + pip install wagtail-condensedinlinepanel==0.5.2 Otherwise, run: diff --git a/docs/source/managing_main_menus.rst b/docs/source/managing_main_menus.rst index de5d64429..e02e4130d 100644 --- a/docs/source/managing_main_menus.rst +++ b/docs/source/managing_main_menus.rst @@ -10,7 +10,7 @@ Managing main menus via the CMS 2. Click on **Settings** in the side menu, then select **Main menu** from the options that appear. -3. You'll be automatically redirected to the an edit page for the current site +3. You'll be automatically redirected to an edit page for the current site (or the 'default' site, if the current site cannot be identified). For multi-site projects, a 'site switcher' will appear in the top right, allowing you to edit main menus for each site. @@ -29,9 +29,7 @@ Managing main menus via the CMS showing up, edit the page and check whether the "Show in menus" checkbox is checked (found under the "Promote" tab by default). -5. At the very bottom of the form, you'll find the **ADVANCED SETTINGS** - panel, which is collapsed by default. Click on the arrow icon next to the - heading to reveal the **Maximum levels** and **Specific usage** fields, +5. Use the **SETTINGS** inline panel to define the **Maximum levels** and **Specific usage** fields, which you can alter to fit the needs of your project. For more information about specific usage see :ref:`specific_pages`. diff --git a/docs/source/menupage.rst b/docs/source/menupage.rst index e548d7c08..b3e5f7e70 100644 --- a/docs/source/menupage.rst +++ b/docs/source/menupage.rst @@ -40,7 +40,7 @@ If the **About Us** page uses a model that subclasses ``MenuPage`` or ``MenuPage .. image:: _static/images/wagtailmenus-menupage-settings-visible.png :alt: Screenshot show the expanded 'advanced menu behaviour' panel -Now, wherever the children of the **About Us** page are output (using one of the above menu tags), an additional link will appear alongside them, allowing the that page to be accessed more easily. In the example above, you'll see **"Section overview"** has been added to the a **Repeated item link text** field. With this set, the link text for the repeated item should read **"Section overview"**, instead of just repeating the page's title, like so: +Now, wherever the children of the **About Us** page are output (using one of the above menu tags), an additional link will appear alongside them, allowing that page to be accessed more easily. In the example above, you'll see **"Section overview"** has been added to the **Repeated item link text** field. With this set, the link text for the repeated item should read **"Section overview"**, instead of just repeating the page's title, like so: .. image:: _static/images/repeating-item.png :alt: Screenshot showing the repeated nav item appearing in a rendered menu @@ -97,7 +97,7 @@ Implementing ``MenuPage`` into your project models involved, you can skip this step. But, if you are overriding the ``settings_panels`` attribute on a custom model to surface other custom fields in that tab, you'll need to include additional panels to surface the - new ``MenuPage`` fields in the page edit interface. Wagtailmenus includes a pre-defined ``menupage_panel`` to make this easier, which you can use like + new ``MenuPage`` fields in the page editor interface. Wagtailmenus includes a pre-defined ``menupage_panel`` to make this easier, which you can use like this: .. code-block:: python @@ -149,7 +149,7 @@ Implementing ``MenuPageMixin`` into your project Wagtail has a restriction that forbids models from subclassing more than one other class derived from ``Page``, and that single page-derived class must be the left-most item when subclassing more than one model class. Most of the time, that doesn't cause any noticeable issues. But, in some cases, it can make it difficult to swap out base model classes used for page models. In these cases, you can use ``wagtailmenus.models.MenuPageMixin`` instead of ``MenuPage``. .. NOTE:: - ``MenuPageMixin`` doesn't change make any changes to the panel configuration on your model in order to surface it's new fields in the page editing interface. If you want those fields to appear, you'll have to override ``settings_panels`` on your model to include ``menupage_panel`` + ``MenuPageMixin`` doesn't change make any changes to the panel configuration on your model that would cause it's new fields to be surfaced in the page editing interface. If you want those fields to appear, you'll have to override ``settings_panels`` on your model to include ``menupage_panel`` 1. Subclass ``wagtailmenus.models.MenuPageMixin`` to create your model, including it to the right of any other class that subclasses ``Page``: @@ -171,7 +171,7 @@ Wagtail has a restriction that forbids models from subclassing more than one oth # It's not possible for MenuPageMixin to set `settings_panel`, so you must # override `settings_panels` yourself, and include `menupage_panel` in - # order to surface additional field in the 'Settings' tab of the editor + # order to surface additional fields in the 'Settings' tab of the editor # interface settings_panels = [ FieldPanel('custom_settings_field_one'), @@ -195,8 +195,8 @@ Wagtail has a restriction that forbids models from subclassing more than one oth .. _manipulating_submenu_items: -Using ``MenuPage`` to manipulating sub-menu items -================================================= +Using ``MenuPage`` to manipulate sub-menu items +=============================================== When a page model subclasses ``MenuPage`` or ``MenuPageMixin``, pages of that type are given special treatment by the menu generation template tags included in wagtailmenus, allowing them to make changes to the sub-menu items that get rendered below them. diff --git a/docs/source/overview.rst b/docs/source/overview.rst index 1ec57cd50..300573bb0 100644 --- a/docs/source/overview.rst +++ b/docs/source/overview.rst @@ -13,7 +13,7 @@ Overview and key concepts Better control over top-level menu items ======================================== -When you have a 'main navigation' menu powered purely by the page tree, things can get a little tricky, as they are often designed in a way that is very sensitive to change. Some moderators might not understand that publishing a new page at the top level (or reordering those pages) will dramatically affect the main navigation (and possibly even break the design). And really, *why should they?* +When you have a 'main navigation' menu powered purely by the page tree, things can get a little tricky, as the main menu is often designed in a way that is very sensitive to change. Some moderators might not understand that publishing a new page at the top level (or reordering those pages) will dramatically affect the main navigation (and possibly even break the design). And really, *why should they?* Wagtailmenus solves this problem by allowing you to choose exactly which pages should appear as top-level items. It adds new functionality to Wagtail's CMS, allowing you to simply and effectively create and manage menus, using a familiar interface. @@ -33,9 +33,9 @@ Multi-level menus generated from your existing page tree We firmly believe that your page tree is the best place to define the structure, and the 'natural order' of pages within your site. Wagtailmenus only allows you to define the top-level items for each menu, because offering anything more would inevitably lead to site managers redefining parts of the page tree in multiple places, doomed to become outdated as the original tree changes over time. -To generate multi-level menus, wagtailmenus takes the top-level items you define for each menu and automatically combines it with your page tree, efficiently identifying ancestors for each selected pages and outputting them as sub-menus following the same structure and order. +To generate multi-level menus, wagtailmenus takes the top-level items you define for each menu and automatically combines it with your page tree, efficiently identifying descendants for each selected page and outputting them as sub-menus following the page tree's structure and order. -You can prevent any page from appearing menus simply by setting ``show_in_menus`` to ``False``. Pages will also no longer be included in menus if they are unpublished. +You can prevent any page from appearing in menus by simply setting ``show_in_menus`` to ``False``. Pages will also no longer be included in menus if they are unpublished. Define menus for all your project needs @@ -62,7 +62,7 @@ While main menus always have to be defined for each site, for flat menus, you ca You can even use different approaches for different flat menus in the same project. If you'd like to learn more, take a look at the ``fall_back_to_default_site_menus`` option in :ref:`flat_menu_args` -A **copy** feature in also available from the flat menu management interface, allowing you to quickly and easily copy existing menus from one site to another. +A **copy** feature is also available from the flat menu management interface, allowing you to quickly and easily copy existing menus from one site to another. In a multi-site project, you can also configure wagtailmenus to use separate sets of templates for each site for rendering (See :ref:`custom_templates_auto`) diff --git a/docs/source/releases/2.10.1.rst b/docs/source/releases/2.10.1.rst new file mode 100644 index 000000000..0eab6893e --- /dev/null +++ b/docs/source/releases/2.10.1.rst @@ -0,0 +1,7 @@ +================================= +Wagtailmenus 2.10.1 release notes +================================= + +This release includes fixes for the following bugs: + +- `#329 `_, which was preventing level-specific template names working as specified in the docs. diff --git a/docs/source/releases/2.12.1.rst b/docs/source/releases/2.12.1.rst new file mode 100644 index 000000000..504a68924 --- /dev/null +++ b/docs/source/releases/2.12.1.rst @@ -0,0 +1,8 @@ +================================= +Wagtailmenus 2.12.1 release notes +================================= + +This release includes fixes for the following bugs: + +- `#329 `_, which prevented level-specific template names working as specified in the docs. +- `#323 `_, which prevented ``StreamField`` from working properly when creating or editing menus with custom item models. diff --git a/docs/source/releases/2.13.1.rst b/docs/source/releases/2.13.1.rst new file mode 100644 index 000000000..1fbb5a1f2 --- /dev/null +++ b/docs/source/releases/2.13.1.rst @@ -0,0 +1,8 @@ +================================= +Wagtailmenus 2.13.1 release notes +================================= + +This release includes fixes for the following bugs: + +- `#329 `_, which prevented level-specific template names working as specified in the docs. +- `#323 `_, which prevented ``StreamField`` from working properly when creating or editing menus with custom item models. diff --git a/docs/source/releases/2.13.rst b/docs/source/releases/2.13.rst index 81ea9267a..025e940c9 100644 --- a/docs/source/releases/2.13.rst +++ b/docs/source/releases/2.13.rst @@ -1,12 +1,6 @@ -======================================= -Wagtailmenus 2.13 (alpha) release notes -======================================= - -.. NOTE :: - - Wagtailmenus 2.13 is in the alpha stage of development. Any changes - detailed below are subject to change before the final 2.13 release. - +=============================== +Wagtailmenus 2.13 release notes +=============================== .. contents:: :local: @@ -16,23 +10,28 @@ Wagtailmenus 2.13 (alpha) release notes What's new? =========== -TBA +There are no new major features in this release. -Minor changes & bug fixes +Minor changes & bug fixes ========================= - Added support for Wagtail 2.3. +- Added support for Wagtail 2.4. - Added support for Django 2.1. +- Minor documentation updates (OktayAltay). - Updated ``MenuPage.get_repeated_menu_item()`` to nullify ``sub_menu`` on the copy to reduce likelihood of infinite recursion errors. - Updated ``Menu._prime_menu_item()`` to set ``sub_menu`` to None if no new value is being added, to reduce likelihood of infinite recursion errors. -- Updated ``SectionMenu.prepare_to_render()`` to augment ``root_page`` with 'text', 'href' and 'active_class' attributes, so that it no longer has to be done in ``SectionMenu.get_context_data()``. +- Updated ``SectionMenu.prepare_to_render()`` to augment ``root_page`` with ``text``, ``href`` and ``active_class`` attributes, so that it no longer has to be done in ``SectionMenu.get_context_data()``. +- Updated ``AbstractLinkPage.get_sitemap_urls()`` signature to match Wagtail 2.2 (Dan Bentley). +- Documentation typo correction and other improvements (DanAtShenTech). +- Fix an issue where the ``WAGTAILMENUS_USE_CONDENSEDINLINEPANEL`` setting wasn't being respected. Deprecations ============ -TBA +None Upgrade considerations @@ -45,4 +44,3 @@ Following a standard deprecation period a two minor releases, the following func --------------------------------------------------------------------- If you're using custom ``MenuItem`` models in your project, and are overriding ``relative_url()``, you should update the signature on your custom model method to accept a ``request`` keyword argument, and pass it on to ``link_page.relative_url()`` and ``super().relative_url()`` (in addition to ``site``) if calling either of those from. - diff --git a/docs/source/releases/3.0.rst b/docs/source/releases/3.0.rst new file mode 100644 index 000000000..012b2c12f --- /dev/null +++ b/docs/source/releases/3.0.rst @@ -0,0 +1,82 @@ +====================================== +Wagtailmenus 3.0 (alpha) release notes +====================================== + +.. NOTE :: + + Wagtailmenus 3.0 is in the alpha stage of development. Any changes + detailed below are subject to change before the final 3.0 release. + + +.. contents:: + :local: + :depth: 1 + + +What's new? +=========== + +TBA + + +Minor changes & bug fixes +========================= + +* Added support for Django 2.2 (no code changes necessary). +* Added support for Wagtail 2.5 (no code changes necessary). +* Fixed bug `#329 `_, which prevented level-specific template naming from working as specified in the docs. +* Fixed bug `#323 `_, which prevented ``StreamField`` from working properly when creating or editing menus with custom item models. + + +Deprecations +============ + +TBA + + +Upgrade considerations +====================== + +Changes to ``Menu.get_sub_menu_templates()`` +-------------------------------------------- + +If you are overriding this method on a custom menu class you will need to update the method's signature to accept a ``level`` argument with a default value of ``2``. If you are calling ``super().get_sub_menu_templates()`` from within the override method, you should also pass the ``level`` value through to that, like so: + +.. code-block:: python + + MyCustomMenu(OriginalMenuClass): + + def get_sub_menu_templates(self, level=2): + # your custom here + ... + # passing level on to super() version + return super().get_sub_menu_templates(level) + + +Planned removals +---------------- + +Following a standard deprecation period a two minor releases, the following functionality has now been removed. + + +``Menu.get_instance_for_rendering()`` +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In an effort to make method names more reflective of their functionality, this method has been replaced by two methods: +``create_from_collected_values()`` and ``get_from_collected_values()``. The former is implemented on menu classes that are not model based (where instances must be created from scratch each time, for example: ``ChildrenMenu``, ``SectionMenu``, ``SubMenu``), and the latter is implemented on model-based menu classes, where a corresponding object must be retrieved from the database (so, ``AbstractMainMenu``, ``MainMenu``, ``AbstractFlatMenu`` and ``FlatMenu``). + +``render_from_tag()`` automatically calls one or the other, depending on whether the class inherits from ``django.db.models.Model``. + +If you're using custom menu classes in your project, and are overriding ``get_instance_for_rendering()`` for any of those classes, you should update your code to override one of the new methods instead. Both of these new methods accept the same arguments, and return the same values, so the transition should be very easy. + + +``Menu.get_contextual_vals_from_context()`` +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In an effort to make method names more reflective of their functionality, and to help dissuade users from overriding functionality that could be subject to change in future, this method has been renamed to ``_create_contextualvals_obj_from_context()`` (becoming a private method in the process). + + +``Menu.get_option_vals_from_options()`` +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In an effort to make method names more reflective of their functionality, and to help dissuade users from overriding functionality that could be subject to change in future, this method has been renamed to ``_create_optionvals_obj_from_values()`` (becoming a private method in the process). diff --git a/docs/source/releases/index.rst b/docs/source/releases/index.rst index b9fb6fe28..776c79402 100644 --- a/docs/source/releases/index.rst +++ b/docs/source/releases/index.rst @@ -5,10 +5,14 @@ Release notes .. toctree:: :maxdepth: 1 + 3.0 + 2.13.1 2.13 + 2.12.1 2.12 2.11.1 2.11 + 2.10.1 2.10.0 2.9.0 2.8.0 diff --git a/docs/source/rendering_menus/custom_templates.rst b/docs/source/rendering_menus/custom_templates.rst index 80e338c00..553bed0e0 100644 --- a/docs/source/rendering_menus/custom_templates.rst +++ b/docs/source/rendering_menus/custom_templates.rst @@ -18,7 +18,7 @@ Writing custom menu templates What context variables are available to use? -------------------------------------------- -The following variables are added to the context by all included template tags, which you can make use of in your templates: +The following variables are added to the context for each menu template or sub-menu template that you create: :``menu_items``: If the template is for rendering the first level of a main or flat menu, @@ -51,7 +51,7 @@ The following variables are added to the context by all included template tags, levels (should be picked up automatically by the ``sub_menu`` tag). :``original_menu_tag``: - A string value indicating the name of tag was originally called in order to + A string value indicating the name of the tag that was originally called in order to render the branch currently being rendered. The value will be one of ``"main_menu"``, ``"flat_menu"``, ``"section_menu"``, ``"children_menu"`` or ``"sub_menu"``. @@ -113,7 +113,7 @@ Using preferred paths and names for your templates This is the easiest (and recommended) approach for getting wagtailmenus to use your custom menu templates for rendering. -When you do not specify templates to use using the ``template``, ``sub_menu_template``, or ``sub_menu_templates`` arguments template tag arguments, wagtailmenus looks in a list of gradually less specific paths until it finds an appropriate template to use. If you're familiar with Django, you'll probably already be familiar with this concept. Essentially, you can easily override the default menu templates by putting your custom templates in a preferred location within your project. +When you do not specify templates names using the ``template``, ``sub_menu_template``, or ``sub_menu_templates`` template tag arguments, wagtailmenus looks in a list of gradually less specific paths until it finds an appropriate template to use. If you're familiar with Django, you'll probably already be familiar with this concept. Essentially, you can easily override the default menu templates by putting your custom templates in a preferred location within your project. The following sections outline the preferred template paths for each tag, in the order that they are searched for (most specific first). @@ -219,7 +219,7 @@ For flat menus, the tag also uses the `handle` field of the specific menu being **Examples** -For a flat menu with the handle ``info``, that is required to show two levels of menu items, your templates directory might look like this: +For a flat menu with the handle ``info`` that is required to show two levels of menu items, your templates directory might look like this: :: templates diff --git a/docs/source/rendering_menus/template_tag_reference.rst b/docs/source/rendering_menus/template_tag_reference.rst index 7b1954252..da592feb0 100644 --- a/docs/source/rendering_menus/template_tag_reference.rst +++ b/docs/source/rendering_menus/template_tag_reference.rst @@ -45,7 +45,7 @@ Required? Expected value type Default value No ``bool`` ``True`` ========= =================== ============= -Adding ``show_multiple_levels=False`` to the tag in your template is essentially a more descriptive way of adding ``max_levels`` to ``1``. +Adding ``show_multiple_levels=False`` to the tag in your template is essentially a more descriptive way of setting ``max_levels`` to ``1``. ----- @@ -84,7 +84,7 @@ Required? Expected value type Default value No ``bool`` ``True`` ========= =================== ============= -Item repetition settings set on each page are respected by default, but you can add ``allow_repeating_parents=False`` to ignore them, and not repeat any pages in sub-menus when rendering multiple levels. +Item repetition settings that are set on each page are respected by default, but you can add ``allow_repeating_parents=False`` to ignore them and not repeat any pages in sub-menus when rendering multiple levels. ----- @@ -178,7 +178,7 @@ Lets you render the menu to a template of your choosing. If not provided, wagtai For more information about overriding templates, see: :ref:`custom_templates`. -For a list of preferred template paths this tag, see: :ref:`custom_templates_main_menu`. +For a list of preferred template paths for this tag, see: :ref:`custom_templates_main_menu`. ----- @@ -195,7 +195,7 @@ Lets you specify a template to be used for rendering sub menus. All subsequent c For more information about overriding templates, see: :ref:`custom_templates`. -For a list of preferred template paths this tag, see: :ref:`custom_templates_main_menu`. +For a list of preferred template paths for this tag, see: :ref:`custom_templates_main_menu`. ----- @@ -340,7 +340,7 @@ Required? Expected value type Default value No ``bool`` ``True`` ========= =================== ============= -Repetition-related settings on your pages are respected by default, but you can add ``allow_repeating_parents=False`` to ignore them, and not repeat any pages in sub-menus when rendering. Please note that using this option will only have an effect if ``use_specific`` has a value of ``1`` or higher. +Repetition-related settings on your pages are respected by default, but you can add ``allow_repeating_parents=False`` to ignore them and not repeat any pages in sub-menus when rendering. Please note that using this option will only have an effect if ``use_specific`` has a value of ``1`` or higher. ----- @@ -353,7 +353,7 @@ Required? Expected value type Default value No ``bool`` ``False`` ========= =================== ============= -When using the ``flat_menu`` tag, wagtailmenus identifies the 'current site', and attempts to find a menu for that site, matching the ``handle`` provided. By default, if no menu is found for the current site, nothing is rendered. However, if ``fall_back_to_default_site_menus=True`` is provided, wagtailmenus will search search the 'default' site (In the CMS, this will be the site with the '**Is default site**' checkbox ticked) for a menu with the same handle, and use that instead before giving up. +When using the ``flat_menu`` tag, wagtailmenus identifies the 'current site', and attempts to find a menu for that site, matching the ``handle`` provided. By default, if no menu is found for the current site, nothing is rendered. However, if ``fall_back_to_default_site_menus=True`` is provided, wagtailmenus will search the 'default' site (in the CMS, this will be the site with the '**Is default site**' checkbox ticked) for a menu with the same handle and, if found, use that instead before giving up. The default value can be changed to ``True`` by utilising the :ref:`FLAT_MENUS_FALL_BACK_TO_DEFAULT_SITE_MENUS` setting. @@ -417,7 +417,7 @@ Lets you render the menu to a template of your choosing. If not provided, wagtai For more information about overriding templates, see: :ref:`custom_templates`. -For a list of preferred template paths this tag, see: :ref:`custom_templates_flat_menu`. +For a list of preferred template paths for this tag, see: :ref:`custom_templates_flat_menu`. ----- @@ -450,7 +450,7 @@ Lets you specify a template to be used for rendering sub menus (if enabled using For more information about overriding templates, see: :ref:`custom_templates`. -For a list of preferred template paths this tag, see: :ref:`custom_templates_flat_menu`. +For a list of preferred template paths for this tag, see: :ref:`custom_templates_flat_menu`. ----- @@ -664,7 +664,7 @@ Lets you render the menu to a template of your choosing. If not provided, wagtai For more information about overriding templates, see: :ref:`custom_templates`. -For a list of preferred template paths this tag, see: :ref:`custom_templates_section_menu`. +For a list of preferred template paths for this tag, see: :ref:`custom_templates_section_menu`. ----- @@ -681,7 +681,7 @@ Lets you specify a template to be used for rendering sub menus. All subsequent c For more information about overriding templates, see: :ref:`custom_templates`. -For a list of preferred template paths this tag, see: :ref:`custom_templates_section_menu`. +For a list of preferred template paths for this tag, see: :ref:`custom_templates_section_menu`. ----- @@ -881,7 +881,7 @@ Lets you render the menu to a template of your choosing. If not provided, wagtai For more information about overriding templates, see: :ref:`custom_templates` -For a list of preferred template paths this tag, see: :ref:`custom_templates_children_menu` +For a list of preferred template paths for this tag, see: :ref:`custom_templates_children_menu` ----- @@ -898,7 +898,7 @@ Lets you specify a template to be used for rendering sub menus. All subsequent c For more information about overriding templates, see: :ref:`custom_templates` -For a list of preferred template paths this tag, see: :ref:`custom_templates_children_menu` +For a list of preferred template paths for this tag, see: :ref:`custom_templates_children_menu` ----- diff --git a/requirements/development.txt b/requirements/development.txt deleted file mode 100644 index c6173054b..000000000 --- a/requirements/development.txt +++ /dev/null @@ -1,9 +0,0 @@ -wagtail>=1.13,<2.0 -html5lib>=1.0,<1.1 -beautifulsoup4>=4.6,<4.7 -django-cogwheels -django-debug-toolbar -django-extensions -ipdb -werkzeug -mock diff --git a/setup.py b/setup.py index 0421bf044..3041a9a53 100644 --- a/setup.py +++ b/setup.py @@ -19,13 +19,21 @@ ] testing_extras = [ - 'beautifulsoup4>=4.5', + 'beautifulsoup4<4.6.1,>=4.5.1', 'coverage>=4.5', 'django-webtest>=1.9,<1.10', 'wagtail-condensedinlinepanel>=0.5,<0.6', 'django-crispy-forms>=1.7,<1.8' ] +development_extras = [ + 'wagtail>=2.4,<2.5', + 'django-debug-toolbar', + 'django-extensions', + 'ipdb', + 'werkzeug', +] + documentation_extras = [ 'pyenchant>=2.0', 'Sphinx>=1.7.4', @@ -75,6 +83,7 @@ extras_require={ 'testing': testing_extras, 'docs': documentation_extras, + 'development': development_extras + testing_extras, 'deployment': deployment_extras, }, ) diff --git a/tox.ini b/tox.ini index df73f67e6..446821de7 100644 --- a/tox.ini +++ b/tox.ini @@ -3,7 +3,7 @@ skipsdist = True usedevelop = True envlist = - py{34,35,36,37}-dj{111,2,21}-wt{2,21,22,23} + py{34,35,36,37}-dj{111,2,21}-wt{2,21,22,23,24,25} [testenv] install_command = pip install -e ".[testing]" -U {opts} {packages} @@ -19,7 +19,10 @@ deps = dj111: Django>=1.11,<2.0 dj2: Django>=2.0,<2.1 dj21: Django>=2.1,<2.2 + dj22: Django>=2.2,<3.0 wt2: wagtail>=2.0,<2.1 wt21: wagtail>=2.1,<2.2 wt22: wagtail>=2.2,<2.3 wt23: wagtail>=2.3,<2.4 + wt24: wagtail>=2.4,<2.5 + wt25: wagtail>=2.5,<2.6 diff --git a/wagtailmenus/__init__.py b/wagtailmenus/__init__.py index 0030441d5..8fa566ca1 100644 --- a/wagtailmenus/__init__.py +++ b/wagtailmenus/__init__.py @@ -2,7 +2,7 @@ # major.minor.patch.release.number # release must be one of alpha, beta, rc, or final -VERSION = (2, 13, 0, 'alpha', 0) +VERSION = (3, 0, 0, 'alpha', 0) __version__ = get_version(VERSION) stable_branch_name = get_stable_branch_name(VERSION) diff --git a/wagtailmenus/models/menus.py b/wagtailmenus/models/menus.py index 0a61c2084..decd3e8d1 100644 --- a/wagtailmenus/models/menus.py +++ b/wagtailmenus/models/menus.py @@ -16,7 +16,6 @@ from wagtailmenus import forms, panels from wagtailmenus.conf import constants, settings -from wagtailmenus.utils.deprecation import RemovedInWagtailMenus3Warning from wagtailmenus.utils.misc import get_site_from_request from .menuitems import MenuItem from .mixins import DefinesSubMenuTemplatesMixin @@ -112,48 +111,10 @@ def _get_render_prepared_object(cls, context, **option_values): for rendering. ``context`` could be a ``django.template.Context`` object passed to ``render_from_tag()`` by a menu tag. """ - class_method = cls.get_contextual_vals_from_context.__func__ - original_method = Menu.get_contextual_vals_from_context.__func__ - if class_method is not original_method: - warnings.warn( - "From v2.12, the get_contextual_vals_from_context() class " - "method is deprecated, and will be removed in v3. Use " - "get_contextual_vals_from_context() instead.", - category=RemovedInWagtailMenus3Warning - ) - ctx_vals = cls.get_contextual_vals_from_context(context) - else: - ctx_vals = cls._create_contextualvals_obj_from_context(context) - - class_method = cls.get_option_vals_from_options.__func__ - original_method = Menu.get_option_vals_from_options.__func__ - if class_method is not original_method: - warnings.warn( - "From v2.12, the get_option_vals_from_options() class " - "method is deprecated, and will be removed in v3. Use " - "_create_optionvals_obj_from_values() instead.", - category=RemovedInWagtailMenus3Warning - ) - opt_vals = cls.get_option_vals_from_options(**option_values) - else: - opt_vals = cls._create_optionvals_obj_from_values(**option_values) - - class_method = cls.get_instance_for_rendering.__func__ - original_method = Menu.get_instance_for_rendering.__func__ - is_model_class = issubclass(cls, models.Model) - if class_method is not original_method: - warnings.warn( - "From v2.12, the get_instance_for_rendering() class " - "method is deprecated, and will be removed in v3. For " - "'{}', you should override the {}() method instead.".format( - cls.__name__, - 'get_from_collected_values' if is_model_class - else 'create_from_collected_values' - ), - category=RemovedInWagtailMenus3Warning - ) - instance = cls.get_instance_for_rendering(ctx_vals, opt_vals) - elif is_model_class: + ctx_vals = cls._create_contextualvals_obj_from_context(context) + opt_vals = cls._create_optionvals_obj_from_values(**option_values) + + if issubclass(cls, models.Model): instance = cls.get_from_collected_values(ctx_vals, opt_vals) else: instance = cls.create_from_collected_values(ctx_vals, opt_vals) @@ -184,16 +145,6 @@ def _create_contextualvals_obj_from_context(cls, context): context_processor_vals.get('current_page_ancestor_ids', ()), ) - @classmethod - def get_contextual_vals_from_context(cls, context): - warnings.warn( - "From v2.12, the get_contextual_vals_from_context() class method " - "is deprecated, and will be removed in v3. Use " - "_create_contextualvals_obj_from_context() instead.", - category=RemovedInWagtailMenus3Warning - ) - return cls._create_contextualvals_obj_from_context(context) - @classmethod def _create_optionvals_obj_from_values(cls, **kwargs): """ @@ -225,16 +176,6 @@ def _create_optionvals_obj_from_values(cls, **kwargs): kwargs # anything left over will be stored as 'extra' ) - @classmethod - def get_option_vals_from_options(cls, **kwargs): - warnings.warn( - 'From v2.12, the get_option_vals_from_options() class method is ' - 'deprecated, and will be removed in v3. Use ' - '_create_optionvals_obj_from_values() instead.', - category=RemovedInWagtailMenus3Warning - ) - return cls._create_optionvals_obj_from_values(**kwargs) - @classmethod def create_from_collected_values(cls, contextual_vals, option_vals): """ @@ -259,20 +200,6 @@ def get_from_collected_values(cls, contextual_vals, option_vals): "their own 'get_from_collected_values' method." ) - @classmethod - def get_instance_for_rendering(cls, contextual_vals, option_vals): - warnings.warn( - 'The get_instance_for_rendering() class method is deprecated in ' - 'v2.12 and will be removed in v3. For model-based menu classes, ' - 'use get_from_collected_values() instead, and for non model-based ' - 'menu classes, use create_from_collected_values().', - category=RemovedInWagtailMenus3Warning - ) - if issubclass(cls, models.Model): - return cls.get_from_collected_values(contextual_vals, option_vals) - - return cls.create_from_collected_values(contextual_vals, option_vals) - def prepare_to_render(self, request, contextual_vals, option_vals): """ Before calling ``render_to_template()``, this method is called to give @@ -1536,12 +1463,11 @@ def get_template_names(self): template_names.append(lstn) return template_names - def get_sub_menu_template_names(self): + def get_sub_menu_template_names(self, level=2): """Returns a list of template names to search for when rendering a a sub menu for a specific flat menu object (making use of self.handle) """ site = self._contextual_vals.current_site - level = self._contextual_vals.current_level handle = self.handle template_names = [] if settings.SITE_SPECIFIC_TEMPLATE_DIRS and site: diff --git a/wagtailmenus/models/mixins.py b/wagtailmenus/models/mixins.py index cf2b77632..b309d5644 100644 --- a/wagtailmenus/models/mixins.py +++ b/wagtailmenus/models/mixins.py @@ -1,6 +1,7 @@ from django.template.loader import get_template, select_template from wagtailmenus.conf import settings +from wagtailmenus.utils.inspection import accepts_kwarg def get_item_by_index_or_last_item(items, index): @@ -69,7 +70,9 @@ def get_sub_menu_template(self, level=2): template = get_template(template_name) else: # A template wasn't specified, so search the filesystem - template = select_template(self.get_sub_menu_template_names()) + template = select_template( + self.get_sub_menu_template_names(level) + ) # Cache the template instance before returning self._sub_menu_template_cache[level] = template @@ -77,15 +80,15 @@ def get_sub_menu_template(self, level=2): sub_menu_template = property(get_sub_menu_template) - def get_sub_menu_template_names(self): - """Return a list of template paths/names to search when rendering a - sub menu for this menu instance. The list should beordered with most - specific names first, since the first template found to exist will be - used for rendering""" + def get_sub_menu_template_names(self, level=2): + """Return a list of template paths/names to search for when rendering + a sub menu for this menu instance at the supplied `level`. The list + should be ordered with most specific names first, since the first + template found to exist will be used for rendering.""" template_names = [] menu_name = self.menu_short_name site = self._contextual_vals.current_site - level = self._contextual_vals.current_level + if settings.SITE_SPECIFIC_TEMPLATE_DIRS and site: hostname = site.hostname template_names.extend([ diff --git a/wagtailmenus/models/pages.py b/wagtailmenus/models/pages.py index e08634c7e..2411669fd 100644 --- a/wagtailmenus/models/pages.py +++ b/wagtailmenus/models/pages.py @@ -244,7 +244,7 @@ def show_in_menus_custom(self, request=None, current_site=None, return self.link_page_is_suitable_for_display() return True - def get_sitemap_urls(self): + def get_sitemap_urls(self, request=None): return [] # don't include pages of this type in sitemaps def _url_base(self, request=None, current_site=None, full_url=False): diff --git a/wagtailmenus/panels.py b/wagtailmenus/panels.py index e4a24a37b..f8f937ad7 100644 --- a/wagtailmenus/panels.py +++ b/wagtailmenus/panels.py @@ -17,7 +17,10 @@ def _define_inlinepanel(relation_name, **kwargs): klass = InlinePanel defaults = {'label': _('menu items')} - if 'condensedinlinepanel' in django_settings.INSTALLED_APPS: + if( + settings.USE_CONDENSEDINLINEPANEL and + 'condensedinlinepanel' in django_settings.INSTALLED_APPS + ): import condensedinlinepanel from condensedinlinepanel.edit_handlers import CondensedInlinePanel if LooseVersion(condensedinlinepanel.__version__) >= LooseVersion('0.3'): diff --git a/wagtailmenus/settings/development.py.example b/wagtailmenus/settings/development.py.example index a7a25cfe3..c1028c447 100644 --- a/wagtailmenus/settings/development.py.example +++ b/wagtailmenus/settings/development.py.example @@ -13,7 +13,6 @@ INSTALLED_APPS += ( 'debug_toolbar', 'wagtailmenus.tests', 'wagtailmenus.development', - 'wagtail.contrib.wagtailstyleguide', ) DATABASES = { @@ -23,9 +22,9 @@ DATABASES = { } } -MIDDLEWARE_CLASSES = ( +MIDDLEWARE = ( 'debug_toolbar.middleware.DebugToolbarMiddleware', -) + MIDDLEWARE_CLASSES +) + MIDDLEWARE ROOT_URLCONF = 'wagtailmenus.development.urls' WAGTAIL_SITE_NAME = 'Wagtailmenus development' diff --git a/wagtailmenus/templates/wagtailmenus/flatmenu_copy.html b/wagtailmenus/templates/wagtailmenus/flatmenu_copy.html index b085a31e7..4f49b34e0 100644 --- a/wagtailmenus/templates/wagtailmenus/flatmenu_copy.html +++ b/wagtailmenus/templates/wagtailmenus/flatmenu_copy.html @@ -1,4 +1,3 @@ {% extends "modeladmin/create.html" %} -{% load i18n %} {% block form_action %}{{ view.copy_url }}{% endblock %} diff --git a/wagtailmenus/templates/wagtailmenus/mainmenu_edit.html b/wagtailmenus/templates/wagtailmenus/mainmenu_edit.html index efec0c3b7..ba9004db8 100644 --- a/wagtailmenus/templates/wagtailmenus/mainmenu_edit.html +++ b/wagtailmenus/templates/wagtailmenus/mainmenu_edit.html @@ -1,11 +1,4 @@ {% extends "modeladmin/create.html" %} -{% load i18n %} - -{% block header %} - {% include "wagtailmenus/includes/header_with_site_switcher.html" with title=view.page_title subtitle=view.get_page_subtitle icon=view.header_icon %} -{% endblock %} - -{% block form_action %}?{% endblock %} {% block extra_css %} {% include "wagtailadmin/pages/_editor_css.html" %} @@ -16,5 +9,12 @@ {% block extra_js %} {% include "wagtailadmin/pages/_editor_js.html" %} {{ edit_handler.form.media.js }} + {{ edit_handler.html_declarations }} {{ view.media.js }} {% endblock %} + +{% block header %} + {% include "wagtailmenus/includes/header_with_site_switcher.html" with title=view.page_title subtitle=view.get_page_subtitle icon=view.header_icon %} +{% endblock %} + +{% block form_action %}?{% endblock %} diff --git a/wagtailmenus/tests/models/menus.py b/wagtailmenus/tests/models/menus.py index a282570e3..0fb7a3972 100644 --- a/wagtailmenus/tests/models/menus.py +++ b/wagtailmenus/tests/models/menus.py @@ -17,11 +17,6 @@ class CustomChildrenMenu(ChildrenMenu): class CustomSectionMenu(SectionMenu): sub_menu_template_name = "menus/custom-overrides/section-sub.html" - @classmethod - def get_instance_for_rendering(cls, contextual_vals, option_vals): - # To be removed in v3 - return super().get_instance_for_rendering(contextual_vals, option_vals) - class MultilingualMenuItem(models.Model): link_text_de = models.CharField( @@ -90,21 +85,6 @@ class FlatMenuCustomMenuItem(MultilingualMenuItem, AbstractFlatMenuItem): class CustomMainMenu(AbstractMainMenu): panels = AbstractMainMenu.content_panels + AbstractMainMenu.settings_panels - @classmethod - def get_contextual_vals_from_context(cls, context): - # To be removed in v3 - return super().get_contextual_vals_from_context(context) - - @classmethod - def get_option_vals_from_options(cls, **kwargs): - # To be removed in v3 - return super().get_option_vals_from_options(**kwargs) - - @classmethod - def get_instance_for_rendering(cls, contextual_vals, option_vals): - # To be removed in v3 - return super().get_instance_for_rendering(contextual_vals, option_vals) - class CustomFlatMenu(AbstractFlatMenu): heading_de = models.CharField( diff --git a/wagtailmenus/utils/deprecation.py b/wagtailmenus/utils/deprecation.py index 1bba82ee8..059517ae1 100644 --- a/wagtailmenus/utils/deprecation.py +++ b/wagtailmenus/utils/deprecation.py @@ -1,13 +1,13 @@ -class RemovedInWagtailMenus3Warning(DeprecationWarning): +class RemovedInWagtailMenus31Warning(DeprecationWarning): pass -removed_in_next_version_warning = RemovedInWagtailMenus3Warning +removed_in_next_version_warning = RemovedInWagtailMenus31Warning -class RemovedInWagtailMenus31Warning(PendingDeprecationWarning): +class RemovedInWagtailMenus32Warning(PendingDeprecationWarning): pass -class RemovedInWagtailMenus32Warning(PendingDeprecationWarning): +class RemovedInWagtailMenus33Warning(PendingDeprecationWarning): pass