Upgrade to newer version broke existing accordion

Thanks for your fast reply. I had tried what you suggested. I went back and did it one more time. I removed the module from Drupal, physically deleted the folder, removed all setting from the view, got the view working with other settings, then changed the view one more time for good measure, then downloaded the latest version of the module, then activated it, changed the view to views accordion. I still got the same issue, namely all the elements displayed in full and a visible "Stop" Link.

I think it is related to the theme in some way, and I kinda proved it. Acting on my guess I changed my default theme to garland and sure enough, the accordion now works as expected. We do have a customized version of Tendu and I do have to wonder if our Themer changed something that might affect VA.

I should add that I'm using the Admin module which uses the slate theme for admin, which seems to be active in some fashion, even when you are editing pages in your main theme. The Admin module is a port back from Drupal 7, so it's a good way to make Drupal 6 sites feel more like Drupal 7 sites, and is also a sign of things to come. I was not sure if it was the combination that was the issue, so I turned it off, but the problem remained. So yes, the signs are that it is our theme, in some way, messing with the way jQuery works... or maybe is changing the way views displays output, which affects VA.

Do you have any suggestions on what we might look for? HTML/CSS that might mess with the way VA works? I think it may be useful, so I'm including some HTML code. I wish there was some way to abbreviate it, but I seem to be stuck with the html code tag in this forum. Here's what the HTML looks like for the broken code:

<div id="block-views-test_accordion-block_1" class="block block-views block-first block-last block-odd">
	<div class="content">
			<span class="stop-accordion"><a class="stop-accordion" href="#">Stop</a></span>
			<div class="view-content">
				<div class="item-list views-accordion views-accordion-test_accordion-block_1">
					<div id="views-accordion-test_accordion-block_1">
						<div class="views-accordion-item accordion-item-0 accordion-item-odd accordion-item-first">
							<div class="views-field-title">
								<span class="field-content">Test Blog Entry</span>
							</div>
							<div class="views-field-body">
								<span class="field-content">LEFT Suspendisse congue enim non ligula euismod eu consequat orci iaculis!...</span>
							</div>
						</div>
						<div class="views-accordion-item accordion-item-1 accordion-item-even">
							<div class="views-field-title">
								<span class="field-content">Test Blog Entry 2</span>
							</div>
							<div class="views-field-body">
								<span class="field-content">Morbi nec mattis quam. Nulla vel ligula ac libero elementum egestas. Vestibulum...</span>
							</div>
						</div>
						<div class="views-accordion-item accordion-item-2 accordion-item-odd">
							<div class="views-field-title">
								<span class="field-content">Test Blog Entry 3</span>
							</div>
							<div class="views-field-body">
								<span class="field-content">Sed fringilla suscipit convallis. Curabitur semper sem vitae quam scelerisque...</span>
							</div>
						</div>
						<div class="views-accordion-item accordion-item-3 accordion-item-even">
							<div class="views-field-title">
								<span class="field-content">Test Blog Entry 4</span>
							</div>
							<div class="views-field-body">
								<span class="field-content">Suspendisse vitae nisi ac mi volutpat semper volutpat eu metus. Proin convallis...</span>
							</div>
						</div>
						<div class="views-accordion-item accordion-item-4 accordion-item-odd">
							<div class="views-field-title">
								<span class="field-content">Test Blog Entry 5</span>
							</div>
							<div class="views-field-body">
								<span class="field-content">Etiam gravida sapien a eros blandit in faucibus turpis luctus. Nulla facilisi....</span>
							</div>
						</div>
					</div>
				</div>
			</div>
		</div>
	</div>
</div>

We tried removing all of the themer's tpl files, but the problem remained. Very baffling. Something really odd is going on here.

However, today I found a clue. I looked at our test site hosted on another server... and VA is working there with the exact same code & database. Very baffling. Identical code, identical databases, and yet one works and the other does not. I've flushed caches more times than I can count and tried multiple things. Since jQuery works browser-side and I'm running my local dev and the remote test site in two tabs in the same Firefox session, it suggests that this is actually indirectly a PHP error of some kind.

My first thought was that my php settings might be different, and certainly it appears to be the case because there is one possible clue. In the test site, the site where VA is working, when editing the VA view I see the following error message:
warning: array_merge_recursive() [function.array-merge-recursive]: recursion detected in xxx/includes/common.inc on line 2216.
However, if I change to view to a different display style, then re-edit the view, then the error is gone. Add VA back, save and re-edit... and the error is back. So the possibility exists that there is some error that is getting blocked on my test site, which in turn allows VA to function properly, but on my test box, where setting are less stringent and I get no error, VA breaks.

I hope I was clear there. In summary, in one environment I get the above error message, but VA works, while in another environment I get no error and VA does not work.

Another side note is that the test site is Linux and my local machine is a Mac, but I'm not sure if/how that affects things either.

The code in /includes/common.inc is as follows (line 2204 to the error line, 2216):

  // For inline Javascript to validate as XHTML, all Javascript containing
  // XHTML needs to be wrapped in CDATA. To make that backwards compatible
  // with HTML 4, we need to comment out the CDATA-tag.
  $embed_prefix = "\n<!--//--><![CDATA[//><!--\n";
  $embed_suffix = "\n//--><!]]>\n";

  foreach ($javascript as $type => $data) {

    if (!$data) continue;

    switch ($type) {
      case 'setting':
        $output .= '<script type="text/javascript">' . $embed_prefix . 'jQuery.extend(Drupal.settings, ' . drupal_to_js(call_user_func_array('array_merge_recursive', $data)) . ");" . $embed_suffix . "</script>\n";

I hope this is some help. Hopefully all this means more to you than it currently does to me.

I'll see what I can find. All I know is that all the rest of the site's jQuery works fine, even the jQuery on the same page. Thanks for your timely replies. This has been a time-killer. I'll come back to it later and assess needs again.

Having shelved this for quite some time, I am planning to come back to it. I thought I'd add the following interesting tidbits:

1. If I embed Views Accordion view X into a standard block in the main content area, then it does not work.
2. If I embed Views Accordion view X into Panels pane, then it does work.
3. (Edit to add:) If I embed a second Views Accordion view Y into Panels pane that already has view X, then it does not work (probably an unrelated issue).
4. If I embed Views Accordion view X into an element created by another jQuery module, in this case a QuickTabs tab structure, then it does work.

Could this be some obscure unclosed tag, unclosed something, condition? Could Panels and QuickTabs be fixing the issue?

More information for you. I think this entire problem might be related to the PHP version. The test site where VA mostly works is on PHP 5.2.4. However, when we moved the site to our live site with PHP 5.2.10 then any stand-alone VA broke. Only those VA blocks embedded in panels or quicktabs. Taking note of my development box where it does not work, I see that I'm on PHP 5.2.9.

To summarize: works with php 5.2.4, broken with 5.2.9 and 5.2.10.

I'd like to have tested this and proved the point conclusively, but my sysadmin pointed out that we want to keep upgrading PHP versions in case of security issues and he does not want to backtrack to PHP 5.2.4 and then be stuck on it. So there you have it. My guess is that something fails in a later version that was fine in an earlier version, and that this is the root of the problem.

For now I'm going to wrap all my VA blocks in a panel, which resolves the bug. I hope this helps.

Another theory bites the dust.

It's so odd. I thought I had a workaround, by adding accordions to panels... which works fine... unless you are using a VA group. Groups in VA disappear if they are in a Panel.

Do you have any suggestions for me? A suggested hack, a workaround, something to look for... anything? What can I do to track this thing down? What could be different about one older Linux server I'm using, where VA works, compared to my Macbook or a brand new Linux server? Something is going on on the server end. I'm out of ideas.

So... we came up with a fix... well, it would be more honest to call it a horrible, nasty, vicious little hack. First, some context. We still don't know where the actual issue is, but here's the thing, the method render() (in views_accordion_style_plugin.inc) gets called twice for the same view. It appears that this is because the view itself is called twice. As a result, render() calls drupal_add_js() twice for the same view, and this is what breaks the accordion, resulting in what was mentioned in 13. If drupal_add_js() only gets called once, then all is well. So, knowing this, but not really getting why the method is being called twice, we were unable to treat the source of the problem or to tackle the problem in the "ideal" way... let alone best practices. So we put in a small hack that ensures that drupal_add_js() is called once.

Here's the diff code for the changes we made to views_accordion_style_plugin.inc:

    * Render the display in this style.
    */
   function render() {
+	global $renderDuplicate; // CHANGE
+
     $output = parent::render();
 
     // dpm($this->display->handler->get_option('fields')); // for dev-troubleshooting
@@ -160,7 +162,14 @@
         }
       }
     }
-    drupal_add_js(array('views_accordion' => array($view_id => $view_settings)), 'setting');
+    // CHANGE BELOW
+	if ($renderDuplicate) { // Is this the first time render has run for the view?
+		unset($renderDuplicate);
+	} else {
+		$renderDuplicate = true;
+		drupal_add_js(array('views_accordion' => array($view_id => $view_settings)), 'setting');
+	}
+    // CHANGE ENDS    
 
     return $output;
   }

As you can see, it's horrible, basically just asking if this is the second time through and then skipping it. A better way would be some way of asking if this is the second time through for the same view. Hell, I'm sure almost every other way of doing this would be better. In our case this does not matter as we never have two accordions on the same page anyway. It's a bandaid on an axe wound... but hopefully this workaround is of some use to helping you to resolve this.

Well the module does not appear to be checking to see if it has already done it's thing because that seems to be the problem. If you look at #13 the JS is wrong. It fails if the same view is called twice. Views handles this fine and the view does not appear twice. VA does not handle this and duplicates the JS entry. We're looking in to this and I'll let you know what we find, but this could happen to someone else.

We do not want to change the module code. How else could we identify the problem? We only changed it to demonstrate the issue to you and to try and be helpful. We had no idea you were being annoyed by the information.

Our patch was a horrible hack based on a tight timeline. However, as I recall, it would only work if there was a single views accordion on the page, which was all we needed. Your needs may differ. I think we had one exception to this and we were able to use views groups to make it work. It has been two years, so memory is a bit fuzzy.