views_embed_view is not returning values

I had a similar problem and with a little debugging found that the name of the displays (ie the first argument passed to views_embed_view()) now use underscores (_) and not dashes (-).

For example, here's what used to work:

Hope that helps

This is not working for me. My display was called Image, so no dash. Lower case also doesn't work. I quess this change is breaking much more sites? It is definately breaking compatibility with the gmap module. That means that gmap users cannot use this version of views.

Its not the name which is displayed, its the internal name. Have a look at the display tab, and hover the tab. Then there is the display-id in the link.

I can confirm that our website is affected by this change... the workaround for us was to change the second argument from 'Page' to 'default', but I guess it won't solve all problems for others.

views_embed_view never accepted a dash in place of an undescore.

If your gmap style is not working, please read the release notes.

Fact is that my function was/is working with the previous version of the views module; so I guess something has changed. The gmap issue seems to be fixed in http://drupal.org/node/623234.

I think that the change here was from #554016: views_embed_view() does not check access, in which an access check was added to the views_embed_view() function. If a user does not have the 'access all views' permissions, I think they won't be able to see the view... Have you (@cronix) tried granting that permission to the user's who can't see the embedded view?

'access all views' means that access control for that role will be ignored. I don't recommend adding it.

It is not only an issue for gmap:
http://groups.drupal.org/node/34812
it is also an issue for modules like Timeline which has similar pop ups and uses Views and it is not offering the information.

I am changing the priority to critical because I can see already a lot of people affected with serious consequences: "popular function unusable". I hope it is ok to do so.

The release notes explicitly say that styles provided by some modules might be broken due to changes in rendering order.

Marking this non-bug as critical won't change that. It is your responsibility to read the release notes before updating a module, especially when there are complicated dependency chains.

Merlinofchaos,
I really respect your excellent work but please try to think like you were and end user.

To say that:

styles provided by some modules might be broken due to changes in rendering order

is meaningless to some of us. Not in my wildest dream I can imagine that it means that affects the pop up output of two of my modules.
What we check in the module is the "Recommended" version, which is truly what we "understand".

Sorry about changing the status.
If I understand correctly, you have changed something that affects other modules, however those modules were suposse to do something properly and therefore it is not the Views module problem, and that is why it is now a "won't fix" status.

If that is the case, the category must change from "bug report" to "none" or "support request" I guess.

I am returning to the 2.6 version until this is fixed "somewhere else", unless it is not recommended:
http://drupal.org/node/488082

Unfortunately, I am given no control over the 'Recommended' status of a release. If I could, I would've waited before having it marked recommended, but drupal.org automatically marks the latest release as recommended. Heck, if I could get all the module developers to coordinate this stuff, I would've. Of course, I didn't actually realize how extensive this breakage would be, I thought it would be less than that.

That said, I will not apologize. The release notes are the only way I have to communicate. If you see a warning like that in release notes, and you upgrade without backing up first and checking on a test site, it is your responsibility. This is open source software, and I do what I can, but these things happen.

Thank you, thank you, thank you noahb. My block also disappeared when upgrading to 6.x-2.6 to 2.7. Changing 'block-1' to 'block_1' solved my problem. My call to

views_embed_view('sunset_images', 'block-1');

started returning NULL after the upgrade until I made this change.

Sorry, I have to disagree with merlinofchaos. In my installation, version 2.6 did in fact accept the dash.

-- Kari

Again, the fact that it appeared to accept 'block-1' was a bug. It did not, in fact, accept it, it actually reverted to the 'default' display, which was incorrect behavior.