Add/Delete Tab not doing anything in Quicktabs admin [#2112787]

It seems like I am currently experiencing the same or a very similar issue as this one in quicktabs 3.6 somehow. I thought I should mention it here to let people know. Although, this may be a freak incident. I don't know yet because I don't know what happened. It could also be caused by something different from that issue. I don't know why updating to 3.6 would create the same issue for me that 3.6 was suppose to fix.

Config: Drupal 7.22, quicktabs 3.4/3.6 and lots of other modules.

First, with quicktabs 3.4, I recently began having a problem with a specific qt instance that has a lot of tabs. It suddenly started acting strange when it reached a certain number of tabs. When I try to select a view, by selecting a view in the "Select a view" dropdown, the ajax runs but after that when I go to select a block from the view in the "display" dropdown, it still has the blocks/options from the one that was previously selected by default in the "Select a view" dropdown (see attachment). So I have no way to select the blocks from the view that I want to use. This stopped me from adding more tabs, but if I delete the last tab that was previously created, I can add a tab again the way I want with the correct view/block. But it stops again. It's almost like I reached the limit of tabs I can add. The other thing I noticed was that up in the admin breacrumbs for this "broken" instance of quicktabs, it was different than usual. Normally the quicktabs breadcrumbs looks like this: "Home » Administration » Structure » Quicktabs" but in this qt instance it looks like this: "Home » Dymanic Content » Delete Content » Agent & Staff Resources" (see attachments) but only "Home" was a link while the others are just black text.

Then I thought I should update the quicktabs module to see if that fixes anything so I updated 3.4 to 3.6 on dev versions of the site in three locations: 1) locally on a linux machine, 2) locally on a dev server, 3) dev location on a dedicated server. The results were a little confusing. Locally on my machine and on the dedicated server it started to behave exactly as stated in this issue. When I click the add (or delete) button, nothing happens. The ajax just pops up for about one second and then disappears without anything happening or changing. I can't add or delete a tab. Also, when I hit save, it reloads the same page.

But the stranger thing is that out of the three dev versions, on the local dev server (very fast machine), I can add and delete tabs again, and it even seems to save the tabs correctly. Out of three identical dev versions of the site, only one of them started working as far as adding/deleting tabs. The only lingering problem is that the breadcrumbs is still strange looking on the dev version that started "working" again. Maybe that means the problem is still there even if it's not so apparent. I also put the site into a different linux machine and it did the same thing as the local server. I can add/delete and save but the breadcrumbs is looking strange. I have no idea why I am getting the different results.

A little more info. All the other qt instances (with much less tabs) are working normally with quicktabs 3.4 and 3.6 on all machines. Somehow, this particular quicktabs instance seems to have gotten corrupt, or too big?

I'm in the middle of doing more testing to see what I can find out but I just wanted to bring it up here in case anyone else has experienced anything strange like this. I'm testing stuff with the current broken qt instances and I also set up a much earlier version of the site that was working normally so I can try updating and adding to the same earlier qt instance.

The bottom line is I would like to prevent having to recreate the whole quicktabs instance again and it seems the only way I can get close to doing that is if I can get the older version updated and imported (without breaking) into the current site.

Thanks for reading, and I'll give an update if I find out anything.

File	Size	Author
admin1_bc1.jpg	5.83 KB	zerorez
admin1_bc2.jpg	5.93 KB	zerorez
qt1_clip1.jpg	22.74 KB	zerorez

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

zerorez CreditAttribution: zerorez commented 16 October 2013 at 20:23

I forgot to link some text. In the 4th paragraph when I said "as stated in this issue" I meant to link "this issue" to this: https://drupal.org/node/1940170

Comment #2

zerorez CreditAttribution: zerorez commented 17 October 2013 at 00:08

I think I'm hitting a memory limit somewhere on the machines that stopped adding/deleting tabs. I set up a version of the site with QT 3.4 and applied the import patch. Then I exported and imported the massive qt instance (with 99 tabs) into a few different machines. The machines all have server configs that are within the recommendations as far as I can tell.

On one machine the qt instance acted like normal after import and I could keep adding tabs or delete tabs and then save it and it saves like it should. No problems at all even after 99 tabs.

On another machine the same qt instance looked normal at first after import but I couldn't add/delete any tabs. The ajax starts but stops without a new tab appearing or disappearing. And when I hit save it just reloads the page with nothing saved which also means I can't change the current tabs.

So it must be because the qt instance is too big for the server config on the machine where it doesn't work. The php.ini settings appear to be the same on both machines so there must be something else that is affecting the ajax.

Anyone have any ideas?

Comment #3

zerorez CreditAttribution: zerorez commented 19 October 2013 at 20:01

It all turned out to be rather simple, even though it took a little while to pin point. In one of my searches on Ajax I found someone having a similar problem. It was a php setting (max_input_vars) that normally exists somewhere in the php.ini and it was stopping quicktabs from adding/deleting tabs. I wasn't familiar with that one and I couldn't find it activated inside any php.ini file that was being used. The default on some servers must be 1000 or something if you don't have it turned on in the php.ini. I don't know for sure. I didn't want to put the setting in the php.ini for the whole server so I set it inside the sites htaccess:

Usually starting around line 26 in .htaccess:

# PHP 5, Apache 1 and 2.
<IfModule mod_php5.c>
  ...
  ...
  php_value max_input_vars 2000
</IfModule>

So, if you're having this kind of problem even with the latest quicktabs or anything else, then it is probably the max_value_input.

Next, I found out why the admin breadcrumbs was changed when editing the quicktabs instance. Someone working on the same website had setup the webmaster_menu module for a specific role and when they created links to edit content they created a custom menu using different URLs from Drupal's admin menu or admin_menu module. As soon as the quicktabs instance was loaded in the browser for the first time using the different URL in the custom webmaster_menu, it changed the URL within quicktabs. Then when I went to the same quicktabs instance logged in as admin using the admin_menu, the breadcrumbs for that quicktabs instance page was changed to the same one that the webmaster_menu was using. I don't have time to research what is causing it but maybe someone else knows. The webmaster_menu must be replacing the default URL when you set it to something different from the quicktabs default.