Working with a site in localhost, and im getting the following error:

Fatal error: Call to a member function set_display() on a non-object in C:\wamp\www\mysite.com.au\sites\all\modules\advanced_forum\includes\core-overrides.inc on line 164

Working with Drupal 6.15, AF Alpha 2 (although i tried the dev version and get the same error)
Have nodecomments enabled, views, chaos tools, author pane, page manager.

The forum index shows fine, as do individual posts and containers, but actual forums within containers show that error.

Could it be a views issue somehow? There are no AF related views listed in my setup, which seems odd. Im sure when i was using the old 6.x.1 version they were listed.

Comments

I'm not sure what happened here. I have a live site and I just noticed this problem so i don't know how long it's been going on. Opps. It was looking for a view that exists in the file system. So I did the down and dirty. I opened advanced_forum_topic_list.view in a text editor, copied the the code minus the first couple of lines, went to views -> import, typed advanced_forum_topic_list as the view title and the pasted the code for the view. I hit return then save and now it's fine and dandy.

Why didn't Drupal acknowledge the file.view??

EDIT: That's weird. I just went to views -> list and they are now available. Advanced_forum_topic_list is giving me the option to revert too. I just went ahead and reverted it without a problem. You know what they say, "if it ain't broke don't fix it."

EDIT Again: It says that it's missing a view.tpl.php file. What is it looking for because it looks ok to me?

Style output: advanced-forum-topic-list-view.tpl.php (File not found, in folder sites/all/modules/advanced_forum/includes/), advanced-forum-topic-list-view--advanced-forum-new-topics.tpl.php, advanced-forum-topic-list-view--advanced-forum.tpl.php, advanced-forum-topic-list-view--default.tpl.php, advanced-forum-topic-list-view--advanced-forum-new-topics--default.tpl.php

EDIT Again EDIT: Weeee........ I just figured out that I'm responsible to theme my own advanced forum (and the whole time I thought Michelle already gone done it for me :). Let me see if I got this correct? I'm supposed to copy advanced_forum_topic_list.tpl.php from the naked file to, say, for example, to the includes folder?

No, you don't need to copy anything. I don't have time to dig into this now but didn't want you going down the wrong path. It should just work with the files where they are.

Michelle

Yeah, I realize that now. I just don't know why it didn't find the views until after I imported the views. Perhaps, I needed to run update.php or something.

The same problem at transition to new version Views 6.x-3.0-alpha2.

I have the same problem on my local machine. Seems to be a bug. I will go and try to fix it by using adamsohn's fix as I need the forum to work propperly fast.

Subscribe--same problem on local site when moving from 6.x-1.1 to 6.x-2.0-alpha2. Ran update, but no dice.

Same problem Here. This happen when I want to enter any subforum room. Please help to get ride from this problem.

i subscribe. made a clean install, without any other module related. it simply doesn't work. any idea?

now, when i disable everything related to views, af seems to work, but what use then the rest of the site.

I just noticed comment #4... AF doesn't currently work with Views 3. Are all of you getting this error on Views 3? Is there anyone getting this error with Views 2?

Michelle

Looks like reverting back to Views 2 fixed it for me.

Broken with Views 6.x-2.x-dev (2010-Jan-27).

Views list at /admin/build/views do not show any of AF views.

Status:Needs review» Active

I'm looking at this code [1] in advanced_forum/includes/views/advanced_forum.views.inc:

function advanced_forum_views_default_views() {
  $files = file_scan_directory(drupal_get_path('module', 'advanced_forum') . '/includes/views', '.view$');
  foreach ($files as $absolute => $file) {
    $view = NULL;
    require_once $absolute;
    if (isset($view)) {
      $views[$file->name] = $view;
    }
  }
  return $views;
}

And this code [2] in views/includes/cache.inc:

function _views_discover_default_views() {
  static $cache = NULL;
  if (!isset($cache)) {
    $index = views_cache_get('views_default_views_index');
    // Retrieve each cached default view
    if (isset($index->data) && is_array($index->data)) {
      $cache = array();
      foreach ($index->data as $view_name) {
        $data = views_cache_get('views_default:' . $view_name, TRUE);
        if (isset($data->data) && is_object($data->data)) {
          $cache[$view_name] = $data->data;
        }
      }
    }
    // If missing index, rebuild the cache
    else {
      views_include_default_views();
      $defaults = module_invoke_all('views_default_views');
      $cache = array();
      foreach(module_implements('views_default_views') as $module) {
        $results = call_user_func($module . "_views_default_views");
        if (!empty($results) && is_array($results)) {
          foreach($results as $name => $view) {
            // Only views with a sufficiently high api version are eligible.
            if (!empty($view->api_version) && $view->api_version >= 2) {
              // Do not cache dead handlers.
              $view->destroy();
              if (!isset($cache[$name])) {
                $cache[$name] = $view;
              }
              else {
                watchdog('view', "View name '@name' is already taken", array('@name' => $name), WATCHDOG_ERROR);
              }
            }
          }
        }
      }
      // Allow modules to modify default views before they are cached.
      drupal_alter('views_default_views', $cache);
      // Cache the index
      $index = array_keys($cache);
      views_cache_set('views_default_views_index', $index);
      // Cache each view
      foreach ($cache as $name => $view) {
        views_cache_set('views_default:' . $name, $view, TRUE);
      }
    }
  }
  return $cache;
}

From [2] it is appears that hook_views_default_views is called twice, first to set $default, second time to run foreach $module and set $results. (Note: $default is unused and seems to be a leftover code, and prompts a bug report in views)

On the first call [1] does require_once for all files which works as intended, but [2] does not use the return value. On the second call [1] will not include any of the previously included files, resulting in an empty return value to [2]. This makes all AF views to disappear.

The fix is simple - change "require_once" to "require" or "include" in [1]. "require_once" is a good practice for top-level code, but for the particular use case inside the loop "require" is acceptable while allowing repeated calls to the function.

Status:Active» Needs review
StatusFileSize
new486 bytes

Patch is attached - please review.

Status:Active» Needs review

I didn't write this code so I'll need to dig into it carefully before changing it. Might be a while. I don't expect to have time to work on AF before the end of the month.

Thanks for the patch,

Michelle

Sure. Or maybe get the community help to review, test and report here.

made change, but whenever i access update.php or clear cache or any admin page, it still gives me blanc page with

array(4) { ["type"]=> int(1) ["message"]=> string(44) "Call to undefined function ctools_include()" ["file"]=> string(74) "/../../public_html/sites/all/modules/advanced_forum/includes/style.inc" ["line"]=> int(24) } n/a

then all gets back to normal when i put back into modules folder AF 1.1 (this works flawless)

i don't know if this is the same bug or another..AF 2 never worked on my configuration. is this trick working for anybody?

I have same error too .

the error is in this code : ( core-overrides.inc )


// When views is installed, we let it take over the topic list page.
if (module_exists('views')) {
$view = views_get_view('advanced_forum_topic_list');
$view->set_display('default');
$view->set_arguments(array($tid));
$view->sort_form = $sort_form;
return $view->preview();
}

i use view 3.X and advanced forum 6.x-2.0-alpha2

What is the way for solving it ?

@alimosavi: AF is not compatible with Views 3.

Michelle

Subscribe--same problem

Status:Needs review» Fixed

I discussed this with merlinofchaos and supermanscott who confirmed the "required" change (as well as pointing out that OG has already made that change). They also suggested using the view name instead of the filename which I implemented as well.

Thanks for hunting this down,

Michelle

Status:Fixed» Closed (fixed)

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

Version:6.x-2.0-alpha2» 6.x-2.0-alpha4
Status:Closed (fixed)» Active

Just as a follow-up, we are seeing this issue using AF 6.x-2.0-alpha4 and Views 6.x-2.12.

In our error log file we regularly see the following entries:

[warn] PHP Fatal error:  Call to a member function set_display() on a non-object in /sites/all/modules/advanced_forum/advanced_forum.module on line 650, referer: /forum

which refers to the following code:

<?php
function advanced_forum_forum_topic_list_sort_form(&$form_state) {
 
$view = views_get_view('advanced_forum_topic_list');
 
$view->set_display('default');    //  <------- this is line 650
 
$view->init_handlers();
 
$view->init_style();
  ...
?>

and...

[warn] PHP Fatal error:  Call to a member function set_display() on a non-object in /sites/all/modules/advanced_forum/includes/core-overrides.inc on line 182, referer: /forum

which refers to this code:

<?php
function advanced_forum_get_topics($tid, $sortby, $forum_per_page, $sort_form = TRUE) {
 
$term = taxonomy_get_term($tid);
 
drupal_add_feed(url('taxonomy/term/'. $tid .'/0/feed'), 'RSS - '. check_plain($term->name));
 
// Views handles this page
 
$view = views_get_view('advanced_forum_topic_list');
 
$view->set_display('default');   // <------ this is line 182
 
$view->set_arguments(array($tid));
 
$view->sort_form = $sort_form;
  return
$view->preview();
}
?>

Did something possibly change with Views 2 that now makes this handling similar to Views 3?

Hi ron_s.

views 6.x-2.12 was released in Dec 2010, and the changes to advanced_forum_views_default_views() which fixed this issue were made a year before the the alpha4 release, and haven't been touched since Michelle committed them in March 2010. So nothing's changed any time recently - I can't see any reason why this issue should have come back.

Can you see your advanced_forum views when you list views on your site? If so, what is their status (default / overidden)?

What sort of cache are you running - e.g. are you using memcache?

I'm having the same issue with views-6.x-2.12 which as of this posting is the most recent 6.x-2 stable release.

I'm guessing this has something to do with caching. For some reason it doesn't think the $view is an object even though that view 'advanced_forum_topic_list' should be loaded.

I've tried clearing the drupal cache and restarting apache (which should clear the APC and memcache) and can't recreate the issue.

I'll check back if it arises again or if I find anything else.

I agree it looks like a problem with views not finding the advanced_forum_topic_list view in the cache, although I can't explain why that would happen.

We could add some resilience and avoid the fatal error by checking we got a valid views object back from views_get_view() before we do anything with it, but this is obviously treating the symptom and not the disease.

For those that are seeing this error - is it only AF you see in your logs? and is anyone seeing this who is not using memcache?

Hey mcdruid, thanks for the response. Yes, we can see the views on our site and they all have a status of default. I think you and acouch are right, this probably has something to do with caching. A couple of weeks ago the AF views "disappeared" for a short amount of time. To make them re-appear we had to edit the views and simply click "save" (no edits, just re-save). This made them return to the page.

We haven't "lost" the views since then, but we still continue to receive the error messages in our logs about 8-10 times a day.

We're running Pressflow with Varnish, Memcache, and APC. We have cache_views being cached with memcache, and cache_views_data cached with APC. We only see AF errors in our logs... we have not seen errors for any other module.

We found that the problem was with our memcache prefix. The view wasn't loading even though it was in the database because it wasn't available in memcache.

So, is there a solution to this issue?

Category:bug» support
Status:Active» Postponed (maintainer needs more info)

Is this still an issue? There's multiple people on this thread and one reported they found the problem for them but no comments from the others as to whether that was the solution.

Status:Postponed (maintainer needs more info)» Fixed

as I suggested in #26, I've added a check in both places where AF calls views_get_view.

If an object doesn't come back, AF will now give up rather than trying to access methods / functions on the view.

In the case of the user-facing advanced_forum_get_topics function, AF will now output a simple error message if this situation arises.

We could also log the error to watchdog, but I note that AF doesn't do so for anything else - let me know if this is something people would like to be added so they have some record of when this happens.

I realise this is more of a workaround than a solution, but it at least prevents fatal errors.

I have seen this sort of occasional 'soft error' with views and memcache on non-AF projects before.

I'm not sure what else AF can do if it asks for one of its own views and it doesn't come back.

StatusFileSize
new1.21 KB

This is the patch, which I couldn't attach to the last comment for some reason.

Status:Fixed» Closed (fixed)

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

Status:Closed (fixed)» Needs review

Sorry for reopening if that patch in #32 was committed. To me it looks like "fixed" was set in error, I think it should have been "needs review".

Status:Needs review» Fixed

Thanks, but I did commit the patch:

http://drupalcode.org/project/advanced_forum.git/commit/2e8058c

...and deliberately set the issue to fixed.

Status:Fixed» Closed (fixed)

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