After installing 7.x-3.4, the calendar block does not view properly. Further, the following issues are seen:
- Error 'calendar_plugin_style: The calendar row plugin is required when using the calendar style, but it is missing.' seen.
- Navigating to 'admin/structure/views/view/calendar/edit' results in 500 error.
- The following error seen in dblog:
'calendar_plugin_style: The calendar row plugin is required when using the calendar style, but it is missing.'
in calendar_plugin_style->render() (line 228 of sites/all/modules/calendar/includes/calendar_plugin_style.inc).

Comments

carlnewton’s picture

I also have this issue with the new D7 update, except I don't get the 500 error you mentioned. I did before I cleared the cache though. Following.

Edit: I get the following warning appear twice on the view edit page:

"Style Calendar requires a row style but the row plugin is invalid."

waverate’s picture

Same issue as OP.

- missing calendar pluging style message
- missing calendar_plugin_style error in dblog
- cannot edit view:

httpd/error_log
PHP Fatal error:  Call to a member function summary_title() on a non-object in /var/www/html/drupal-7.14/sites/all/modules/views/plugins/views_plugin_display.inc on line 1148, referer: http://example.com/
Simon Georges’s picture

It appears that sometimes, you need to rebuild the View using the last Calendar template (at least it seems to have worked on my instance).

waverate’s picture

Simon's advice at #3 works.

I deleted the view and then built a new view from template (/admin/structure/views/add-template).

I lucked out that after I deleted the original view, I could save the new view with the same name; thus most of my CSS was not affected.

KarenS’s picture

Status: Active » Fixed

That is the right solution. I had to create some new calendar components that work better than the old ones did and it resulted in deprecating some old ones. Creating a new view will make everything work.

polskikrol’s picture

Status: Fixed » Active

I see 9 different templates to pick from... which one is the correct one to retain original functionality?

Also, any reason why such a drastic change did not have database schema changes to make the old view compatible ?

Lostboy22’s picture

A message with the "Release Notes" explaining calendar views must be recreated would be nice.

metakel’s picture

Priority: Normal » Major

I have tried exporting the view-> import it again.
However it does not work. Should I need to rebuilt the view from scratch?
My previous views were quite complicated. I am afraid it is not that easy to do so.
Now I have downgraded to use version 7.3.

Simon Georges’s picture

@polskikrol, each template is actually the same, but targetting a different date field, so choose the one regarding the date field you want to use for your calendar.

carlnewton’s picture

Thanks guys, that's the solution. More specifically, these are the steps I took:

1. Go to admin/structure/views
2. In the list of views, find the Calendar view
3. Under the Operations column, click Delete
4. From the same page, click 'Add view from template'
5. Select whichever view matches your field name (can be found under admin/structure/types/manage/[event node type]/fields)
6. Ensure you save the view

kylebcooke’s picture

For anyone not wanting to re-create their calendar views the following can be done.

  1. Export your current calendar view
  2. Insert the code below at the end of section /* Display: Master */, probably under line $handler->display->display_options['style_options']['max_items'] = '0';


    $handler->display->display_options['row_plugin'] = 'calendar_entity';


  3. Re-import your view and select Replace an existing view if one exists with the same name.
  4. Click Save and voila!

Hope this helps!

manicato’s picture

I get the following error when I try to rebuild the view with a template:

Fatal error: Call to a member function summary_title() on a non-object in /www/sites/all/modules/views/plugins/views_plugin_display.inc on line 1127

Original View disappeared but no new is created.

metakel’s picture

#11's solution restores the calendar at the Month page. However, it does not work on all other display: year page, week page, and the month block.

nasinandes’s picture

Great!! I follow the #11 steps and its works again.
Thanks!!

KarenS’s picture

Status: Active » Fixed

The solution is to create a new view. There is no way to 'change the schema' of an existing view automatically, so there is no way for the code to do this automatically.

hynnot’s picture

+1 #10 #15
It's necessary to delete the view and create it new.

NowThatsCookin.Com’s picture

#10 worked for me with one exception. I did not have the ability to "delete" it, but instead disabled it.

Got it to working now, thanks for the help!!

Frank

Ole Martin’s picture

For me it was #10 who fix my problem.
Thanks!

rv0’s picture

cries..

as KarenS says in #5, recreating all your views is the only "stable" solution

I can't help but wonder why a simple module update can become such a pain and it is not mentioned anywhere in the release notes? Don't we care for some little backwards compatibilty? How about deprecating stuff instead of deleting it?

For me this means hours of work recreating all the views, and lots of chances to make mistakes in doing so :( It is a rather complex site and I use calendar functionality in many places.
Luckily I didn't take any chances and used a testserver first..

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

einarps’s picture

For me it was #10 - thank you.

TechNikh’s picture

I Exported the view, removed the code related to /* Display: Week */(This display was causing problem to me and I don't need it)
imported the view code with "Replace an existing view if one exists with the same name" and "Bypass view validation"

kingfisher64’s picture

Status: Closed (fixed) » Active
'calendar_plugin_style: The calendar row plugin is required when using the calendar style, but it is missing.'

in calendar_plugin_style->render() (line 228 of C:\wamp\www\sitename\sites\all\modules\calendar\includes\calendar_plugin_style.inc).

I've read the fixes for this however wouldn't it make more sense then to remove the calendar views by default if you have to delete it and re-create them? Seems very strange to leave something installed that basically needs deleting straight away.

Can these views be removed and instructions on how to create them be included in the readme.txt file instead?

Thank you

kingfisher64’s picture

Added to previous comment there's no way to delete the broken views. There's only a disable option in the dropdown. Clicking on edit to go into the view then normally click the delete view just outputs the following in the view.

( ! ) Fatal error: Call to a member function summary_title() on a non-object in C:\wamp\www\sitename\sites\all\modules\views\plugins\views_plugin_display.inc on line 1192

This has also broken http://drupal.org/project/events_calendar_feature.

_vid’s picture

@kylebcooke that is fantastic! Thanks much.

I had the WSOD with this error:

PHP Fatal error:  Call to a member function summary_title() on a non-object in ...sites/all/modules/views/plugins/views_plugin_display.inc on line 1192

I followed your advice and made some other changes and my calendar views are back!

Here are my complete steps:

  1. Log in as user 1. This is necessary to use views import.
  2. Navigate to the views list screen:
    /admin/structure/views

    .

  3. Export your 'Calendar' view
  4. Edit your exported code adding this line
    $handler->display->display_options['row_plugin'] = 'calendar_entity';
    just below the last
    $handler->display->display_options['style_options']...

    in the /* Display: Master */ before any field declarations like: /* Field: Content: Title */.

  5. Scan your code for other occurrences of
    ['row_plugin']

    I found that I had one for each display:

    $handler->display->display_options['defaults']['row_plugin'] = FALSE;
  6. Change all occurrences of
    $handler->display->display_options['defaults']['row_plugin'] = FALSE;
    to
    $handler->display->display_options['defaults']['row_plugin'] = TRUE;
    unless you have a display that already has a
    $handler->display->display_options['row_plugin']

    entry.
    In that case leave it false. Ex:

    /*no change*/
    $handler->display->display_options['defaults']['row_plugin'] = FALSE;
    $handler->display->display_options['row_plugin'] = 'fields';

    @metakel: This may help your issue

  7. Prior to importing
    • If you have any calendar block displays, open those blocks to capture the settings. As those will be lost after re-importing the view.
      Block notes:
      • Because I had block displays, there was a MySQL conflict when saving the imported view; an entry for each block already existed in the DB.
        I noticed the error when running $ drush cc all.
      • So I also changed my block's machine names in the export code; incrementing their numbers, starting at a 1+ the highest #
        Ex: I had 2 blocks (block_1, block_2) and the highest number was 2 so
        $handler = $view->new_display('block', 'Upcoming', 'block_1');
        became
        $handler = $view->new_display('block', 'Upcoming', 'block_3');
        and
        $handler = $view->new_display('block', 'Upcoming', 'block_2');
        became
        $handler = $view->new_display('block', 'Upcoming', 'block_4');
        Perhaps I could have avoided this by using some combination of cache clearing and db updating but the damage was done and this fixed it.
      • In any case, that meant that I needed to set up my blocks again after import.
  8. Import the view with the same name as the original: "Calendar" (check the box: 'Replace an existing view if one exists with the same name')
  9. Save the view
  10. Optional steps (these may not be necessary)

  11. Clear the views cache and the site cache
    $ drush cc all
  12. Update the DB
    $ drush updb
  13. View your calendar

Now my calendars are back and I don't have any php errors.

@KarenS; Could something like this be done programmatically?

hebbar10’s picture

Thanks vid (#25), it worked for me.

ppatnaik’s picture

Hurray I solved the issue.

I was stuck at this issue for a long time.
Then I solved the issue.

Solution :
The Events Calender view that gets generated automatically is having some default settings.
And It happens many time that You don't have all the same in your site.

step 1 : delete or Disable the View : Events Calender
step 2: Create a new view using : create View using Template.
step 3:SELECT CALENDER AND THE DATE FIELD THAT YOU WANT THE VIEW TO BE TRACKED ON.
step 4 : allocate your view to specific block and enjoy the special calender features of your website.

webdrips’s picture

Thanks @_vid, #25 worked!

Note to avoid step #7, I simply deleted the calendar view prior to re-importing it.

_vid’s picture

Great. Glad it's working for others. @webdrips; thanks for the tip on Step #7.

danielbeeke’s picture

Thanks all, #25 fixed it for me!

Thambos’s picture

Thanks #25!

I was wondering with your fix in Step 7 with the blocks though, does that cause any sort of problems? I've had to do the same thing in order to still access our Blocks list, and so I'm hoping it doesn't cause any other problems.

_vid’s picture

@Thambos, I haven't seen any problems arise from Step 7. You're essentially creating a new view, so you just have to be dilligent with the block numbering.
If you do have problems you can always create a new calendar from a template and then delete the broken displays / view.

DamienMcKenna’s picture

Issue summary: View changes
DamienMcKenna’s picture

Version: 7.x-3.4 » 7.x-3.x-dev

FYI I'm still running into this problem after creating a view from a template.

DamienMcKenna’s picture

In my scenario I'm using a view created from a view template, but it's still showing the following error:
Warning: Creating default object from empty value in calendar_plugin_row->pre_render() (line 312 of calendar/includes/calendar_plugin_row.inc).

DamienMcKenna’s picture

Interestingly enough, the problem only happened when display the "Upcoming" block, the regular mini calendar block didn't cause problems.

Incidentally, the block was taking almost a minute to render (as reported by Panels Why So Slow) and was using about 560mb to render the page (as reported by Devel). With the block disabled, the entire page rendered in a few seconds and the max memory limit was 34mb.

I think part of the problem might have been triggered by Panels / Panels Everywhere. I was using PE to render the Upcoming block and originally the summary for the pane was saying "Using display" whereas it should have said "Using display Upcoming". I removed the block from the PE display and re-added it, at which point the pane summary finally had the correct label and the memory usage was back to normal. So there may be scenarios triggering this problem.

qmjeelani’s picture

Comment #10 works for me

kingfisher64’s picture

recreating the view from template works quickly, however there is still no way to delete the view. I just disabled it. https://www.drupal.org/project/event_calendar was what I was using.

qasimzee’s picture

#10 should be added in README.txt

Neslee Canil Pinto’s picture

Status: Active » Closed (outdated)