Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.I updated my Quicktabs module and then received the following error:
user warning: Unknown column 'hide_empty_tabs' in 'field list' query: SELECT qtid, title, tabs, ajax, hide_empty_tabs, default_tab, style FROM quicktabs WHERE qtid = 3 in /home/shannonm/public_html/modules/quicktabs/quicktabs.module on line 447.
I have many Quicktabs on my site, and they are all now broken. Any suggestion with what I should do next? Help please!
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | 1-21-2010 9-42-16 AM.png | 16.5 KB | ShannonK |
| #6 | parsedjava_err1-20-2010.png | 58.48 KB | ShannonK |
Comments
Comment #1
pasquallerun update.php
Comment #2
ShannonK commentedI did. I get the following:
An HTTP error 0 occurred. http://mysite.org/update.php?id=108&op=do
Then on the error page,
The update process was aborted prematurely while running update #6205 in quicktabs.module. All errors have been logged. You may need to check the watchdog database table manually.
Then on the log:
TYPE: php
Date: Tuesday, January 19, 2010 - 6:53pm (this is the first, there's a bunch of these same errors)
User: Guest
Location: http://mysite.org/index.php?q=BOCC
MESSAGE:
Unknown column 'hide_empty_tabs' in 'field list' query: SELECT qtid, title, tabs, ajax, hide_empty_tabs, default_tab, style FROM quicktabs WHERE qtid = 5 in /home/shannonm/public_html/modules/quicktabs/quicktabs.module on line 447.
severity: error
HOSTNAME:
OPERATIONS:
Does this tell you anything?
Comment #3
ShannonK commentedAlso....
Interestingly, when I go to admin/reports/updates it shows Quick Tabs as Up to date (Quick Tabs 6.x-2.0-rc4).
However, running update.php, I clicked "select versions" out of curiousity, and it shows quicktabs module with the number 6205, and the Weather module with a number, 6504, listed under it.
So why does the update page think it has updated successfully then?
Comment #4
ShannonK commentedI'm starting to panic here.....I have a LOT of quicktabs on my site, and now that they're all broken, a LOT of content is unviewable. Is it lost? Is there a way for me to restore a backup if nothing else to retrieve my content. I don't know what I should do here.
My logs have a ton of php errors listed. The Location is always a Quicktab. The message is as follows:
Unknown column 'hide_empty_tabs' in 'field list' query: SELECT qtid, title, tabs, ajax, hide_empty_tabs, default_tab, style FROM quicktabs WHERE qtid = 11 in /home/shannonm/public_html/modules/quicktabs/quicktabs.module on line 447.
Does this mean anything to anyone? Please - any help at all would be greatly appreciated!
Comment #5
pasqualleyou need to run update.php successfully.. All the php errors you see are because update.php was not run.
check your quicktabs table in the database:
the 6205 update adds a new column 'hide_empty_tabs'
the 6206 update adds a new column 'default_tabs'
(if you are using PostgreSQL then the update 6206 may fail..#689942: Update 6206 fails)
so I do not know why update 6205 fails on your system, the log in comment #2 is not related to the update.
as a quick solution just use -rc3, all your content should be in the database and working correctly with -rc3
then create a test system and find the error message generated at update in the Drupal log or apache log..
you may try running update.php again..
Comment #6
ShannonK commentedOK - reinstalled -rc3 and Tabs are back...THANK YOU!
Won't I get the same error message if I run a test site? How do I check the apache log?
I reran update.php and received the following mss:
An unrecoverable error has occurred. You can find the error message below. It is advised to copy it to the clipboard for reference.
Please continue to the error page
An HTTP error 0 occurred. http://mysite.org/update.php?id=115&op=do
The error page:
The update process was aborted prematurely while running update #6000 in quicktabs.module. All errors have been logged. You may need to check the watchdog database table manually.
The logged page has a bunch of "Parsed JavaScript file" messages:
(see attached).
I was under the assumption the Parsed JavaScript file message didn't mean anything, because of this thread:
http://drupal.org/node/409676
So, basically, update.php won't run successfully and the logs aren't telling me anything. I'm not sure what I should do now?!
Comment #7
pasquallewhy are you running update #6000?
between -rc3 and -rc4 there is only update #6205 and #6206
Comment #8
ShannonK commentedI don't know how that number is generated. I just run update.php and click update. I don't muck with the versions, because I've always let it do it itself. -rc3 isn't listed as an available download, so I just used a backup copy I had made from my site in Nov. 09.
Comment #9
pasquallehttp://drupal.org/node/415138
the number is updated every time when you run update.php or install a new module. The number is the largest (N) number in the quicktabs.install file from quicktabs_update_N() functions.. The number is stored in the {system} table in schema_version column.
so in November 2009 you should have the number 6004 for the quicktabs module..
Comment #10
ShannonK commentedThank you for the link...I used it to update Quicktabs to -rc3. If I go to /admin/reports/updates it shows the Quicktabs version as being 6.x-2.0-rc3 and that there's an update available (as we know). However, I get the same error message on the error page as above, stating
"The update process was aborted prematurely while running update #6000 in quicktabs.module. All errors have been logged. You may need to check the watchdog database table manually."
Why do you suppose it's stuck on 6000?? I don't get this at all.
Comment #11
pasqualleThe number 6000 comes from the database. Which means you have started using the quicktabs module at release 6.x-1.0-beta1 (or 5.x-1.x) and you never did not run update.php since. If that is true then your {quicktabs} table must be broken, like you are missing the 'ajax' and 'style' columns. But if it would be broken, then you would see many error messages using the -rc3 release. So I do not know how did you make your database updates required to run the -rc3 release..
My guess on the "aborted prematurely" message at running update.php without seeing an actual error is that you might have a server miss-configuration like a too short php execution time limit (or your database user does not have grants to alter the db, but then you should see a special error). So I do not know, as there is nothing useful in your report. So I need to know your habits about running update.php (did you run it successfully in the past?), your state of the database (the quicktabs table) or any other useful information.
If you have a test system, and you do not have more than 10 quicktabs, then you should simply uninstall the module (admin/build/modules/uninstall), then start with -rc4 and create the quicktabs again.
Comment #12
ShannonK commentedI've run update.php about once a week, or whenever there was an update. I'm logged into my site six days a week, and when I see a red "status report" box after clicking Administer, I always click it (admin/reports/status), run cron manually, then click on "Module and Them Update Status" if it's out of date (admin/reports/updates). Then I scroll down and see what needs to be updated, click the download, make a backup of the website, install/extract the update, run php. That's my habit. I've never had a problem until recently.
The Quick Tabs listed on admin/reports/updates is indeed 6.x-2.0-rc3, and it's recommending I update to 6.x-2.0-rc4 (which we know I shouldn't do).
The most recent changes I've made to the site are adding the module Custom Pagers, updating the Weather module, and updating Quicktabs. The other significant change was changing the site to be secure in its entirety, i.e., from http to https. I wonder if that "s" could cause a problem with php somewhere because it's redirecting all pages to https?
I just ran update.php again and am receiving the same "The update process was aborted prematurely while running update #6000 in quicktabs.module." Which is weird since -rc3 must be running successfully or the Quicktabs would be broken (as they were when this whole mess started).
Checking the logs this morning (admin/reports/dblog) I found an odd entry for 1:30AM this morning when I was nowhere near my computer (see attached). Do you think this mean someone's trying to hack me? (probably a separate issue, but because things are not making sense, it might be significant??).
Comment #13
pasqualleok. so the question is: did you run update.php (with actual updates) successfully in the past with the new server settings (with https)?
Comment #14
ShannonK commentedI think so. But it's the "actual" updates that's making me hesitate, because I may have just run update.php with no updates. Are you going to suggest I revert the site back to http and try running update.php again?
Comment #15
pasqualletry to disable and module, and run update.php. As I know you have other pending updates also.. So if you can reproduce the error with other updates, then your https configuration might be the problem..
Comment #16
ShannonK commentedactually I got rid of Secure Pages after trying to disable it and running into odd behaviour (kept getting "Page Not Found")...so anyway, I deleted it. The site is secure without the benefit of the Secure Pages module because I had contacted my host and paid for a dedicated host and an SSL setup. They gave me this code to put in my .htaccess:
# Always use https for secure connections
# Replace 'www.example.com' with your domain name
# (as it appears on your SSL certificate)
RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]
Now the site is secure in its entirety, and this may have nothing at all to do with what we're talking about, but I'm just wondering if that redirect causes problems. So, I'm assuming if I remove the above added code the site will go back to being "unsecure" (i.e., http), and then I can try running update.php again. What do you think?
Would throwing my computer out the window while cursing perhaps solve the problem?
Comment #17
Trinorae commentedRunning update.php fixed the problem with my site. Thanks for the tip Pasqualle!
Comment #18
nancydruI am still getting "Unknown column 'hide_empty_tabs' in 'field list' query: SELECT machine_name, title, tabs, ajax, hide_empty_tabs, default_tab, style FROM quicktabs ORDER BY title in /mnt/stor1-wc1-dfw1/378969/379186/www.thepoliticus.com/web/content/sites/all/modules/quicktabs/quicktabs.m... on line 523." Yes, I have run update.php and cron and cleared caches (many, many times).
Comment #19
katbailey commented@NancyDru, it sounds like you must have skipped an update function somehow - maybe you went from 2.x to 3.x without having updated to the latest 2.x version first?
Comment #20
nancydruThat's possible. However, the API descriptions of hook_update_N() say that all updates within a major version (6.x) should remain within the .install file, so they should all be there to be executed. I assure you that I have run update.php many, many times.
Comment #21
nancydruHmm, looking at the project page, this just jumped out at me:
The 3.x branch of Quicktabs introduces ctools-based exportability of Quicktabs instances.We do not have cTools installed and it is not listed as a dependency.Comment #22
nancydruSee #1282470: Updates missing from the .install file.
Comment #23
jelo commentedThis problem is still persistent. I just upgraded from 6.x-2.0-rc3 to 6.x-3.0. That did not work at all. I had to go back and do the update to 6.x-2.0 first. Even that did not look right. When I executed the update.php script, it showed Quicktabs to update to 6205, but in the dropdown 6206 was available for selection as well. It seemed that it updated correctly to 6206 though. Only after that I could upgrade to 3 without problems. The change to machine names require re-configuring the block settings and adjusting the theme files because the class names changed. You might want to rename your tabs before the update because your human readable name gets converted to the machine name (and you cannot change it afterwards). For me it resulted in very long machine names and hence CSS classes.
Comment #24
venusrising commentedWe have tried updating several times with fails each time. Here is the recent fail
What can we do to fix this as we need to be running the stable release and previous version worked fine
user warning: Unknown column 'qtid' in 'field list' query: SELECT qtid, title FROM quicktabs in /home/MYSITE/html/sites/all/modules/quicktabs/quicktabs.module on line 139.
user warning: Unknown column 'qtid' in 'field list' query: SELECT qtid, title FROM quicktabs in /home/MYSITE/html/sites/all/modules/quicktabs/quicktabs.module on line 139.
user warning: Unknown column 'qtid' in 'field list' query: SELECT qtid, title FROM quicktabs in /home/MYSITE/html/sites/all/modules/quicktabs/quicktabs.module on line 139.
In Logs We Get
http://www.MYSITE/admin/build/quicktabs/add
Referrer http://www.MYSITE.com/admin/build/quicktabs/list
Message Unknown column 'qtid' in 'field list' query: SELECT qtid, title FROM quicktabs in /home/MYSITE/html/sites/all/modules/quicktabs/quicktabs.module on line 139.
Comment #25
japo32 commentedHi Guys, I was having the same problem so I kept googling. Pasqualle posted the solution which worked for me in another thread.
Here's what I did:
basically disable and uninstall QT.
Then I downloaded a fresh copy of the latest for Drupal 6.x and did the fix for the quicktabs.view.inc bug:
and then I installed the fixed copy of QT and enabled it:
It now works. :)
Hope this helps anyone who has the same problem. Cheers!
Comment #26
stella commentedI get the same error. The problem happens when you update from an old quicktabs 2.x version to the latest 3.x version without first upgrading to the quicktabs 2.1. This is because update hooks for 2.x are not included in the install file for the 3.x version. This is generally not recommended practise within the same major version of Drupal, i.e. it's okay to remove 6xxx update hooks for the 7.x branch but not when you change your module from 6.x-2.x to a 6.x-3.x version numbering.
A two-stage upgrade is also not realistic for production sites - you just want to be able to deploy from git once, run update.php and be done. My solution was to download the 2.1 version and copy and paste in the missing update hooks to the 3.x install file. Then I was able to upgrade and deploy the module in one step.
Comment #27
netw3rker commentedThis is resolved now that #1282470: Updates missing from the .install file is closed out.