Upgrading a very small site from 6.2 to 7.0, just looking for advice. When attempting to run update it starts and then dies here:
An AJAX HTTP error occurred. HTTP Result Code: 500 Debugging information follows. Path: http://www.fourtiresandfuel.com/update.php?id=18&op=do StatusText: Service unavailable (with message) ResponseText: Recoverable fatal error: Argument 2 passed to SelectQuery::fields() must be an array, null given, called in /home/hoslot5/public_html/includes/entity.inc on line 284 and defined in SelectQuery->fields() (line 1262 of /home/hoslot5/public_html/includes/database/select.inc).
Error page:
Notice: is_dir() [function.is-dir]: Unable to find the wrapper "public" - did you forget to enable it when you configured PHP? in file_scan_directory() (line 1975 of /home/hoslot5/public_html/includes/file.inc).
Notice: is_dir() [function.is-dir]: Unable to find the wrapper "public" - did you forget to enable it when you configured PHP? in file_scan_directory() (line 1975 of /home/hoslot5/public_html/includes/file.inc).
Notice: is_dir() [function.is-dir]: Unable to find the wrapper "public" - did you forget to enable it when you configured PHP? in file_scan_directory() (line 1975 of /home/hoslot5/public_html/includes/file.inc).
Notice: is_dir() [function.is-dir]: Unable to find the wrapper "public" - did you forget to enable it when you configured PHP? in file_scan_directory() (line 1975 of /home/hoslot5/public_html/includes/file.inc).
The update process was aborted prematurely while running update #7012 in user.module. All errors have been logged.
If this is posted somewhere and I missed it I apologize, I need sleep :)
Comment | File | Size | Author |
---|---|---|---|
#91 | drupal.field_bundle.patch | 919 bytes | marysmech |
#63 | drupal-component-1158114-63.patch | 608 bytes | helmo |
#51 | drupal-1158114-51.patch | 541 bytes | tim.plunkett |
#7 | drupal.taxonomy_might_not_exist.patch | 608 bytes | rfay |
Comments
Comment #1
plachThis seems a duplicate of #1245980: Outdated static schema cache while upgrading from a plain D6 install to D7 on Windows.
Comment #2
Starminder CreditAttribution: Starminder commentedI don't see how this is even close to being a duplicate of that. This did not occur in a windows environment, and was related to update #7012 aborting.
This same site is still dead in the water this many months later. Using 7.7 core, the now 135 pending updates still aborts, the error message is now:
An AJAX HTTP error occurred. HTTP Result Code: 500 Debugging information follows. Path: (siteURL)/update.php?id=19&op=do StatusText: Service unavailable (with message) ResponseText: Recoverable fatal error: Argument 2 passed to SelectQuery::fields() must be an array, null given, called in /home/hoslot5/public_html/includes/entity.inc on line 284 and defined in SelectQuery->fields() (line 1261 of /home/hoslot5/public_html/includes/database/select.inc).
Comment #3
plachYou're right, sorry, I misread the OP. FWIW #1234834: 'module' column of role_permission table is not populated on upgrades fixes the issue I crossposted in #1.
Comment #4
Starminder CreditAttribution: Starminder commentedAren't 7006 and 7012 different? I'd like to leave this open until the fix in #1234834 is committed and i can check it if that's ok. Thanks, glad to see this getting some attention, this site has been dead since upgrading.
Comment #5
rfayI just got this on an update from D5 through D6 to D7. It's a tremendously simple businesscard-type site. Seemed find when it got to D6.
CCK was not installed in either the D5 or D6 instances.
The reported error is
Comment #6
rfayMarked #1231836: Update fails: Argument 2 passed to SelectQuery::fields() must be an array as a duplicate
Comment #7
rfayCall is from user_update_7006():
It's caused by taxonomy_vocabulary_load_multiple().
I note that taxonomy was not enabled on the site being upgraded.
So what happened was that DrupalDefaultEntityController::buildQuery() does this:
but base_table is NULL (because taxonomy was not enabled, I assume)
then we hit
which causes the fatal.
The attached patch lets the upgrade run to completion
Comment #8
rfaySame patch applies fine to D8. I guess we'll have to get it in there first.
Comment #9
rfayTagging upgrade path
Comment #10
plach@rfay: did you try the patch cited in #3? it fixes exactly user_update_7006()...
Comment #11
rfay@plach -- no I didn't try it. You pointed to it as being a mistaken attribution, to an issue that had nothing to do with this. And I don't see where #1234834-15: 'module' column of role_permission table is not populated on upgrades addresses the problem in this patch.
Comment #12
plachI was asking because the issue I originally marked as duplicate of this one appears to be in a possibly similar situation: it has been marked duplicate of #1234834: 'module' column of role_permission table is not populated on upgrades even though it concerns a different issue, at least for what I can understand of it.
I am just curious to know if the patch over there removes the symptom also here.
Comment #13
catchPlease try #1234834: 'module' column of role_permission table is not populated on upgrades, user_permission_get_modules(); should not be run anywhere during the upgrade path under any circumstances, nor should any other function invoking hooks. So if that's triggering the bug here then removing it from user_update_7006() is the right fix for this issue as well.
Comment #14
rfayI don't disagree, @catch, but think that #7 solves a (very simple) real core problem here, and should not be dismissed. These are not mutually exclusive fixes.
Setting back to CNR not to be confrontational, but because I think it should be fixed.
Comment #15
catchIf taxonomy_vocabulary_load_multiple() is being called when taxonomy module isn't even enabled, that's not fixed by having entity_get_info() work around it, we should instead figure out why taxonomy_vocabulary_load_multiple is getting called at all.
If taxonomy module isn't upgraded when this function is called, then that's the reason for removing the call from user_update_7006().
Is there a different bug here that this fixes?
Comment #16
rfay@catch, #1234834-16: 'module' column of role_permission table is not populated on upgrades also allows the update to continue to completion successfully and resolves the OP here. Either approach would have fixed it. Both should be implemented, IMO.
Comment #17
catchWhy should entity_get_info() have special workaround code for missing base tables for a condition that can only exist during update though?
Comment #18
rfay@catch, yes, the bug is that the existing code assumes an array in $this->entityInfo['schema_fields_sql']['base table'] and that's an invalid assumption.
Comment #19
catchIt's only an invalid assumption during upgrade though, because hooks cannot be reliably executed, which is why we have #1134088: Properly document update-api functions and a broken upgrade path for two years. module_implements() should ideally throw an exception during update so it is impossible to even reach this code. Are there any other circumstances under which you believe this could be triggered?
Comment #20
rfayI really don't know this stuff anything like you do, so if you think it's impossible, we'll call this a dup.
Marking a dup of #1234834: 'module' column of role_permission table is not populated on upgrades
Comment #21
Starminder CreditAttribution: Starminder commentedFor what it is worth, I ran update on this site - there are 135 pending updates. It fails here:
An AJAX HTTP error occurred. HTTP Result Code: 500 Debugging information follows. Path: http://www.fourtiresandfuel.com/update.php?id=20&op=do StatusText: Internal Server Error ResponseText: Recoverable fatal error: Argument 2 passed to SelectQuery::fields() must be an array, null given, called in /home/hoslot5/public_html/includes/entity.inc on line 284 and defined in SelectQuery->fields() (line 1261 of /home/hoslot5/public_html/includes/database/select.inc).
Comment #22
catch@rfay it should be impossible, if there's another way to get to it, something else very bad is happening (which is not at all impossible given the sort of bugs in D7 at the moment).
@Starminder if you're getting that running updates it's likely the same thing. If you can dump a debug_backtrace() in there to see what comes through that'd help to confirm though.
Moving back to duplicate for now.
Comment #23
rfayUmm... @Starminder you didn't mention what patch you applied, if any...
Comment #24
xjmFixing crosspost.
Comment #25
Starminder CreditAttribution: Starminder commentedsigh. I know we want to close this stuff, but I don't think you should be closing it until someone the community tests it, or at least cite what this is a duplicate of, which I think the answer is that it isn't.
Comment #26
xjm#25: It was marked as a duplicate of #1234834: 'module' column of role_permission table is not populated on upgrades in #20. rfay and catch both have set it to this status. See catch's post in #22. If you can provide information as he suggests that indicates it is not a duplicate, then post that.
Comment #27
chx CreditAttribution: chx commentedahem
Comment #28
asciikewl CreditAttribution: asciikewl commentedSorry to open this again, but I'm running into this with a migration on D7.8 where the changes from http://drupal.org/node/1234834 has already been applied.
During development and migration I applied the patch in http://drupal.org/node/1158114#comment-4863562 to the dev tree and the error went away.
Now we are moving the dev database to a staging site where the paths etc are different. Placing the working D7 database in the new position, we then need to rebuild the paths to fit the new location.
Step 1: rebuilding registry works fine
Step 2: Rebuilding module,theme and css data fails when we do:
drush php-eval "system_rebuild_module_data();system_rebuild_theme_data();drupal_clear_css_cache();"
Clearing the caches also fails with the same error.
If I then apply the patch above, everything works fine. When I revert the patch, everything keeps working fine, so it could be a tricky one to re-create.
Comment #29
rfayIf you used Registry Rebuild to build the cache, it does a full cache clear... So I'm surprised you even see the need to do step 2 in #28.
Comment #30
DamienMcKennaRunning into this with D7.8 with a custom installation profile that contains a large number of contrib modules, a few custom modules and several features.
Comment #31
migrad CreditAttribution: migrad commented#7: drupal.taxonomy_might_not_exist.patch queued for re-testing.
Comment #32
mgiffordThis patch hadn't gotten into 7.10 and this is still an outstanding issue. I applied this issue to core and all works properly now.
Comment #33
xjmHmm, what about the patch in #1234834: 'module' column of role_permission table is not populated on upgrades? As far as I can tell from the comments above, that's the preferred way to fix this? Though that issue looks to be in limbo as well.
Comment #34
kevinquillen CreditAttribution: kevinquillen commentedI ran into this issue when building custom entities and while everything was fine and dandy for a few days, this error started happening. After applying rfay's patch in #7, this went away immediately.
Comment #35
xjm@Kevin Quillen-- what about the patch in the other issue? Could you test that one as well?
Comment #36
kevinquillen CreditAttribution: kevinquillen commentedTo reproduce (in my case) with D7.10, Entity API 7.x-1.0-rc1:
- Enable Entity API
- Create an Entity, with its own EntityUIController
- YourEntityUIController calls overviewTable(), which calls entity_load: $entities = entity_load($this->entityType, FALSE, $conditions);
The result is this error:
"Recoverable fatal error: Argument 2 passed to SelectQuery::fields() must be an array, null given, called in /sandbox/includes/entity.inc on line 284 and defined in SelectQuery->fields() (line 1320 of /sandbox/includes/database/select.inc)."
It would appear that $this->entityInfo['schema_fields_sql']['base table'] is not populated.
After applying rfay's patch, the error goes away, but then I get a new warning:
"Warning: Invalid argument supplied for foreach() in EntityAPIController->load() (line 223 of /sandbox/sites/all/modules/entity/includes/entity.controller.inc)." - which is in Entity API and not core entity.inc.
What is odd is I had created this particular Entity and its UI and CRUD a week ago and it worked perfectly fine, in the midst of many drush rr and drush cc all while working. Today is the first time I have seen this error, though nothing has changed in my entity code.
Comment #37
xjmAlright, so it sounds like it is only reproduced sporadically, per #36? If we could find a specific set of steps to reproduce from "Install D7 HEAD" that would be really helpful.
@mgifford @DamienMcKenna @asciikewl -- Was the Entity API module installed when you saw the bug as well? If so, we might want to move this issue to that queue for a closer look.
Comment #38
lowkee CreditAttribution: lowkee commentedI got this issue while doing a clear cache all in order to install a few custom panels layouts using 7.10
The patch from rfay worked perfectly. The connection to panels may be simply timing, not causal.
I am using Entity API module.
Error:
Recoverable fatal error: Argument 2 passed to SelectQuery::fields() must be an array, null given, called in includes/entity.inc on line 284 and defined in SelectQuery->fields() (line 1320 of includes/database/select.inc).
Comment #39
xjmAlright, moving to the Entity API queue for a closer look based on #38.
Comment #40
xjmComment #41
tim.plunkettEasy way to reproduce this: enable both http://drupal.org/sandbox/amateescu/1429904 and http://drupal.org/project/webform_entity, then clear the cache.
Comment #42
fagoThe entity api module controller does nothing different with those fields than the core controller. The problem is that this is not populated, probably due to cache initializing issue.
I remember, the uuid module did or does some trickery here. Else, try to find the module or modules combination causing it...
Yep, I think the webform_entity module should bypass entity_load in hook_entity_info_alter(). Using entity_load() at this stage could be the cause.
Comment #43
ShaneOnABike CreditAttribution: ShaneOnABike commentedI also encountered this when I enabled Rules module
Comment #44
madeby CreditAttribution: madeby commentedJust got this error on a live D7.12 site after emptying the cache.
It broke the entire site and it was down for 2 hours before I applied the patch on this page.
Is the patch the way to permanently fix this or?
Comment #45
Damien Tournoud CreditAttribution: Damien Tournoud commentedLikely this is a symptom of #1416558: hook_entity_info(), hook_schema(), and the field system are strongly bound to each other again.
Comment #46
Damien Tournoud CreditAttribution: Damien Tournoud commentedThis is a core issue, as it is a case of info hook dependencies going haywire.
Comment #47
ShaneOnABike CreditAttribution: ShaneOnABike commentedBut this is happening in D7 as well so shouldn't it be set to that version?
Comment #48
tim.plunkett@ShaneOnABike, bugs are fixed in the latest branch first and then backported: http://drupal.org/node/767608
Comment #49
madeby CreditAttribution: madeby commentedJust got this error as well with the entity module in core.
Notice: Undefined index: revision in entity_extract_ids() (line 7496 of /includes/common.inc).
Notice: Undefined index: load hook in DrupalDefaultEntityController->attachLoad() (line 334 of /includes/entity.inc).
Notice: Undefined index: load hook in DrupalDefaultEntityController->attachLoad() (line 334 of /includes/entity.inc).
Notice: Undefined index: load hook in DrupalDefaultEntityController->attachLoad() (line 334 of /includes/entity.inc).
Running D7.12.
Comment #50
srlawr CreditAttribution: srlawr commentedI have implemented the patch in #7, and though it has got me away from the WSOD with this error message, I now get a half-page-loaded, drupal error message:
PDOException: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'AS , revision.uid AS revision_uid FROM node base INNER JOIN node_revision revis' at line 1: SELECT base.*, revision.*, revision.timestamp AS revision_timestamp, base. AS , revision.uid AS revision_uid FROM {node} base INNER JOIN {node_revision} revision ON revision.vid = base.vid WHERE (base.nid IN (:db_condition_placeholder_0, :db_condition_placeholder_1)) ; Array ( [:db_condition_placeholder_0] => 37242 [:db_condition_placeholder_1] => 37244 ) in DrupalDefaultEntityController->load() (line 196 of \includes\entity.inc).
Comment #51
tim.plunkettHere's a very hacky patch I've been running in the short term.
Comment #52
srlawr CreditAttribution: srlawr commentedYes, I have been "implementing" a similar mechanism, of simply adding the "true" in as a second parameter OD when it crashes out, but this provides a slightly more elegant way of maintaining that.
The fix in 17 of this issue http://drupal.org/node/1438278 does seem to have worked for me more long term though (well, 24 hours).. if it's worth checking out.
Comment #53
tim.plunkettIndeed, #1438278-17: Latest dev crashes Drupal completely solves my problem and mitigates the need for my patch in #51.
Comment #54
Taras Zavaliy CreditAttribution: Taras Zavaliy commentedThanks to #7 patch my site (Drupal 7.16) works again! The problem however was not caused by update. After a lot of testing i still can't figure out this.
Comment #55
helmo CreditAttribution: helmo commented#7 also saved a site I'm working on (7.18).
As this site does not include the entityreference module, the solution from #53 was not applicable.
Comment #56
Elijah LynnDrupal 7.23 - Trying to run a Simpletest* threw this error. Applied patch in #7 and tests are running fine now.
* Tried three different Simpletests, 2 were custom & one was core -> 'Actions configuration'.
Comment #57
deepak_kadam CreditAttribution: deepak_kadam commentedHi there,
getting the error while clearing the cache:
Catchable fatal error: Argument 2 passed to SelectQuery::fields() must be an array, null given, called in /includes/entity.inc on line 284 and defined in /includes/database/select.inc on line 1300
Solution:
https://drupal.org/files/drupal-1158114-51.patch
The patch at above link solve my problem.
Thank You.
Comment #58
helmo CreditAttribution: helmo commented7: drupal.taxonomy_might_not_exist.patch queued for re-testing.
Comment #60
helmo CreditAttribution: helmo commentedThe patch from #7 still applies to D7, but D8 has changed substantially and is probably no longer affected.
So let's assume this is only a D7 issue... and just solve this
Comment #61
helmo CreditAttribution: helmo commented7: drupal.taxonomy_might_not_exist.patch queued for re-testing.
Comment #63
helmo CreditAttribution: helmo commentedTss an offset of 5 lines :)
Here's a re-roll :)
Comment #64
ergophobe CreditAttribution: ergophobe commented#63 did the trick for me.
Running Drupal 7.24 with Panopoly on an otherwise fairly clean install (testing phase with basically no content).
Comment #65
helmo CreditAttribution: helmo commentedComment #66
3eidoz CreditAttribution: 3eidoz commentedNotice: Undefined index: controller class in /drupal/sites/all/modules/entity/entity.module on line 84 Warning: class_implements(): object or string expected in /drupal/sites/all/modules/entity/entity.module on line 84 Warning: in_array() expects parameter 2 to be array, boolean given in /drupal/sites/all/modules/entity/entity.module on line 84 Notice: Undefined index: schema_fields_sql in /drupal/includes/entity.inc on line 260 Catchable fatal error: Argument 2 passed to SelectQuery::fields() must be an array, null given, called in /drupal/includes/entity.inc on line 279 and defined in /drupal/includes/database/select.inc on line 1300
please help
Comment #68
David_Rothstein CreditAttribution: David_Rothstein commented63: drupal-component-1158114-63.patch queued for re-testing.
Comment #69
sinasalek CreditAttribution: sinasalek commentedPatch #68 solved my problem for Drupal 7 latest version
Comment #70
schulle@web.de CreditAttribution: schulle@web.de commentedPatch #68 solved my problem for Drupal 7.30
Comment #71
helmo CreditAttribution: helmo commented#67 was a test bot glitch ... I see multiple +1's so back to RTBC.
Comment #75
dcam CreditAttribution: dcam commentedComment #76
David_Rothstein CreditAttribution: David_Rothstein commentedThis seems a bit like it's hiding the bug more than fixing it... "base table" is (to my knowledge) a required property of hook_entity_info(), and the code in this function is expecting it to be accurate and to be able to use it.
I think we need to track down the root cause of the bug. There is discussion earlier in the issue of a few possible causes...
Comment #77
kevinquillen CreditAttribution: kevinquillen commentedThis just happened to me recently on a Pantheon site, making it totally inaccessible WSOD. The patch indeed got me through, but as David says in #76, this just circumvents a root cause.
Comment #78
deanflory CreditAttribution: deanflory commentedJust ran into this when back-tracking to a backup due to drupageddon with an update to D7.33. Trying the patch...but clearly there needs to be a fix after 3.5 years.
I did not get the error on one site with far fewer modules than the second that has lots of modules and was stopped in it's tracks with this bad error.
Comment #79
srobert72 CreditAttribution: srobert72 commentedPatch #68 solved my problem for Drupal 7.34
As others said, I don't know if it the good solution or not.
But it needs a fix because this error really crashes sites and it's difficult to have a hand on them again.
Comment #80
kevinquillen CreditAttribution: kevinquillen commentedYes - I feel that this simply hides the symptoms instead of fixing the root issue... it is hard to reproduce but it is a particularly nasty bug. Combined with caching layers like Redis and Varnish, once this gets up to memory cache it is very difficult to correct the issue (typically a cache clear - but it takes a lot more with corrupted cache bins).
Comment #81
lucyp CreditAttribution: lucyp commentedI just wanted to confirm that I had this bug too. For me it was dependent on the Rules module. With Rules installed, I would get this site-crashing error every time I would enable/disable a module. Clearing the cache with drush would fix it. With Rules uninstalled, I do not encounter this error at all.
I used the patch in #63/68 and can confirm that I no longer get the site-crashing error when I enable/disable a module.
I do, however get a few notices and warnings:
Notice: Undefined index: schema_fields_sql in .../sites/all/modules/rules/includes/rules.core.inc on line 56
Warning: Invalid argument supplied for foreach() in .../sites/all/modules/rules/includes/rules.core.inc on line 56
Notice: Undefined index: field cache in .../modules/field/field.attach.inc on line 634
Notice: Undefined index: revision in .../includes/common.inc on line 7761
Notice: Undefined index: revision in .../includes/common.inc on line 7761
Notice: Undefined index: revision in .../includes/common.inc on line 7761
Notice: Undefined index: load hook in .../sites/all/modules/entity/includes/entity.controller.inc on line 861
I don't really understand the finer points of what's happening here, but am just adding my 2 cents in case it helps solve the problem. Thanks to everyone who is working on this.
Comment #82
Cristina_Drupal CreditAttribution: Cristina_Drupal commentedCould someone help me, please??. I've got this error:
Catchable fatal error: Argument 2 passed to SelectQuery::fields() must be an array, null given, called in /home/calonso/public_html/inicial7/includes/entity.inc on line 279 and defined in /home/calonso/public_html/inicial7/includes/database/select.inc on line 1300
I deleted some modules of my file system (a big error, I know):
-Gmap
-Openlayers
-Address Field
-Geofield
-GeoPhp
And my website crashed.
Please, any solution. :(
Comment #83
winstonchurchil99 CreditAttribution: winstonchurchil99 as a volunteer commentedUpldate the drupal core to 7.41 release solve the bug for me:
Comment #84
dasfuller CreditAttribution: dasfuller as a volunteer and commentedRunning 7.44 and hit this bug hard on sites that use custom modules that are entity-heavy. Sites become absolutely unrecoverable. Applying patch #63 helped us get back online. Get this patch into drupal core as soon as possible please!
Comment #85
izus CreditAttribution: izus commentedPatch #63 worked for us too.
Thanks
Comment #86
marcelomg CreditAttribution: marcelomg commentedSame problem happening, none of the patches worked for me.
Started happening after installing Brightcove module.
Drupal - 7.41
Comment #87
chrisrockwell CreditAttribution: chrisrockwell commentedI closed #2673204: Argument 2 passed to SelectQuery::fields() must be of the type array, null given as a duplicate. There is also #1546672: Catchable fatal error: Argument 2 passed to SelectQuery::fields() must be an array, null given. Core could definitely help handle this gracefully (Same issue #1606686: Gracefully handle broken entity controller bugs, thus avoiding WSOD) but this seems to be an issue with other modules.
There are at least 5 open issues: https://www.drupal.org/project/issues/drupal?text=Argument+2+passed+to+S... related to this.
Comment #88
travis-bradbury CreditAttribution: travis-bradbury as a volunteer commentedI'm just sharing my experience with this issue.
Suspiciously, I was only able to replicate this issue on one machine, not other instances of my project. The application would die pretty early on while expecting to have some data (
['schema_fields_sql']['base table']
) on rules_config. If I manually cleared the cache table I could watch it loading schemas. While calling all of the implementedhook_schema()
s, It'd suddenly jump back to a breakpoint inentity_get_info()
. Now it's trying to get schema information again but it's just loading from cache, which is incomplete since we never finished calling thehook_schema()
s.Turns out an error was being triggered in
ldap_query_schema()
because it was using an undefined constant. The error was logged bywatchdog()
, which invokeshook_watchdog()
. Rules implements that and invokes an event, which requires reloading its information, ends up callingentity_get_info()
, and we're getting our cached, incomplete entity information.The constant was undefined because I had not installed the ldap extensions for PHP on that machine. Installing those appears to have fixed the issue.
So, if you're encountering this error, it could be helpful to look in
drupal_get_complete_schema()
to see if an error occurs while invoking each module'shook_schema()
.This experience may be very different from what has caused the errors for others, but from my investigation it seems that changes such as in #63, where argument 2 to
SelectQuery::fields()
is forced to be an array, are not a solution since they'll only work around this error and allow the problem to be an issue later (such as in #81 where instead of the program crashing they're getting a bunch of less-fatal errors later in the program's execution).Comment #89
chrisrockwell CreditAttribution: chrisrockwell commentedI closed more duplicates, pointing them all here and referencing.
Comment #90
Michael-IDA CreditAttribution: Michael-IDA as a volunteer commentedlove these six year old bugs ;(
New install of Commerce Kickstart, 7.x-2.44, https://www.drupal.org/project/commerce_kickstart
Added:
Administration menu, https://www.drupal.org/project/admin_menu
Wysiwyg, https://www.drupal.org/project/wysiwyg
Created Roles through PHP:
Even a double clear cache doesn’t help (‘drush cc all && drush cc all').
Site displays fine, but now PHP can’t get past drupal_bootstrap.
Here’s the errors, the first 3 REMOTE_ADDR have been around for years as well:
Edit:
PS: I can provide tarballs, 40MB total, if someone wants a known bad copy to work from.
Edit2:
Maybe. As a possible fix, try both clearing cache and running cron. I'm not sure which was run first, but problem vanished...
Comment #91
marysmech CreditAttribution: marysmech at Freely Agency commentedI have experienced same problem on Drupal 7.54.
After little debugging I created patch that seem to fix the error.
Comment #92
helmo CreditAttribution: helmo at Initfour websolutions commentedComment #93
shaunole CreditAttribution: shaunole commentedI was able to validate this issue by executing the following drush command on the entity in question (In my case this was commerce_license):
What I found was that the ['schema_fields_sql']['base table'] value was NULL as was the ['schema_fields_sql']['revision table'].
After clearing cache and forcing cron to run without halting on errors, the schema repopulated the base and revision table values. I was able to verify this using the above drush command again.
I'm not sure what caused the corruption of that schema data, but hopefully these steps help others in the pursuit of resolution.
Comment #94
arnoldbird CreditAttribution: arnoldbird commentedNone of the above solutions are working for me. My site is down and I see no way to restore it. Drush won't run either. If I run "drush cc all", it hangs.
I'm experiencing this following an upgrade to 7.66. Rolling back database and code has not resolved the problem. The drupal_bootstrap() function never finishes executing, so I'm not able to do something like adding drupal_flush_all_caches() to index.php after the drupal_bootstrap() function call.
The error I'm seeing...
Comment #95
arnoldbird CreditAttribution: arnoldbird commentedSwitching this from critical to normal because I was able to recover my site. I'm still trying to figure out how I might have resolved it, but I think it involved steps mentioned above, and then at a certain point I had to reboot mysql.
Comment #96
arnoldbird CreditAttribution: arnoldbird commentedFour and a half years ago in this thread, it was suggested that the patch in #63 hides the bug but doesn't find the root cause. That may be, but it doesn't seem like anyone is going to find the root cause, and the patch in #63 still works. Perhaps it should be committed so we don't have to patch entity.inc every time we do a core upgrade affecting entity.inc. Perfect is enemy of the good?
Comment #97
DamienMcKennaComment #98
rcodina CreditAttribution: rcodina commentedPatch on #63 works for me and patch on #91 doesn't fix the problem. Also, patch available on #2673204: Argument 2 passed to SelectQuery::fields() must be of the type array, null given works for me too. I agree with @arnoldbird that patch on #63 should be committed ASAP. Thanks!
Comment #99
travis-bradbury CreditAttribution: travis-bradbury as a volunteer commented#81 vividly illustrates that the patch in #63 does not solve anything. Instead, it adds separation between the actual problem and its symptoms. Instead of the fatal error being discussed you will have different issues that will be at least severe, and possibly more severe because the application is broken but still running. What will it do?
It's likely that many of the reports of this problem were from totally different causes. It's possible that the only thing Drupal core can do to help here would be to reveal the problem earlier - crashing at the source of the problem instead of in the middle of the database api - but I have no idea if there's a practical way to do that.
Comment #100
skyredwangWe can't commit things that we know would cause more trouble in the future. Therefore, settings the status back
Comment #101
Ronino CreditAttribution: Ronino as a volunteer commentedThis bug occurred to me when I called watchdog() in some hook_schema_alter() which caused Rules to trigger an event. It was gone after I removed the watchdog() call.
Here's the backtrace:
Comment #102
jpoesen CreditAttribution: jpoesen commentedWe had this exact issue today (2022-04-11, D7.88.
The approach in #93 worked for us: clear cache + run cron.
Still no idea what caused the issue in the first place.
Thanks, @shaunole!