Default views do not appear correctly until edited

Could it be, that you do some caching? Or do you have some arguments? This could cause the drupal_not_found.

You should debug_backtrace from drupal_not_found, so you can see whats causing the problem?

Note that when you add a default view to code, its menu options will not be visible until a menu_rebuild() is performed. (This is also true if you make changes to a hook_menu() implementation in code, which is essentially what you are doing). This is consistent with what you are seeing, so I think what you need to do is use devel.module to rebuild the menus after you add your default view to code.f

Visit admin/build/modules -- that page always rebuilds the menu.

Sorry to reopen, but I'm facing this issue right now.

I created a module with a hook_views_default_views() with a view that contains a page display at "/myview".

hook_views_api() is there. I double-checked the syntax, and everything looks ok. Right after I enable the module, the view is listed on admin/build/views. But if I navigate to "/myview" I get a 404. If I clear the cache using either the devel module or by going to admin/settings/performance and clicking the "Clear cache" button, then when I access "/myview" the view works perfectly.

I included the following command in my mymodule_install() but it didn't solve the issue:

     views_invalidate_cache();
     menu_rebuild();
     cache_clear_all();

Also tried the code above in mymodule_enable(). It didn't work either.

What bother me most is that by inspecting some modules that do almost exactly what I'm trying to accomplish (for example, Views Bulk Operations), I can see that those module do nothing to make their page views work out-of-box.

Of course, I can clear the cache aftert installing the module, but it's a nuisance, and it looks very unprofessional to my clients which keep me asking "why the heck you don't clear the cache on the code?". Not to mention that that's not how the Views API are meant to work.

Any clues of what might be happening?

Wow. You totally should not need to clear the menu; activating a module does that.

Is there something strange about the location of your hook_views_api()? Maybe it's somehow not triggering the first time -- like if you use hook_init() to include a file that has your hook_views_api() it's possible that doesn't actually get run when your module is activated, but only immediately after?

I don't have any other good ideas, so I may need to see the module. Possibly could you strip down any business specific stuff and put it in a sandbox if my advice here doesn't help?

Merlin, thanks for your quick response.

The module is actually very simple. If you strip out my hook_block() and hook_footer(), mymodule.module will contain just:

function mymodule_views_api()
{
     return array(
	  'api' => 2
	  );
}

Then mymodule.views_default.inc contains:

function mymodule_views_default_views()
{
     $views = array();

     $view = new view;

     $view->name = 'admin_myview';
             // (...straight copy'n'paste of the view export...)
    
     $views[$view->name] = $view;

     return $views;
}

Actually, the path I'm using is "admin/content/myview". I've just abbreviated to "/myview" do make describe the issue easier. Of course, I'm testing using the adminstrator account. Does it make any difference?

BTW, I tried to debug using your instructions on http://drupal.org/node/683324#comment-2476348, and one thing I noticed is that right after I enable the module, no entry for "admin/content/myview" appear on the menu_router table. The entry is created as soon as I clear the cache.

Last details: my local installation is using 2.10. My client is using 2.11 and is experiencing the same issue. Is there any feature/bug fix in the latest 2.12 that may solve it?

This is happening on my development machine, so I can put debug statements in the code to help solve it, if you think it's needed.

Update: in the initial development phase of the module, I didn't know about hook_views_default_views() and created the view in my .install file as per the instructions in http://drupal.org/node/685432. It worked flawlessly. But as soon as I discovered that that's not the correct approach, I deleted the view manually using the UI and started implementing hook_views_default_views().

Perhaps a pointer to the old view is dangling somehow on the db even after I deleted the old (non API-based) view?

Important: I didn't test it on a clean install yet, but I bet it would work out-of-box. But given that my client's site is up and running, I'll have to know how to solve it on their site anyway, so I didn't bother.

Are you enabling the module via drush or the module page?

I have noticed that older versions of drush do not actually perform a menu rebuild after module enable. That's a bug that's fixed in current versions of drush.

Merlin, to make testing faster, I created a script to disable and uninstall the module using drush ("All-Versions-2.1"), but enabling the module was always done using the UI.

Unfortunately, I don't have any good ideas what might be wrong here. You could try latest -dev but I can't remember if there's anything in latest -dev that affected this sort of thing.

Note that whatever solution we come up with here needs to also be used on the taxonomy context, which has a similar UI in that it lets you pick a single term.

Hi

I am closing this issue to clean up the issue queue. Feel free to reopen the issue if there is new information and the problem still resides. If not please make sure you close your issues that you don't need any more.

Maybe you can get support from the local user group. Please take a look at this list at groups.drupal.org.