I had a complex site using version 1 of this module for about 100 menu items spread across six separate menus. It was working fine.

I just did the upgrade and now all of the existing menu_views menu items have been turned back into regular links.

If I try editing a link to convert it back to a View, the views data is still there... but the "Parent Item" dropdown only shows the site's main menu. I have a couple dozen other menus on the site. None of them are showing up in the dropdown. So I can't even manually go back and fix each link.

So... yeah. Good module, many thanks for all your hard work on it, but the upgrade process is completely broken. You should stick a large warning on the page telling people not to upgrade until this is resolved.

Comments

markhalliwell’s picture

Priority: Normal » Critical
Status: Active » Fixed

First, I did warn in the release notes (http://drupal.org/node/1815540), I will also put in on the front page:

This is the first release candidate and is stable for production use. This release may, however, contain a few minor bugs that will only be discovered with actual production use. Use with caution.

Second, you use the past tense "had" and from the tone of your message I seems as if you upgraded your production site before actually testing it locally? Even if you don't have a tiered development environment, you should have follow step 2 in: Updating Modules, Backup your Files and Database

Third, I thank you for pointing out these issues. It is extremely easy to overlook minor coding bugs such as these when doing such an extensive rewrite of the module.

Lastly, I'm releasing 7.x-2.0-rc2 here shortly as these are indeed critical issues for an upgrade path (http://drupalcode.org/project/menu_views.git/commit/60e5d4a). Seeing as you have probably already ran update.php, the menu items will have already been updated. However, with the parent menu item fix you should be able to go ahead and re-work your menu structure the way you need. I apologize for any inconvenience this has caused you.

reallyordinary’s picture

I apologize if I came across as snarky in my original post.

I tried the upgrade on a development copy of the site. Everything was backed up, so it was quick to restore to the pre-upgrade version.

I'll try out rc2 shortly. Fingers crossed. Thanks for addressing this so quickly.

markhalliwell’s picture

I understand how frustrating modules can be, believe me, I know lol. Out of your entire message though, it was really only the last sentence that seemed completely unnecessary and "snarky" as you put it. See: http://drupal.org/dcoc#respect. Often times, just informing a module maintainer about an issue is usually the quickest step in catching things like this. We're not superhuman and can easily overlook some small things.

reallyordinary’s picture

Lesson learned. Next time I'll contribute a patch instead of snark.

reallyordinary’s picture

Ok, well... tried this, and it did upgrade... the links are correct... cool... but... it wiped out another module that was previously working.

I have the Menu attributes module installed -

http://drupal.org/project/menu_attributes

It was working with the 1.4 version. I had access to it on Menu View items.

Now... it's still working on regular menu links. But... it's vanished on Menu View links. The fields are no longer there.

I also have Menu per role installed -

http://drupal.org/project/menu_per_role

- and that's vanished as well. But I'm not really using it, so not as big a deal.

markhalliwell’s picture

In all probability, it didn't actually remove the attribute options from the menu item during the upgrade. On line 140 of menu_views.install: $options['menu_views'] = $item;. I only replace the menu_views array item, not the entire $options property. The attributes array is probably still there, but just isn't displayed on the menu view item because it's a view and not a link.

What happen in 1.x is that there was a lot of confusion between "attaching" a view to an existing link or replacing the link with a view by setting it's path to <view>. So to simplify this in 2.x, admins can now configure a menu item based on menu item type: link or view. This toggle is located at the top of the form and changes the entire form depending on which type you select.

If you switch the menu item back to a link, the attributes should still be there or at the very least the module's extra options should appear in the form. In any case, modules that deal with the menu system in this way really only pertain to links and not a view, which should be handled differently as views really are a beast of their own.

This all being said, my guess is that we need the ability to add classes to the <li/> element? I've have been thinking about wrapping the entire view (and view title if it exists) with something like: <div class="menu-view"></div>. Perhaps, however, classes should just be added to the <li/> element instead. I agree that some type of this functionality is definitely needed. Created issue: #1824588: Create option to add classes to the menu item <li> element.

In regards to whether the link is shown based on access, that could easily be handled by a view's access logic. As it stands right now though, Menu Views does check for views access with $view->access($item['view']['display']), but if it fails it actually just renders the default theming function. That default function probably would fail in retrospect though because it doesn't have the proper configuration for a normal link. We should probably have more control in place for determining what happens when it fails. Created issue: #1824590: Use a views access to hide menu item.

These are great questions and observations! Things like this only get discovered from actual usage and with sites that have different configurations and modules enabled.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.