All of the other views work fine, but when I click year I get:
Fatal error: Allowed memory size of 100663296 bytes exhausted (tried to allocate 2646262 bytes) in /usr/www/users/pl884/includes/bootstrap.inc on line 735
I got the error on the release version as well as the latest dev.
Calendar 6.x-2.x-dev (2009-May-11)
Date 6.x-2.2
Views 6.x-2.6
php_value memory_limit 96M
The changes I've made are to limit to a particular node type, I'm showing taxonomy all terms in "calendar page" but not "year view" (I'm not sure how those views relate), and I changed the date argument to show my date field rather than the default node date.
If no one else is having this problem, is there anyway I can revert to test the default settings without losing all my customizations?
Comment | File | Size | Author |
---|---|---|---|
#14 | calender-year.patch | 528 bytes | marcingy |
Comments
Comment #1
Poieo CreditAttribution: Poieo commentedI am experiencing the same issue. Fatal error on the year view only. I have 20+ installs of these modules on different sites on the same server and this is the first time I've had this issue. This install is the only one using the very latest dev release. Also, this is the first time I used Date Tools to create the calendar...maybe a connection.
Comment #2
troybthompson CreditAttribution: troybthompson commentedI didn't use date tools, but I originally had "Event" installed and uninstalled it because it didn't work with views, then created another content type with a date field. I had the same problem with the recommended version of Calendar and updated to the dev version to see if it was fixed. Hope this helps.
Comment #3
cronix CreditAttribution: cronix commentedSame issue here. Only with the year view. Changed to DEV, but that did not help. I have tried to configure php with 512mb per script, that did not help either.
Comment #4
GatorBat CreditAttribution: GatorBat commentedI too am receiving this error, only on my year view.
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 2406813 bytes) in D:\Drupal6\includes\bootstrap.inc on line 735
My PHP Memory Limit is currently set to 128MB.
Running:
Drupal 6.12
Calendar: 6.x-2.x-dev (2009-May-11)
Date: 6.x.2.x-dev (2009-Jun-09)
I have created a custom "Event" type using CCK, and performed the security update a few days prior for the views module. Clearing Views cache and site cache have had no impact on the problem. I know the year view has worked before (within the past 3-4 months), but I hadn't checked in a while, so I'm not exactly sure when it stopped working. Please let me know if I can provide any more information.
Comment #5
cronix CreditAttribution: cronix commentedI installed the new Views too. Would that be the reason why this is not working?
Comment #6
pascalduez CreditAttribution: pascalduez commentedSame issue here, the year view give a blank page, and have the PHP memory limit error in logs.
I reverted to views views-6.x-2.5, and the year view is back.
Running:
Drupal 6.12
Calendar: 6.x-2.1
Date: 6.x.2.2
Views: 6.x-2.6
The blank page seems to only occurs on current year (2009), while other years works.
Comment #7
jriedel CreditAttribution: jriedel commentedSame issue here. I'm not using the DEV version, but that laestest production 6.X-2.1. I updated views for a security issue and now the year view only of a calendar gives a 500 error.
Comment #8
Daryljames CreditAttribution: Daryljames commentedsame here...
Comment #9
nehagupt CreditAttribution: nehagupt commentedI am receiving the exact same error. I have the latest dev modules installed for Views, Calendar, Date and CCK. If it was a memory issue, then other pages would not show up either. However its just the year calendar view which is showing the Fatal Error. I have two different content types that I am trying to display on calendar that use date (Event using event module and Appointments using cck). My php memory limit is set to 128 MB. Here is the error:
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 6035564 bytes) in /var/www/drupal/drupal-6.12/includes/bootstrap.inc on line 735
Earlier the memory was 96 MB, and increasing that did not really help
Comment #10
NickSI CreditAttribution: NickSI commentedI've got same problem. Quick check showed that multiple calls to one of template processing function (template_preprocess_calendar) in case of year view results in memory overload. This function has build-in check in order to avoid multiple calls, however it is commented for some reason.
Open theme.inc file in theme folder of calendar module and find following code:
Uncomment return statement and year view will work again. Other calandar views works as well, although I had no time for detailed testing.
Comment #11
GatorBat CreditAttribution: GatorBat commentedGreat catch, NickSI! Uncommenting that return statement has resolved my Year-view problem, and has not impacted my other calendar views. Thanks for this solution, and hopefully it will be a simple fix rolled into the next dev or full version :)
Comment #12
Poieo CreditAttribution: Poieo commented#10 solved the problem for me as well. Thanks!
Comment #13
cronix CreditAttribution: cronix commentedI am soo happy now. Working perfectly.
Comment #14
marcingy CreditAttribution: marcingy commentedThe fix worked for me so I thought I'd roll a patch to hopefully get the fix committed.
Comment #15
jriedel CreditAttribution: jriedel commented@marcingy Thanks, just what I was going to say was needed, a patch.
I just applied it and my problem is fixed.
Comment #16
marcingy CreditAttribution: marcingy commentedmoving the status up as it works
Comment #17
gooddesignusa CreditAttribution: gooddesignusa commentedused info from post #10.
OMG thank god that fixed the problem. I thought i broke something. I love it when the community fixes a problem before i know about it lol :).
Thanks again
Comment #18
Tony Sharpe CreditAttribution: Tony Sharpe commentedThe fix in #10 did it for me as well. I can describe a simple clean minimal install and setup to recreate this problem if required by the developers. Latest dev of Views, Calendar and Date did not fix problem without using the fix in #10.
Comment #19
ashtonium CreditAttribution: ashtonium commentedThanks for the patch, it fixed the issue. I'm also bumping priority since the year display is completely broken without it.
Comment #20
alphex CreditAttribution: alphex commentedconfirming fix in #10 works for me.
Looking forward to the update to include this, so I can test drush :)
Comment #21
snorkers CreditAttribution: snorkers commented#10 worked for me too. VMT @NickSI
Comment #22
dshaw CreditAttribution: dshaw commented#10 worked for me too. Nice work NickSI!
I can't tell immediately, has this been rolled into the latest version?
Comment #23
pwolanin CreditAttribution: pwolanin commentedTrying to track down where this change came from. The original issue where that change was made seems to be this one:
http://drupal.org/node/360967
The main changes were to the calendar .module and .install, here:
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/calendar/ca...
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/calendar/ca...
Which are the changes actually described in the issue. It's unclear whether the change to theme.inc was needed to make this work?
Comment #24
CrashNet CreditAttribution: CrashNet commentedJust to add to those who have tried it, I too had this error, and it was fixed by uncommenting these lines. Great catch!
Comment #25
KarenS CreditAttribution: KarenS commentedOK that change should not have been made for that issue, so that is definitely a mistake. I think there may have been some other reason why that was there, but this is clearly breaking other things so I'm going to commit this change and keep an eye on it to try to figure out if there are any other issues.
Thanks Peter for all the detective work!
Comment #26
KarenS CreditAttribution: KarenS commentedAnd thanks everyone else for the patches and help (and your patience)!
Comment #27
clintthayer CreditAttribution: clintthayer commentedThanks for the fix. Works great!
Comment #28
gooddesignusa CreditAttribution: gooddesignusa commentedwhy wasn't this rolled into the newest version. I updated and had to re-patch :(
Comment #29
dawehnerthe problem is that the issue is newer than the latest stable version.
Perhaps there should have been a simpletest for this if :p
Comment #31
elsvandeveire CreditAttribution: elsvandeveire commented#10 Wauw Great! Thank u so much