Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
After upgrading to latest dev versions for views, calendar and date, I'm getting the following error whenever I look at "Year" view for a calendar:
"Fatal error: Call to a member function advanced_render() on a non-object in ...\views\theme\theme.inc on line 225"
Calendar 6.x-2.x-dev (2010 April-1)
Date 6.x-2.x-dev (2010-Mar-26)
Views 6.x-2.x-dev (2010-Apr-07)
Again, I can only produce the error on "Year" view (not day, week, month etc.). Any ideas?
Comment | File | Size | Author |
---|---|---|---|
#29 | 765296-id-out-of-sync_0.patch | 672 bytes | dawehner |
#22 | 765296-id-out-of-sync.patch | 2.42 KB | merlinofchaos |
#17 | 765296-id-out-of-sync.patch | 2.71 KB | merlinofchaos |
#4 | calendar_date_view.txt | 14.59 KB | endiku |
Comments
Comment #1
NoDice CreditAttribution: NoDice commentedHmmm it appears now that it's not just "Year" view. It's basically any calendar view that has a Date node.
Comment #2
endiku CreditAttribution: endiku commentedYes, I just installed the current dev version of Date and Views3 and I am having this fatal error out on the Upcoming view.
I haven't found a concise view yet. So far the issue is in the Calendar_date view.
The Date argument has this warning
warning: Invalid argument supplied for foreach() in C:\Apache\htdocs\drupal\includes\form.inc on line 1207.
Comment #3
merlinofchaos CreditAttribution: merlinofchaos commentedCan you please attach an export of the smallest possible view that demonstrates this? Replicating this will be crucial to understanding what is going on.
Comment #4
endiku CreditAttribution: endiku commentedThis is just the default build Calendar_date view from the Calendar module. It fatal error's on any view or even referencing the views through panels. Sorry that isn't as much help at the moment.
Comment #5
NoDice CreditAttribution: NoDice commentedI just found a similar issue over at calendar here: PHP 5.3 issue - Attempt to modify property of non-object
Seems to be related to new PHP5.3 functionality and not all 3 modules (views,date,calendar) are fully compatible w/ PHP5.3. But then again, I'm only running PHP 5.2.9, so maybe I need to upgrade and this issue would go away...? Or I could roll-back to older versions of all 3. They worked before I upgraded them all today.
Here are my versions again:
Calendar 6.x-2.x-dev (2010 April-1)
Date 6.x-2.x-dev (2010-Mar-26)
Views 6.x-2.x-dev (2010-Apr-07)
PHP Version: 5.2.9
MySQL: 5.1.33
Again, I only get this error if the calendar view has date nodes. For example, empty month view is fine, empty day view is fine, but any view that has even 1 date node produces this error.
Comment #6
chrisfromredfinJust FYI it seems like the schema updates should still work with 2.8 (seem to for me); I had to revert to 2.8 so my production site worked, and seems to be running OK (till a fix comes). (This happened to me when applying the security update for 2.9, not the -dev version - though it's presumably the same problem.)
Comment #7
Anonymous (not verified) CreditAttribution: Anonymous commentedSince upgrading views to 2.9 I am also seeing this issue on calendar pages
Comment #8
jmcclelland CreditAttribution: jmcclelland commentedSame here.
Comment #9
chrisal CreditAttribution: chrisal commentedSame error on my two sites. (same error with 3.0 alpha). Thanks for patch or workaround
Comment #10
jmcclelland CreditAttribution: jmcclelland commentedI have no idea what the real problem is - but this patch makes the error go away:
Comment #11
merlinofchaos CreditAttribution: merlinofchaos commentedhttp://drupal.org/node/765410 is reporting a similar problem with views_custom_field
It's going to take some private time with debugging the flow, I think, to figure out what's wrong here.
Comment #12
Island Usurper CreditAttribution: Island Usurper commentedIt's not just Date, because I'm having the same problem with an Imagefield field. I don't know what's special about it because I can add an identical field to the view, and it works. But if I take the new field off again, it stops working.
Comment #13
Druper CreditAttribution: Druper commentedI had the same problem after upgrading to Views 2.9. Reverted to 2.8 until fix is found.
Just wanted to point out that problem exists in PHP 5.2.13 too, not restricted to 5.3
Comment #14
georgedamonkey CreditAttribution: georgedamonkey commentedSadly, that does not work for me at all...
Comment #15
merlinofchaos CreditAttribution: merlinofchaos commentedOk, the problem is that the 'id' does not match the actual key on some fields.
I do not currently know why this would be. I'm trying to figure out a good fix.
As a workaround, you might be able to export your view, go through the 'fields' section and ensure that the 'id' matches the key to the array, then re-import. I know that's a bad workaround but I think it'll fix the views until I can find the right way to do this.
Comment #16
bishless CreditAttribution: bishless commented/sigh... wish I'd read this thread before upgrading this morning. I'm borked w/ the same issue.
Comment #17
merlinofchaos CreditAttribution: merlinofchaos commentedUrgent testing needed: Anyone experiencing this trouble, does this fix it?
Comment #18
Steve Hanson CreditAttribution: Steve Hanson commentedEarl -
I made a quick pass at trying this out on the site where I'm having trouble with the 2.9 update, and this patch doesn't seem to have fixed anything -- I'll try to take a closer look in a little while.
Comment #19
chrisfromredfinI have a good safe test environment where I can test this. I applied the patch (and I'm pretty sure I verified that it applied correctly. It doesn't seem to fix my issue, but additionally, it introduces:
Fatal error: Cannot use object of type views_display as array in /var/www/tc.redfinsolutions.net/sites/all/modules/views/includes/view.inc on line 1869.
UPDATE: I reversed the patch (so I'm at straight views 2.9 now) and instead just put in some debug statements to show $id and $this->handler[$id]['id']... those statements weren't even being executed (nothing in my watchdog), so it makes me think that the code to fix the ID is too late to fix the root cause of MY particular problem, anyway. I can provide my exported view if you want, but it's a total bear. It's the default 'Calendar' view that's generated, plus a bunch of additional filters, etc. How else can I help?
Comment #20
merlinofchaos CreditAttribution: merlinofchaos commentedOh hm. Ok, that means my patch is wrong. Thanks for the report, I'll roll a new one.
Comment #21
chrisfromredfinIt is something with the ID's, as you likely know by now. In the $view object the id is "field_date," and in the field object the ID is "field_date_value."
Comment #22
merlinofchaos CreditAttribution: merlinofchaos commentedYes, first patch was *really* wrong. Sigh. Try this one?
Comment #23
timb CreditAttribution: timb commentedI received this error after upgrading to views 2.9 on a site using calendar. Reverting to views 2.8 has brought the site back on line.
Comment #24
timb CreditAttribution: timb commentedComment #25
merlinofchaos CreditAttribution: merlinofchaos commentedWe don't need tags for specific issues. That's a needless creation of tags in the drupal.org database. :/
Comment #26
dawehnerThe last tag is just not true. Thats not caused by the security update.
This kind of tags are not really helping.
views-3.x roadmap or novice or needs tests are some good example for tags.
Comment #27
dawehnerand remove
Comment #28
chrisfromredfinPatch in #22's a winner for me.
Comment #29
dawehnerPatch worked fine for this view:
Attached a patch for views3
Comment #30
merlinofchaos CreditAttribution: merlinofchaos commentedCommitted to all branches.
Comment #31
endiku CreditAttribution: endiku commentedJust wanted to say cudos and thanks for the dedication. The quick response time was amazing.
Crap, I didn't intend to change the issue, my bad.
Comment #32
dawehneryou shouldn't change the issue stuff after fixing it :) I think this is not open anymore
Comment #33
IreneKraus CreditAttribution: IreneKraus commentedI was referred to this thread as the update in Views has rendered one of my sites inoperable. That site is run as part of a multi-site install and the other sites are fine. Site is for a regional computer user group that does promote both live and web-based events. When operational, it can be found at http://cebug.org/
While I'd like to try applying the patch listed in #22, I would have to do this manually as it is on a live server. According to the directions for manually applying a patch:
http://drupal.org/node/534548
The patch directions should begin with telling me what file I need to alter. That isn't provided in this patch so I don't know how to apply it. The one in #29 is much the same thing with no clear idea of what needs to be changed.
As the other site in the install is fine and I have no desire to rollback to an insecure version of Views, I'm going to have to do something else. What I think I will do is setup and install in XAMPP using the database backup for the site I made before the upgrade. The database in use on the site will be wiped clean and I'll do a fresh install of Drupal making sure I avoid activating the Calendar and so forth. (Those that differ from what is in use on other sites that are working fine.) I'll copy the content from that backup into the new install and have to come up with some sort of workaround for publicizing those events until a fix is found for those things. Going to be a lot of work, but it is the best choice I can see as of the moment on what to do.
I am working on establishing a completely separate install of Drupal for testing work. Had thought to use that mainly for testing as I build themes for the sites I support, but I am setting up examples of all of the content types in use on those active sites. From now on I will do upgrades on THAT install first so as to avoid screwing up live sites. (Having made a backup to that prior to doing upgrades.) If there is such a critical issue this should help me avoid a repeat of this kind of situation.
Comment #34
merlinofchaos CreditAttribution: merlinofchaos commentedThe patch in #22 is already released in Views 2.10. Perhaps you should try that first.
Comment #35
IreneKraus CreditAttribution: IreneKraus commentedI'd love to, but how can I upgrade the site to using Views 2.10 when I can't get into it in anyway from the previous upgrade. Site is still off-line, so maybe if I just trying to run the update script again? Worth a shot...
Comment #36
IreneKraus CreditAttribution: IreneKraus commentedFor anyone wondering, I was indeed able to run the update script on the site. It worked! Site is back and operational again. Thanks everyone for all the GREAT work and suggestions. Saved me a lot of frustration and work time as I'm rebuilding that site from scratch anyway. (Long story involving corrupted and lost databases from a hosting move.) Very happy camper right now!