Enabling disabled views presents a path to the new view which leads to 404

Thanks for the followup ...

Yes, tried a menu_rebuild() after enabling and it doesn't help ... debugging efforts are currently pointing to the enabled view (archive in my example) not getting pulled into the views_menu_alter hook by views_get_applicable_views (maybe it's somehow not deemed applicable ...).

I'll certainly give it a try on the dev branch.

Confirmed issue seems also present on the latest dev *release* tarball (not sure if there's any difference between that and git master, but haven't tried git in any case).

I'm going to keep debugging this menu_alter a bit ...

Spoke too soo - it definitely does come out of views_get_applicable_views. I'll avoid running commentaries for now until I have something more concrete.

Erm .... the disabled-and-enabled view's path has now started working, after about 10x menu_rebuild()s during debugging. It could have appeared any time after, say the 3rd though. Trying to repro on another one.

Now appears to work after one menu_rebuild() post-enable.

It looks like I may have tested the menu_rebuild whilst still using the previous release codebase, then upgraded codebase after that test, confirmed that the view was still broken post-enable and didn't reconfirm after multiple menu_rebuilds

.... And again, no changes to code since last test, but this time multiple menu_rebuilds are not getting the /frontpage view to enable. I'll see if my logging caught anything of interest. I might have to continue this tomorrow.

We have a fantastically intermittent bug.

I'm probably just losing my mind ... now none of my debug logging in views_menu_alter is firing at all, on multiple menu_rebuild()s. By all appearances, the menu is not being rebuilt at all, or at the very least the menu_alter is not running. The hook is definitely registered though:

drush php-eval "print_r(module_implements('menu_alter'))"
Array
(
    [0] => comment
    [1] => views
)

OK, so trying to debug menu_rebuild() now ...

function menu_rebuild() {
watchdog('dbg', 'MENU REBUILD START');
  if (!lock_acquire('menu_rebuild')) {
    // Wait for another request that is already doing this work.
    // We choose to block here since otherwise the router item may not
    // be available in menu_execute_active_handler() resulting in a 404.
    lock_wait('menu_rebuild');
    return FALSE;
  }

watchdog('dbg', 'MENU REBUILD START TX');
  $transaction = db_transaction();

watchdog('dbg', 'MENU REBUILD START TRY');
  try {

The first 2 of these get logged, the 3rd one ('TRY') does not. Similarly, a watchdog at the end of the func just before the return does not get logged. Curious.

menu_rebuild() does return TRUE, so it does complete.

Solved where the debug messages were going missing, using file logging from now on ...

So, looking at this, which is called on enable (views_ui.class.php):

function set_item_state($state, $js, $input, $item) {
    ctools_export_set_object_status($item, $state); 
    menu_rebuild();
}

there is already a menu_rebuild there, and it does get called (already confirmed this), I have a lot of debug logging still in there, so now time to work out why this menu_rebuild() doesn't do the job, but another manual rebuild later does.

So ... the issue appears to be, at the point where the menu_rebuild is called, as mentioned in #10, the view still has disabled => 1, so doesn't get considered during that menu_rebuild()... Will try and find out why that might be.

Seems that during menu_rebuild, we're dealing with statically cached views. This can be solved in views.module like this:

function views_get_applicable_views($type) {
  // @todo: Use a smarter flagging system so that we don't have to
  // load every view for this.
  $result = array();
  $views = views_get_all_views(TRUE);

Setting the $reset param to TRUE to refresh those cached objects. I've grepped ctools and views for other uses of this function and there aren't many. I'll probably ask advice on whether we always want to reset cache when calling this function (most consistent, but could cause performance problems if used a lot) or just on this one case (when calling views_get_applicable_views('uses hook menu'))

Attached is the patch equivalent to the change pasted above and I've tested this and it does clear up the issue: it is now possible to enable disabled views and have the menu link work immediately.

What I'm not sure about is where this function gets called elsewhere. I know there is only one instance it is used in views, but several instances of views_get_applicable_views('returns context') appear in ctools. I can't say for sure whether this cache reset on every call to views_get_applicable_views is necessary for all calls, or whether limiting it to "uses hook menu" calls would be better.

Attached is the patch equivalent to the change pasted above and I've tested this and it does clear up the issue: it is now possible to enable disabled views and have the menu link work immediately.

What I'm not sure about is where this function gets called elsewhere. I know there is only one instance it is used in views, but several instances of views_get_applicable_views('returns context') appear in ctools. I can't say for sure whether this cache reset on every call to views_get_applicable_views is necessary for all calls, or whether limiting it to "uses hook menu" calls would be better.

Apologies for the double post.

Excellent, thanks.