Rotor explodes for logged-in users

CORRECTION: After more testing, I've found that the problem also exists for anonymous users. I didn't check them out enough. Apologies for the confusion.

Additional information:
I've tested a bit more and I find that immediately after a Drupal cache clear through one browser, the first page refresh in another browser allows the rotor to function correctly. Refreshing again breaks it. Checking the transfers through Firebug, the first refresh shows all 200 codes for the css and js files meaning, of course, fresh loads. At the second refresh, all css and js files show 304 not modified, as expected. But the rotor is back to being broken again.

EDIT - more info:
Looks like rotor isn't loading on subsequent requests. Here's my javascript load order after purging the cache and a refresh.

1. jquery
2. drupal
3. date_timezone
4. filefield
5. jquery.pngfix
6. thickbox
7. jcalendar
8. rotor
9. jquery.cycle.min

The second refresh shows the same order except it's missing rotor and jquery.cycle.min.

So, it's not loading, but why? Could I have broken something?

Thanks for the confirmation. Please also check my edit. Sorry about that. Thought I had time to get in the extra info before someone posted. :)

More tests. The rotor.css file isn't getting loaded either. Looking through the .module, the css, js, and jquery_plugin_add are all in the theme_rotor_block function (line 470).

Dropping a die() after the first if statement there, and clearing the Drupal cache, the page dies on the first refresh. I removed the die() to get the page to load, and then re-inserted it and refreshed the page again. Page loads broken same as before. So, something is wrong with the $items array on subsequent page loads, yes? I'm still a Drupal noob, so I don't know where that param is coming from.

Thanks for the response. Disabling Imagecache didn't change anything.

Page compression has been disabled from the start. Same for CSS optimization and JavaScript optimization. And I've had caching mode disabled for the duration of testing. It's usually on normal.

However, block cache has been enabled the whole time. Don't know how I overlooked that one to test. Anyway, I disabled it (with Imagecache enabled again and everything else still disabled) and the rotor works for anon and auth users. Re-enabling it causes the problem to re-appear for both anon and auth users.

Thanks for your work, mrfelton. I'll give it a shot later this evening.

Hi, again, mrfelton. I've tested a bit more with the dev version and still have the same problem: the rotor.js appears to not be loading for non-admin users on subsequent page loads. It looks like it works fine as long as the block cache is disabled, but enabling it (marked as recommended) breaks it again.

I've taken the liberty of changing this back to active and converting it to a bug report. I'd appreciate it if others can confirm they're seeing the same problem so I'll know I'm not entirely crazy or suffering from browser cache problems instead.

Here's what I'm looking at. Maybe someone can suggest whether I'm thinking correctly, or if I'm actually seeing what I think I'm seeing.

I cleared the Drupal cache and refreshed a page. The block shows works. I refresh again and the block breaks as described previously. Now, to test whether the block caching is indeed to blame, I modified the rotor_block_content() function in the new dev module:

function rotor_block_content() {
  $limit = variable_get('rotor_max_items', 3);
  $random = variable_get('rotor_random_items', 0)? "ORDER BY RAND()" : "";
  $items = array();
  $result = db_query("SELECT nid FROM {node} WHERE type = 'rotor_item' $random LIMIT %d", $limit);
  if ($result) {
    while ($node = db_fetch_array($result)) {
      $items[] = node_load($node);
    }
    drupal_add_css(drupal_get_path('module', 'rotor') .'/rotor.css');
    _rotor_setup_js();
    die("HERE");
    return theme('rotor_block', $items);
  }
}

The only difference is the die(). Now if this function is named intuitively and is where Drupal gets the block content (and loads the javascript, css, etc, according to above), then page loading should die on each subsequent pass after the modification above, yes? But it doesn't. It loads broken, same as before. I know the die() works, too, because if I clear the cache and hit the page again with the die still in place, the page load dies with my message.

I haven't tested it yet, but I'm betting that if I disable the block cache and play with the die(), it'll die every time it's uncommented.

Am I also correct that block cache is new with Drupal 6? That is, it's new in the sense that it's integrated now rather than an add-on?

No luck here, mrfelton. I had also tried setting the cache param under the list case this afternoon and was surprised it didn't work as advertised. I'm looking for more information on the block cache, but it's slow in coming. Think it could be a bug on that side?

For reference, here's the test site: http://arctest.eapdd.com/

The rotor is the 2007 Platinum Sponsors block. If it's not broken, I've most likely just cleared the cache. A refresh should generate a broken block.

Related material: http://pingv.com/blog/john-fiala/2008/drupal-6-blocks-need-extra-conside...

Be sure to check the comments to links.

Possibly fixed after all! One of the links through that blog posting trails back to a discussion in the block module list about this exact problem. I checked the mentioned blocks table in the db and found that the cache value for rotor under the theme I'm using was still at 1 instead of -1 for BLOCK_NO_CACHE. A manual change looks like it fixes the problem for non-admin users.

Since I didn't do it before, I'm going to completely uninstall and re-install to see if it picks up the cache param as it should. Will report back.

Don't know if I should submit a new bug for this one:

Fatal error: Call to undefined function _rotor_get_node_list() in /var/www/drupal-6.6_arctest.eapdd.com/sites/default/modules/rotor/rotor.module on line 312

Fixed that one with a function rename to rotor_get_all_items(), but now I'm unable to add rotor-item nodes past the first one, and can't edit that one. Screen blanks like a php error, but I get nothing in logs. The rest of the site works fine.

EDIT: Had to go to the generic Apache error log. Found this when attempting to visit node/add/rotor-item:
[Sun Dec 07 21:46:56 2008] [notice] child pid 11149 exit signal Segmentation fault (11)

I'll poke around a bit more, but may roll back to the stable version and add in the BLOCK_NO_CACHE there for testing.

It looks like adding the no cache line ('cache' => BLOCK_NO_CACHE,) to line 91 of stable version 1.4 works. Authenticated users now get the javascript to load each time so the rotor functions as expected. It also works for anon users, though the randomization appears absent. I'm betting that's page caching coming into play for them, though, since I just turned it back on.

I'm going to run with the modified stable version for this test site, but may set up a clone to tinker with the dev version and work on finding those bugs.

Apologies for the delay. Finishing up some other work.

I just cloned into a test site and downloaded the latest dev snapshot. Looks like it works now. Caching issue appears to be fixed, as well as a couple of other hard errors with the dev version that prevented me from working with it a couple of days ago.

There are a few problems specific to some of the transition effects in the new version, but I'll submit a separate bug report for those. Many thanks for your help!