15

I'm getting a frequent, intermittent error from the Advanced Forum module that causes a 500 error when it occurs (WSOD). On production, it's happening about 20 times per hour, on probably 2-3% of all forum page loads per hour. It is consistently intermittent. Locally, I cannot consistently reproduce the error, but it does occur.

The error is on

Line 232 o f sites/all/modules/contrib/advanced_forum/includes/core-overrides.inc`:

Call to undefined method stdClass::preview()

The problem lies with the advanced_forum_get_topics() function:

function advanced_forum_get_topics($tid, $sortby, $forum_per_page, $sort_form = TRUE) {
  $term = taxonomy_term_load($tid);
  drupal_add_feed('taxonomy/term/' . $tid . '/feed', 'RSS - ' . check_plain($term->name));

  // Views handles this page
  $view = views_get_view('advanced_forum_topic_list');
  $view->sort_form = $sort_form;

  return $view->preview('default', array($tid));

}

Essentially views_get_view() fails to find the view and the object isn't created as expected on the return line. So the problem seems to lie with Views occasionally not knowing the view exists. This makes me think it's a hook problem.

Where it starts to get odd are the implementations of hook_views_default_views() and hook_views_plugins(). According to views.api.php hook_views_default_views() should be in a file called MODULENAME.views_default.inc and hook_views_plugins() should be in a file called MODULENAME.views.inc. However, both files are in the MODULENAME.views.inc file.

From views.api.php:

  • hook_views_plugins()
    This hook should be placed in MODULENAME.views.inc and it will be auto-loaded.
    MODULENAME.views.inc must be in the directory specified by the 'path' key returned by MODULENAME_views_api(), or the same directory as the .module file, if 'path' is unspecified.

  • hook_views_default_views()
    This hook should be placed in MODULENAME.views_default.inc and it will be auto-loaded. MODULENAME.views_default.inc must be in the directory specified by the 'path' key returned by MODULENAME_views_api(), or the same directory as the .module file, if 'path' is unspecified.

I tried splitting up these routines into the seemingly correct files. This caused Views to consistently find the Advanced Forum view (as indicated that it appeared in the Views GUI list) but not see the plug-in. The pages in Advanced Forum ran fine, but the views were blank because they referenced a style plugin provided by Advanced Forum that Views was no longer seeing.

I assume I'm missing something about Views hooks, but I'm totally stumped.

  • Stack: Drupal 7, Views (7.x-3.3), CTools (7.x-1.0), Advanced Forum (7.x-2.0)
  • PHP FPM, APC, nginx, Redis
  • I didn't find anything helpful in this d.o issue

UPDATE 1: While I have not solved the root cause, it does appear that disabling Redis and reverting to Drupal's default database-based cache storage mechanism stops the problem from occuring.

UPDATE 2: I can reliably replicate the issue on local by doing a flushall in Redis. The first page load of looking at a forum listing will fatal out. The second page load (and all subsequent) work fine. UPDATE: I have to hit the admin Views listing page to clear the error.

UPDATE 3: On further troubleshooting the issue appears to be caused by the Views cache not properly being rebuilt after a cache clear, only when using Redis. The issue does not occur when reverting to standard Drupal cache. When the issue occurs only 2-4 cache entries exists for Views, as opposed 100+ when the cache is properly built. Visiting the admin views list page causes the cache to be fully built and the issue does not occur. I need to verify if hitting any View view page causing the issue, or just the advanced forum view.

UPDATE 4: A helpful user on IRC has suggested this might be a problem related to Views cache race condition issues: 853864, 1102252

  • Have you tried creating an issue in the Views, Ctools, or Advanced Forum queue? It looks to me like the question at hand is does Views or Advanced Forum currently support redis? As far as I am aware of, Views uses a relational query language (SQL) to construct it's displays. I am not sure how well that would play out with Redis (a key-value store). This is not really an answer, but then, I personally don't know if there's an answer to that. I also recommend that you reach out the drupal IRC channels for this question. Good luck. – amateur barista Aug 6 '12 at 5:10
  • Interesting setup you have there. – amateur barista Aug 6 '12 at 5:10
  • I'm only using Redis as a drop-in replacement for Drupal's cache backend, so it should be transparent to Views. I posted to D.o without luck. drupal.org/node/1110688 – Justin Aug 6 '12 at 13:55
  • @amateurbarista It's Pantheon Drupal. – Justin Aug 6 '12 at 20:13
  • 1
    Are you in a position to try other cache backends? That could potentially identify whether you are having a problem with Views or with Redis. – mpdonadio Aug 7 '12 at 18:16
1

It sounds like you found the right answer from the IRC. "Consistently intermittent" in my experience is when there are two sources filling the cache. Most common is when you have a development site and a staging/production site on different code bases but same database. The drupal-provided caches that I have read code for connect to the database, so routing/function information that is cached will cross contaminate. Hitting the admin/modules page will refresh the module cache and locations, hitting the admin/views listing page clears your error because it refreshes the site's understanding of views from the perspective of your site instead of the perspective of whatever is conflicting with you.

If you have server admin ability, change the password to your site's database and the password in your settings.php, and see what breaks. Your listings should stop being corrupted and what is tampering with them should break ... unless it is directly connected to your site and using your settings.php file.

Also, check to make sure there are not multiple installations of the views module in your docroot.

protected by Clive Jan 23 '14 at 11:43

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.