If Views is enabled as part of an install profile, it is will be enabled before there is a schema. Therefore, in views.inc line 1172 this line:
foreach ($schema['fields'] as $field => $info) {
will throw an "invalid argument supplied to foreach()" warning.
It seems like it should be a trivia matter of tossing an if (!empty()) around the foreach(), but I am not sure if there would be other knock-on badness that results. I leave that to those who know more than I do to determine if it's more serious.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | schema_warning.txt | 299 bytes | andrewlevine |
| #5 | views.profile.tgz | 2.52 KB | starkos |
Comments
Comment #1
merlinofchaos commentedIf there is no schema then there shouldn't be any $view objects, either.
Comment #2
Crell commentedWell, it's trying to create one. I am not defining any views, just noting views in the install profile. Is there any debugging you want me to try to figure out why it's doing that in the first place?
Comment #3
merlinofchaos commentedMy best guess is that it's trying to register menu hooks for the default views. I'm not sure it's safe to let that object construct itself without schema, though if it's just creating default views they should theoretically be completely filled in and the schema is unnecessary.
You can put vsm_trace() or vpr_trace() in that function and see where it's being called from.
Comment #4
starkos commentedSubscribing - I'm getting this same issue with both beta3 and HEAD. I'm not creating any views at this point, just trying to list 'views' and 'views_ui' in my profile's module list.
The error has moved to line 1312 in HEAD, but it is the same issue.
I tried adding vsm_trace() but saw no output. vpr_trace() gave me an error "undefined function dpr()". If you can give me a quick dummies guide to those functions I'll get a stack trace for you.
Comment #5
starkos commentedI put together a simple install profile to demonstrate the problem (see attached), and along the way found out some more about the issue. It only happens if the CCK content module is enabled BEFORE views. If you do it after views everything works okay.
I'm not sure what exactly is causing the conflict. Hopefully this information helps to pin it down.
Comment #6
merlinofchaos commenteddpr() is a devel.module function. You can replace it with print '
'; (approximately) to do the same job.
It looks like there's a workaround, at least.
Comment #7
andrewlevine commentedsimple enough, seems to work, and don't notice any side effects
Comment #8
andrewlevine commentedThis should apply to the latest RC
Comment #9
merlinofchaos commentedCommitted! Thanks for the patch!
Comment #10
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.