jazzband / wagtailmenus Goto Github PK

I recently extended wagtail-modeltranslation to cover MainMenuItem and FlatMenuItem so as to allow for multilingual menu items.

This presented a couple of challenges, first the Wagtail admin interface to menu items needs to be extended manually to allow for the additional fields with translations.

However, the bigger problem seems to be that the wagtailmenus code doesn't seem to recognize the additional language(s) for items linking to pages. For example, menu items that don't have a manual title set only show the page title in the default language (even if the page has multiple languages set). As well, the relative_url method in wagtailmenus/models.py doesn't recognize the non-default language routes. Specifically the url variable is never filled in those cases. I've manually set url to self.link_page.get_url_parts()[2] when in the non-default language which is what the existing code does when in the default language:

        try:
            url = self.link_page.relative_url(current_site)
        except AttributeError:
            url = self.link_url

This is a bit of a hack around the actual problem, although I'm not quite sure why relative_url doesn't return the proper value, or why menu_text ignores the alternative languages available. Oddly enough, it seemed to actually work better when the MenuItems weren't registered with modeltranslation.

In the meantime, I'm working around this by manually setting page_titles for each of the menu items that link to Wagtail pages.

Hi,
Thanks a lot for your great plugin it really helps a lot

I want to have a siblings only menu (Menu which has only pages at the same level, So no children and no parents)

I tried to change the section menu to do so but with no luck

So is there's something that I'm missing ?
Do you recommend a specific way of doing so ?

Thanks.

When modify_submenu_items returns list of dict items, section_menu tag throws an error.
section_menu tries to access modified submenu item as object attribute in line:

https://github.com/rkhleics/wagtailmenus/blob/01ab3aa6a055128b50368e8047ffb51c4723b680/wagtailmenus/templatetags/menu_tags.py#L368

Workaround is to use object instead of dict.

In the case of footer/header menus, it would be handy to have the ability to make a menu work in common across multiple sites, or duplicate a menu between sites.

Perhaps a duplicate menu button could be added to the Edit/Delete choices.

Wagtailmenus has a hard requirement on wagtail, so upgrading wagtail is not so trivial, since an install of wagtailmenus will revert the wagtail version. Would it not be better to leave wagtail out of the requirements and leave it to users to determine if the versions are compatible?

It looks as though prime_menu_items() is treating the repeated item just like the original. The repeated item could do with marking somehow, so that prime_menu_items() can bypass that logic when dealing with a repeated item.

This is because menu_tags.prime_menu_items() adds a has_children_in_menu attribute to each menu item, which indicates in a template whether or not a sub-menu should be displayed for a particular page. Whether modify_submenu_items adds items or not is irrelevant: If has_children_in_menu isn't True, menu_tags.sub_menu won't (shouldn't) be called for that page, and no sub-menu will appear.

has_children_in_menu is determined entirely by whether the page has suitable children pages or not, and can be done without a need to call Page.specific, because everything can be determined from Page.

It would be possible to pass that logic off to specific model classes, but that would mean that, for every page that appears in menus, we'd potentially need to get the 'specific' object, which would mean an additional database operation for every single page in a menu.

One solution to this problem might be to make use of Page.specific_class. If page querysets could all be fetched using select_related('content_type'), that would add a small overhead to those queries, but would enable us to run Page.specific_class freely. If we could use that to first check for the existence of a has_submmenu_items() method before calling Page.specific, that should (in practice) allow us to avoid unnecessary database operations.

Using apply_active_classes=True in flat_menu but it doesn't add active class for custom URLs.

• Tox environment settings need updating to test with version 1.7
• Any compatibilities (I doubt there'll be any) need identifying and dealing with
• Dev requirements should be updated to use the latest version
• README and install_requires in setup.py to be updated to reflect 1.7 support

Hi,

I am a devops and not a developer.

Because wagtail is magnificent & beautifull, I relied on the intuitive obvious info from docs, examples & common sense to install wagtailmenus.

I don't see the menu in bare-bones step1 default install of wagtail+wagtailmenus, after following the official docs.

• I did this http://docs.wagtail.io/en/v1.6.2/getting_started/tutorial.html without the blog.
• I pip install wagtailmenus
• I added wagtailmenus to INSTALLED_APPS (visible here https://github.com/longwuyuan/devopsdragon.com )
• I added MenuPage in models.py and did the migrate process

I did not get a menu_page.html autogenerated.
I don't see menu even if i use the menu_tag in home_page.html or base.html

I apologise if asking here is not right. But then where else to ask because google throws up nothing and I am not a developer enough to inference from source bits.

Can you help me to just get a menu working.

Regards,
; Long Wu Yuan

It would be nice if the 'Site' element got out of the way unless needed, and users were simply directed to the appropriate edit page, in a similar way to: http://docs.wagtail.io/en/v1.4.3/reference/contrib/settings.html

Hello! First of all thank you for this package :)

I am adapting my website to be multi-language flowing the oficial Internationalisation tutorial from Wagtail using TranslatedField class because, sadly, I cannot use wagtail-modeltranslation since it not compatible with Django 1.10. I am trying to include, therefore, also an international menu based on the selected language. I have seen that to render the menu titles you do:

for item in menu_items:
        try:
            """
            `menu_items` is a list of `MenuItem` objects, that either links
            to Page instances, or custom URLs
            """
            page = item.link_page
            menuitem = item
            if page and use_specific:
                page = page.specific
            setattr(item, 'text', item.menu_text)
        except AttributeError:
            """
            `menu_items` is a list of `Page` objects, not `MenuItem` objects
            """
            page = item
            menuitem = None
            setattr(item, 'text', page.title)

Is there a possibility to define a simple internationalized title? I have tried and tried but I really dont manage to get it working.

Any help would be appreciated, thanks!

Hello, how do you add submenu items using the admin interface?

We've not suffered any problems yet, but we should really be aim to test performance of the various template tags and make changes where necessary, to ensure reasonable performance on larger sites (potentially dealing with 1000s of pages).

I've been playing around with RoutablePageMixin/overriding Page's route method a lot lately, and have been thinking of scenarios where I might want to add further additional items to a specific page's sub-navigation... For example, to access different 'routes' of the same page, such as 'This month' or 'Archive' for a news listing.

Since this behaviour would most likely be common to all pages of a specific type, rather than something that would be defined somewhere in the CMS, I think it would best handled via methods on the MenuPage model, where the functionality could be easily overriden for a custom page type.

I propose the addition of two methods; one to allow further items to be added to the beginning (submenu_items_prepend), and another to allow items to be added to the end (submenu_items_append) of the 'natural' sub-menu items of a page.

The logic in the template tags that works out if an item should be prepended to represent the parent page could be shifted happily to the subnav_items_prepend method on that parent page, which would, by default, return a list containing the additional item, or an empty list, depending on the field values for that page.

submenu_items_append would return an empty list by default, but would give developers an 'in' for customisation.

There's also no reason why those methods couldn't be added to page types that do not extend MenuPage... The template tags could simply always look for them.

Any thoughts?

A some stage within development, a point will likely be reached where the menus required have been set up, and all you'll want to do is create menus with the same handles between sites. Currently,
having an open text field for the handle leaves room for error, as handles can be misspelt, and if a menu is deleted by accident, it's difficult to know exactly what the handle should be should you need to quickly recreate it.

I propose adding support for an optional WAGTAILMENUS_FLAT_MENU_HANDLE_CHOICES field, which would be a list of choices in the standard Django choices format. If specified, the 'handle' field for FlatMenu edit form will be rendered as a Select field with those choices as options.

If the setting is not set, the form will remain as an open text field.

Internally, we've gotten quite used to writing apps to make them fit nicely into Wagtail's Page tree... so we're almost always serving a 'Page' object via wagtail's routing mechanism, which wagtailmenus plays very nicely with. We're also utilising Wagtail's before_serve_page hook to add some helpful data to request.META, which we also use within the template tags.

In reality though, I think it's still very common for developers NOT to use the Page tree for additional apps in their projects (perhaps because they're using a third-party app that's too complicated to adapt, or because they're simply not keen on the idea of being tied to wagtail's routing mechanism). Whatever the reason, I think menu tags should do a better job of 'back-filling' when self isn't present in the context, or CURRENT_SECTION_ROOT and CURRENT_PAGE_ANCESTOR_IDS aren't set on request.META. The section_menu tag is the worst offender, as it fails to render anything unless before_serve_page has set CURRENT_SECTION_ROOT for it.

There's no reason we can't use request.site and request.path to attempt to find a 'current page', even if it means recursively stripping fragments from the URL to find a nearby ancestor. With this, we could at least try to find a 'section_root' page to make section_menu work, and we could get at least some nav items highlighting properly (by identifying a set of 'ancestor ids')

Thanks @ababic for making this package open-source. In the meantime I have over 10 different copy-pasted menu snippet in my projects, so decided to use this package instead!

While adding the main menu is notice the seo_title isn't displayed in my custom menu template.

<ul class="main__menu">
    {% for menu_item in menu_items %}
    <li>
        <a href="{{ menu_item.href }}">{{ menu_item.text }}</a>
    </li>
    {% endfor %}
</ul>

My homepage has for example the title website.com (as it's the site's root page). The seo_title of the homepage is Home (as I don't want to display website.com as my menu item).

I expected Home was returned when using menu_item.text in the upper snippet. Wagtail does use this seo_title as well to override the title attribute.

Does this make sense, of is there a strong reason why seo_title is not taken instead?

Hi rkhleics

This migration keeps being referenced but not applied when running makemigrations:

Migrations for 'wagtailmenus':
  /usr/local/lib/python3.5/site-packages/wagtailmenus/migrations/0018_auto_20161208_0809.py:
    - Alter field site on mainmenu

Any idea what might be the cause?

Thanks,

Russell.

Only having to deal with 'specific' objects would allow us to simplify the code in places, and would give developers access to specific model instances in templates without any extra overhead. However, if there are a lot of different pages types being used, and specific page instances still aren't really needed, there's a possibility that using specific will create extra overhead without any benefit, so a setting to toggle the use of PageQuerySet.specific() would probably be needed.

They were added not long before version 2, but seemed to have gone again, likely during the merge to get all the Menu model changes in.

It would be nice to add the ability to add unique handles to menu items so we have more control over them in the template.
One use case would be to add a specific icon to the menu item based on this handle.

We could use the href, title or slug of the page the menu items refers to but this is not consistent enough.

Two ways we could implement this;

• Extend MenuItem object and add link_handle
• Extend MenuPage object and add handle

I prefer the former, since you don't force users to use the MenuPage. MenuItems are always used so this option will be available by default.

I could pick up this issue and create a pull request for it

Hi,
The docs are not up to date in the github repo: they talk about a context processor, which is not available anymore.

You should also consider using ReST as docs files which willl be more readable on pypi, and more "pythonic", GitHub supports them as soon as they are suffixed with rst.

I'll try to change those files and propose a pull from my own repository.
Thanks !

Use the same pattern as wagtail's Image model, letting developers extend the built-in models to create their own versions with different behaviour, but compatible with the provided template tags

unorderable types: NoneType() > int() error shown when rendering template. Bug after upgrading from 1.6.1 to 2.0.0. Error happens just by invoking {% main_menu %}

Hello, I tried to add my homepage to a menu but it doesn’t show up. I then tried to use / as a custom URL, which would be fine, but then the link doesn’t get the .active class when on the homepage. This happens both in flat and main menus.

Marco

Hello,

When running makemgirations it looks like there is a missing migration that tries to alter fields url_append

    operations = [
        migrations.AlterField(
            model_name='flatmenuitem',
            name='url_append',
            field=models.CharField(blank=True, help_text="Use this to optionally append a #hash or querystring to the above page's URL.", max_length=255, verbose_name='append to URL'),
        ),
        migrations.AlterField(
            model_name='mainmenuitem',
            name='url_append',
            field=models.CharField(blank=True, help_text="Use this to optionally append a #hash or querystring to the above page's URL.", max_length=255, verbose_name='append to URL'),
        ),
    ]

Something that could be related is that the help_text for these fields is not calling the translation function as in
https://github.com/rkhleics/wagtailmenus/blob/master/wagtailmenus/models.py#L122

    url_append = models.CharField(
        verbose_name=_("append to URL"),
        max_length=255,
        blank=True,
        help_text=(
            "Use this to optionally append a #hash or querystring to the "
            "above page's URL.")
    )

So what do you think?

Hi,
is it possible to add i18n to the project ? Only english is supported, I need the french translation...
I'll propose a set of translations in my own repo, and submit a pull.

Currently, database queries are made at each level of navigation output, counting children for pages (where necessary), and fetching those children for display at the next level. I think it would be far more efficient to intelligently query for everything at once and build some kind of pythonic representation of the data that can be accessed directly by all levels of that menu, without having to access the database again.

This could be particularly effective when used in combination with PageQuerySet.specific()

Probably simplest to start with section_menu, as the query will be the easiest to build (it's entirely page driven, and always starts at the same level/depth). main_menu will be trickier because of figuring out how deep to go, but still very possible. With those two cracked, applying to children_menu and flat_menus should be a doddle.

When installing in a new environment (say in docker on deploy), the pip install will fail with ImportError: No module named 'django'.

This happens because setup.py does a from wagtailmenus import __version__ which loads __init__.py which in itself imports django. It should not assume, however, django is already built and installed during a pip install -r requirements.txt.

Hi there,

I've installed wagtailmenus as per instructions. In the wagtail admin when I click settings -> main menu or flat menu I get an error:

`Exception Type: TemplateDoesNotExist
Exception Value: modeladmin/create.html

.../wagtailmenus/templates/wagtailmenus/mainmenu_edit.html, error at line 1
{% extends "modeladmin/create.html" %}`

Apologies if this is a dumb question, I'm new to python and django and wagtail. I've got the up to date versions of all three.

I'd much appreciate anyones help, thanks

There's currently a limit of one "main menu" per site, which has fitted the projects we've used it on internally quite well, and means the templatetags can stay simple, but might that limitation hurt projects that may take a different approach to navigation? Can we increase flexibility without adding unnecessary complication?

The default wagtail form styles don't suit the length of the labels very well, and can sometimes look quite awful...

A few simple style overrides could help us make use of the available space and improve things quite a bit.

For consistency, these tags may as well create some version of a Menu instance that can fetch and return menu items in a similar way during rendering.

This is in the latest version wagtailmenus==1.5.1:

Conflicting migrations detected; multiple leaf nodes in the migration graph: (0016_auto_20160718_0940, 0016_auto_20160930_0645 in wagtailmenus).

This occurs on running migrate or makemigrations

Any plan to support wagtailmenus' tags through a jinja2 extension ? That would be awesome !

Hi, awesome app, but would it be possible to get a signal or two for when a main/flat menu is saved? I'd need it for clearing main menu template cache, which currently only triggers via page (un)publishing.

I need to cache the main menu because it adds +200ms TTFB time to each page load, which is not accetable, fortunately template caching exists. :)

Should cover the basic process of raising issues, branching, submitting a PR, review of the PR, as well as outlining standards for new code.

It's always been a solo venture, so there's been no need for such a thing before. But, it's kind of a requirement now that others may be getting involved.