View links are not displayed (rendered) in menu

It sounds like it could be an issue with Nice Menus. Create a menu block and see if that generates properly first.

Also check to make sure your theme doesn't override the theme_menu_link().

Try creating a block instead of a page in the view. Also please send a screenshot of the advanced fieldset open and the preview to show that the view outputs content.

Lol nevermind, you beat me to it. Try the a block display instead though... page displays tend to render differently.

Awesome, I'm glad I could help!

I have exact the same problem. My link is rendered as
<a href="/nl/%3Cview%3E" title="">MENU ITEM</a>

Where "MENU ITEM" is the menu item entry title provided bij de view.

It is working with vanilla Drupal (Garland theme), but not with the Bootstrap Theme nor with my BS subtheme. Does anyone else has issues with Bootstrap theme and Menu Views? Can't seem to find what causes the issue.

I'm using Menu Views 7.x-2.3 with Drupal 7.43, Views 7.x-3.14 and Bootstrap 7.x-3.5 theme

If I disable the menu templates in the Bootstrap theme, it is working !!
It seems like the provided menu template with the function bootstrap_menu_link(array $variables) {} is what is causing issues.

Maybe this can help somebody else.

@fotograafinge, I think you need to spend some time reading the Bootstrap documentation. The Bootstrap templates exist so they can be extended into a subtheme and customized as needed.

@ron_s: true. But Menu Views can't work if theme_menu_link is used in a template. So extending a template that has that, does not help. And I didn't need that BS template, so for me it was no problem to disable it.

See also #1:

Also check to make sure your theme doesn't override the theme_menu_link().

Additional information:

The same problem seems to appear when using the site_map.module. The menu items which are menu views show a broken link without title:

https://www.example.com/%3Cview%3E
error code: 404 (not found), linked from page(s):
https://www.example.com/sitemap

Any ideas how to fix this, for example hide the item completely at least?

See https://www.drupal.org/node/2027169#comment-11568481.

Whao, that looks very good. I will now test it, but the code itself looks good and logically correct.

I don't why this issue is marked as "fixed". I don't see any fix, nor if the fix should be with menu_views or bootstrap theme.

I'm seeing the same issue using menu_views 7.x-2.4 and Bootstrap 7.x-3.8. I was not getting this bug using Bootstrap 7.x-3.0 so I imagine it was introduced after 3.0.

@nubeli, the issue should have probably been marked as "Closed (works as designed)" as the OP got it working (for this particular issue). See the related issue (which I'm linking now) @ron_s mentioned in #14.

@fotograafinge #9/10

yes, i'm find i'm having the same general outcome.. BOOTSTRAP BASE THEME. with makes #11 correct.. in that it's a theme issue. Bootstrap does too much re-writting of normal drupal output.

Bootstrap does too much re-writting of normal drupal output.

Actually it doesn't do enough, but that's beside the point.

In regards to menus though, yes... Bootstrap's menus are intended to be simple dropdowns. If you wish to implement this module using Bootstrap, you will have to override the menus in your sub-theme and merge both what this module expects and what Bootstrap expects.

This is the nature of custom site building: not all modules/themes will work together out of the box, that's why it's called site building.

(: well..actually: mashing modules and themes togethers is assembly.

doesn't do enough

yikes. personally, the only good thing about bootstrap is it's grid system. otherwise, it's nothing but every bug i have to fix in projects where someone else thought 'hey we need a base theme'

https://www.drupal.org/project/dawn <-- this is my simple answer to that. cheers.

otherwise, it's nothing but every bug i have to fix in projects where someone else thought 'hey we need a base theme'

Then, may I ask, why didn't these "bugs" ever make their way back to the base theme as issues to be addressed?

yikes. personally, the only good thing about bootstrap is it's grid system.

Wow... if you seriously think that, then you don't understand the power of what Mark has created. I find it to be extremely flexible and well integrated with Drupal. Does a lot of things I wish other themes did.

sorry, i didn't first realize you maintain both projects.

#21 no. for long term life span of projects i remove those components that cause such trouble. this is usually a budget/timeline reality.

both 21/22. IMO: 'themes' often try to do too much, when in the most basic concept a theme is a bunch of regions to render blocks. at least until issues like #2652542 #474684 are addressed -- of course, then themes would basically be modules anyway.. (then we just need a method to produce layouts..)

=================
regardless, this issue should not be closed. clearly, regardless of active theme and related menu enchantments other devs are using -- there is a bug in this module.

sorry, i didn't first realize you maintain both projects.

I don't maintain Bootstrap, I just appreciate good quality work when I see it.

IMO: 'themes' often try to do too much, when in the most basic concept a theme is a bunch of regions to render blocks.

To a certain degree, hasn't that philosophical ship sailed a long time ago? Look at all of the most popular themes -- Bootstrap, Zen, Omega, AdaptiveTheme -- by that guideline, they all "often try to do too much." Nothing wrong with that opinion. However, if that's the case, why not just use the Dawn theme you created, and let each project compete on their own merits?

regardless, this issue should not be closed.

As discussed above, bootstrap_menu_link and theme_menu_link can be overridden to do anything you want to do.

I see this situation as no different thantheme_ functions that come with the Date and Calendar modules. Do I like how Date displays content out-of-the-box? Absolutely not! However, I consider what we receive as just a "starting point." We can use the tools we are given to turn it into whatever we want.

I'm not sure how this scenario is much different? Unless maybe you disagree with how modules use theme_ functions too?

@ron_s, I think he was referring to me. To clarify though, I only maintain the Drupal Bootstrap base theme, not the framework itself lol

---

#21 no. for long term life span of projects i remove those components that cause such trouble. this is usually a budget/timeline reality.

That is certainly your prerogative. However, I'd suggest not putting down something that clearly works for the majority of people. This is open source, if you're not willing to, at the very least, open an issue about a "bug" then how are we supposed to know where your pain points are? Magic? It doesn't work that way. I get that budget/time is often a factor, but you could open issues describing your "bugs", even if you don't have time to fix/work on them.

'themes' often try to do too much, when in the most basic concept a theme is a bunch of regions to render blocks

This is, more or less, the nature of Drupal (especially in D7). What core/modules provides isn't always going to work for a theme, especially an external framework like Bootstrap. An external framework comes with a lot of assumptions, sure, but that's why a base theme like Drupal Bootstrap is important: to override core/modules so their markup is inline with what Bootstrap expects, not Drupal. That isn't doing "too much", that's necessary.

at least until issues like #2652542 #474684 are addressed -- of course, then themes would basically be modules anyway.. (then we just need a method to produce layouts..)

Unfortunately, that's all D8 and why I've been working on #2784265: Refactor module to be plugin based and allow template settings.

regardless, this issue should not be closed. clearly, regardless of active theme and related menu enchantments other devs are using -- there is a bug in this module.

I think you're confused with how Drupal's theme system works. This module does some pretty advanced ("hack-ish" to an extent) alter of the theme registry to inject it's own menu output. In reality, this is where I normally scoff at modules attempting to do such things (because theming output should be left to a theme). However, that isn't possible in 7.x due to how convoluted Drupal's use of theme/process/preprocess functions are (especially in menus/menu items).

@ron_s is correct. By default, the base theme supports a very simple dropdown menu setup, nothing more. And because the base theme also provides it's own menu output, it overrides what was previously overridden by this module. That's how Drupal's theme system works.

If a developer decides to use modules like superfish, mega_menu or some other module (like this one) that will, undoubtedly, stray from the "norm" (in whatever sense it deems necessary), then that is when the job of merging something like into a sub-theme via custom hook/template overrides. There is no "bug" here.

---

Could things be different, perhaps maybe in D8 (if this module ever gets ported). That being said, there's nothing more that can be done here, despite how much you are protesting.

Not really related, but I'd recommend reading a blog I posted about Drupal/Bootstrap (including my comments):
http://www.drupalwatchdog.com/blog/2015/8/drupal-should-use-external-fro...

Given the hacky nature of this module I just decided to adapt the bootstrap_theme_link() and insert a view there with views_embed_view(). So I'm not really resolving the module with the theme so much as getting rid of this module. Fewer moving pieces.

And that's certainly your prerogative, no need to bash something just because you don't understand how the system is supposed to work.

I'm not bashing it, I don't mind using some hacks where it makes sense. Above you called it '"hack-ish" to an extent' so I'm agreeing. Would be good to get the two to play nice but my use its not necessary.

You took what I said (advanced alterations of the theme registry) out of context. I was merely recognizing how some may interpret how this module may appear to border-line as "hack-ish" is all. I wasn't calling the entire module itself "hacky"... as you did.

I'm really not "upset", just wanted to clarify that this module/solution is certainly not everyone's cup o' tea, especially if it's having to compete with a theme like bootstrap. There are certainly other solutions, as you so pointedly put.

In case others land here, but the fix above doesn't work for them e.g. not using Superfish, this option might work for you: https://www.drupal.org/node/2252301#comment-11868122.

exactly getting same as #13 but only using base bootstrap module with bootswatch theme United and without using superfish/nice menu.
That make this module is theme dependent or doesn't work with a theme implementing theme_menu_link( in this case
bootstrap base module)

@markcarver
if I want to use bootswatch theme which template file do I need to modify? because there will no separate template files when using CDN?

I get that people are having a really hard time understanding the complexities of how the theme system works, but the "solution" is really... really, not that difficult to implement:

/**
 * Implements hook_theme_registry_alter().
 *
 * {@inheritdoc}
 *
 * Supports the Menu Views module.
 *
 * Because Menu Views is a module, its alter hooks are executed before any
 * theme alter hooks are. If a theme alters the theme registry (such as a
 * popular base theme like Bootstrap), it can potentially replace everything
 * that Menu Views already did.
 *
 * If Menu Views does not work with a theme, then add the following to your
 * sub-theme so it will rerun Menu View's theme registry alters.
 *
 * Replace THEMENAME with the machine name of your sub-theme.
 *
 * @see https://www.drupal.org/node/1908910
 */
function THEMENAME_theme_registry_alter(&$registry) {
  // Re-run Menu View's theme registry alters.
  if (function_exists('menu_views_theme_registry_alter')) {
    menu_views_theme_registry_alter($registry);
  }
}

Proof of the above working in Bootstrap:

Granted, this has all the view wrapper crap around it so that's why you see the bullets, but if you really wanted to, you could easily modify the view template for a view and remove all the <div> and <ul> element so it only spits out <li> elements and works with Bootstrap's dropdown.

Thanks for providing a solution @markcarver.

I would say that although the solution is, as you say, "really... really, not that difficult to implement", it is not obvious to the majority of people. Especially when the people are site builders not expecting that they'll have to add code.

it is not obvious to the majority of people

Perhaps...

The reality is that the "majority" of people simply don't understand the fundamental principles and differences between modules and themes.

I constantly see Bootstrap referred to as a "module" and it bugs me to no end.

Because it is quite obvious when one realizes that the module (menu_views) alters the theme registry but then the theme (bootstrap) resets it.

Especially when the people are site builders not expecting that they'll have to add code.

Then maybe these people shouldn't be using conflicting modules/themes in the first place if they're not willing to learn how to overcome some rather basic and common Drupal obstacles.

@markcarver
I apologize for mistakenly mentioning Bootstrap as module instead of a theme in my previous comment and I was completely aware of it as theme at the time of commenting but misspelled.

#33
is that mean I must create new sub-theme of bootstrap even when bootswatch's pre-available theme is set as active?

@nithinkolekar, yes, create a CDN Starterkit sub-theme.

@33
Please add this to the module README. it'll help so many (:

Or people can just learn how Drupal works... but ok...

I went ahead and added it to the project page anyway, which should be sufficient.

#33 worked for me, thanks!