Trying to get property of non-object in calendar_plugin_row->options_submit() (line 262)

I can't replicate this problem, but I can see that in theory there might be a way to have no value for 'link_display'. The master display has no path, so we can't use that. I guess we can check for the existence of 'link_display' and just do nothing if it's missing.

Here's what I committed. See if you get any more errors after that. I can't test it because I can't find any way to get this error.

http://drupalcode.org/project/calendar.git/commit/b84c870

This comes into play only if you chose the option to link a calendar to a content type. If you choose that option, you get an 'Add Event' (or whatever the name of the content type is) action link on the calendar and a corresponding 'Calendar' link on the node. The default_link tells us the path of the default display of the calendar, which is what we want to link back to. If you build a calendar using the template, the month is the default display.

This bit of code is checking to see if that option is chosen, and if so store the choice in a variable. The variable is used to add the 'Calendar' link to the node in node_view().

Coming from #1614566: Taxonomy label empty when using field via relationship.

I can reproduce this by following these steps:

1. Clean install of Drupal 7 (7.23 dev version).
2. Install latest 7.x-3.x-dev version of Calendar, 7.x-2.x-dev version of Date module, Views 7.x-3.7
3. Add new Calendar view based on the 'created' field in the 'node' base table.
4. Change the machine name of the Month view.
5. Save the view.
6. Save the row settings (Calendar Entities | Settings) on the default view, resulting in an error:
   

   An AJAX HTTP error occurred.
   HTTP Result Code: 200
   Debugging information follows.
   Path: http://d7.dev/admin/structure/views/ajax/display/calendar/foo_bar/row_options
   StatusText: OK
   ResponseText: 
   Fatal error:  Call to a member function get_option() on a non-object in sites/all/modules/calendar/includes/calendar_plugin_row.inc on line 263

Attached patch adds another condition and prevents the 500 errors. When the machine name of the default view is changed the link display does not get updated and needs to be re-saved to restore the link to the default display:

I can confirm that #6 appears to fix this issue here. (Using Calendar 7.x-3.4+1-dev and Views 7.x-3.7+22-dev.). However, before patching I was experiencing the issue even when using the default machine names.

I can confirm that the patch in #6 works. Using latest versions at this time (Calendar 7.x-3.5, Views 7.x-3.8, Drupal 7.32). It's a pitty you didn't include this patch into the 3.5 update that was published just a couple of days ago.

I think you should commit it and publish a fast 3.6 update, because this bug breaks functionality.

I can also confirm the patch in #6 works as expected. No more 500 errors when attempting to edit the legend colors associated with a taxonomy term field. Using the same configuration as gonssal, except with Drupal 7.34.

We came across this issue on some sites we maintain here at the US Courts. We did a $view = views_get_view('our_view_machine_name') and inspected the view. We discovered that the value of $view->display['default']->display_options['link_display'] is 'page_1.' That's the machine name for one of the default views displays, but we had deleted the 'page_1' display.

So we went to the view and added a page display named 'page_1' at a /foo/bar/baz nonsense path and disabled it. Now the plugin code finds a page display called 'page_1' and we no longer get the ajax error.

I'm not sure why the view's default values reference a display that no longer exists. This particular plugin might be blameless: perhaps some other part of the views system should have changed the default value when we deleted the 'page_1' display.

Nevertheless, it seems to be the case that sometimes a view's defaults reference a display that does not exist, so I still think the patch to check for its existence is a good idea and should be incorporated into the module.

Thanks kmcculloch . I can confirm your #10 work around.

This patch is not outdated. It is a reproducible problem, and the solution is still valid and effective.

I'm marking patch #6 as reviewed and ready to be committed. It still applies to the latest 7.x-3.x-dev.