I've looked everywhere for this, and I'm stumped.

BACKGROUND:
I'm working with the newest release of all modules, including Calendar 7.x-3.4. Every patch I've found has already been committed in this version.

ISSUE:
I created a new calendar, using the preset template, and under Row Style Options: Legend Colors, I selected "Based on Taxonomy." My taxonomy terms aren't listed, so I'm unable to assign them colors (when I select "based on Content Type," the ability to set colors works fine).

ATTEMPTED FIXES:
I've added the relationship "Content: Taxonomy Terms on Node" and have added every term field to the fields. I've also displayed each term field as a link. Still, the ability to set the term colors doesn't appear.

I'm hoping I missed something really simple, as it doesn't appear anyone else is having this problem. But I've been struggling with it for several hours now. I'd appreciate any help. Thanks!

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

johnv’s picture

Status: Active » Fixed

It will work if you add the taxonomy fields themselves, not via the relationship.

kscott22’s picture

Thanks for the reply, johnv!

I removed the relationship and added "Content: All taxonomy terms" to the fields, but that didn't work.
I had to add "Content: (vocabulary name)" to the fields to be able to set the color stripes.

Sorry for missing something so simple. I appreciate the nudge!

rsgracey’s picture

Status: Fixed » Active
FileSize
91.35 KB

Yes, but there's still some catch. I had this working, and now it isn't. I still see the colors that I set before upgrading (so they exist in the database somewhere), but the drop-down where I would set the vocabulary now is empty, so that I can't change the colors.

I think I remember a patch before to fix this. Was that also wrapped into the newest version?

An addendum: When I try to save the settings, I get this error--


An AJAX HTTP error occurred.
HTTP Result Code: 200
Debugging information follows.
Path: http://outrea/.../admin/structure/views/ajax/display/calendar_4/speech_calendar_month/row_options
StatusText: OK
ResponseText: 
Fatal error:  Call to a member function get_option() on a non-object in C:\Documents and Settings\d1rsg01\Sites\outreach-dev\sites\all\modules\calendar\includes\calendar_plugin_row.inc on line 263

I'm thinking that it may have something to do with the sequencing of "All Displays" and overridden ones. Will report back in a bit...

johnv’s picture

@rsgracey, what happens if you create the view again? You can use the template views for that.

rsgracey’s picture

Well, I tried that several times, and the problem still occurred. Now, I've found the Views settings, and I've checked "always show master" or whatever it is. I am right now building another view from the master up, one careful step at a time, and it seems to be working. I will check back in if it doesn't succeed.

Summary:

  1. Make sure the master display is visible, from the Views settings, and turn off the Views caching.
  2. Create a new calendar view from the template on the correct date field.
  3. Work on the master display first, making sure that you have selected "Apply to All Displays" for every change.
  4. Add the taxonomy field to the "Fields" section.
  5. Just above the Fields section, click the "settings" link in the "Show: Calendar Entities | Settings" links, and set up the striping colors, selecting the taxonomy field. Apply these settings to all displays.
  6. Here's the tricky part: Work through the month, week, and day displays. (Doing the striping for "year" doesn't make any sense.)
  7. For each display, click the "settings" link in "Show: Calendar Entities | Settings," and select in the first drop-down, "Revert to default," and click the "revert" button.

As I say, this seems to be working for me so far.

rsgracey’s picture

Actually, this hasn't really worked. Somewhere in the process, the taxonomy term disappeared again from all the displays.

I'm really hoping two things:

  1. I don't have to set this all up again.
  2. I don't have to set each striping scheme in each display redundantly.

For now, I've accomplished my initial goal, which was to change my colors, but I can't change them again, at this point, without recreating the whole view.

Argh.

johnv’s picture

Try out the Legend block. It has a new setting 'take legend from display X'.

rsgracey’s picture

Yes. Oddly, only two of the displays appear, and neither should have the striped rows.

There is clearly something I'm not understanding about this situation.

johnv’s picture

Well, IMO it should work as you do in #5, without steps 6 and 7. Do step 3 with the 'default display', which is NOT master, but the next-first display in the line.
Then, add the Legend block and set the default display.

rsgracey’s picture

I think we're confusing content type "displays" and views "displays." In Views, you can work on the "master," while in content types, you work on the "default."

Anyway. Here's the update.
I removed all calendar views from my features.
I deleted the Calendar module.
I deleted all my "views in code."
I cleaned out the database tables--all the leftover displays from the calendar views.

I reinstalled the Calendar module.
I recreated my view.

I get exactly the same result. And I can't even figure out at which step of configuring the view displays the taxonomy field disappears from the striping configuration.

I'm now going to try to "jury-rig" the whole thing from the code side, though I am not a coder. I'm hopeful that someone will be able to figure out where the bug is in this tool.

Thanks--

rsgracey’s picture

In the end (I think), I just commented out line 263 from the "calendar_plugin_row.inc" until I got the colors set up. The taxonomy term was still missing, but at least I didn't get the AJAX error.

$path = $this->view->display[$default_display]->handler->get_option('path');
johnv’s picture

I think we're confusing content type "displays" and views "displays." In Views, you can work on the "master," while in content types, you work on the "default."

If you look at the line queoted in #11, you see '$default_display', this is the 'default' views display, and it is the first one in the row, (or second if master is enabled)

One other thing. Are you working with nodes, or Entities? There are some issues/patches regarding Entities not working.

rsgracey’s picture

I'm working with nodes. I'm trying to create a calendar of events, only one content type ("engagement"), including a vocabulary of "status."

Whenever I try to create a new, clean calendar view with these fields, even after clearing caches, etc., and I open the row options on the Master display, even when it says "None," as soon as I pick the taxonomy option, the vocabulary select is empty, but the correct terms are already listed, and I can't save the options. I get the error above.

These options are saved somewhere, and I can't seem to clear them to start over, without reinstalling the module, etc.

salateenoo’s picture

@johnV:

what if my view requires a relationship to be able to add the term as a field , it worked with me with no relationship , but i need it to work with relations, any work around ?

TelFiRE’s picture

What are you talking about? It's impossible to add the term without adding a relationship....

blackspiraldancer’s picture

I've been able to get the referring term using a label in the field (previously I didn't enter one cause I didn't need it).
Still stuck on the error, anyway - the HTTP error code for me is 500, I tried disabling JS in Views and still the error is the same.

blackspiraldancer’s picture

I have an exported copy of a calendar that had a correct color-taxonomy term matching. Then - somehow - it screwed up and now I can't even change a setting under calendar entities settings.

Re-importing the old saved working view shows that it still behaves correctly - I tried reproducing the problem, it all starts after changing the machine name of the (in my case) page. I don't know if I've been clear enough, I'll try to get some screenshots and/or a complete reproduction of the issue.

blackspiraldancer’s picture

I've also noticed something unclear looking at mysql table views_display while messing with views. After setting under calendar entities settings, stripes, no color, the display_option isn't updated accordingly.
So, after that, if I try to rename the page's machine name or remove from the fields the taxonomy term I get a nasty error 500 whenever I try to change *any* of the calendar entities settings.

ToRum’s picture

I got the same issue. Renaming the machine name for the default view from "my_custom_machine_name" to "page_1" fixes the problem.

humanaut’s picture

I can confirm the above comment fixes this issue.

star-szr’s picture

In addition to #19, we found that editing the 'Block' display and ensuring 'Link display' (under Advanced > Other) was set to the main page display fixed this and allows you to change the view machine name to something other than page_1. When initially editing the 'Link display' none of the radio buttons were selected. I'm not sure how updating the legend colours ties into the link display but it worked for us.

Found this by searching in the Calendar code for page_1 and seeing this:

$handler->display->display_options['link_display'] = 'page_1';
star-szr’s picture

Uploaded a patch over at #1545240-6: Trying to get property of non-object in calendar_plugin_row->options_submit() (line 262) that will prevent the 500 errors. Reviews and testing would be much appreciated :)

Jumoke’s picture

Hi all, so have anyone been able to get the color legends to show up based on their taxonomy terms? If so, please tell me how. Not working for me.

pobster’s picture

Wouldn't setting it to: $default_display = $this->view->display['default']->display_options['current_display']; be better? Then you get the machine name of your current display (obviously change both this and the 'if' statement as well).

Thanks,

Pobster

Sata’s picture

Issue summary: View changes

Fatal error: Call to a member function get_option() on a non-object in C:\Documents and Settings\d1rsg01\Sites\outreach-dev\sites\all\modules\calendar\includes\calendar_plugin_row.inc on line 263
...

I was getting this error yesterday and added this modification to line 263 of calendar/includes/calendar_plugin_row.inc -- problem resolved.

patch:

diff --git a/includes/calendar_plugin_row.inc b/includes/calendar_plugin_row.inc
index f728d18..b929fbe 100644
--- a/includes/calendar_plugin_row.inc
+++ b/includes/calendar_plugin_row.inc
@@ -260,7 +260,9 @@
     if ($this->view->base_table == 'node') {
       if (isset($this->view->display['default']->display_options['link_display'])) {
         $default_display = $this->view->display['default']->display_options['link_display'];
-        $path = $this->view->display[$default_display]->handler->get_option('path');
+	if (isset($this->view->display[$default_display]->handler)){
+          $path = $this->view->display[$default_display]->handler->get_option('path');
+        }
         // If this display has been set up as a default tab, the current path
         // is actually the base path, i.e. if the path is 'calendar/month'
         // and this is a default tab, the path for this display will actually
peterx’s picture

I have this error on master display. I did the following.

  1. Added a page
  2. Set the page path
  3. Saved the query
  4. Set set the colours for all displays based on content type
  5. Saved the query
  6. Deleted the page
rcodina’s picture

I use color setting per content type and I found the same error than all of you. I just manually applied patch on #25 and it worked for me! Thanks!

rcodina’s picture

This is the same patch by @Sata on #25 but in file format ;)

rcodina’s picture

Status: Active » Needs review
Michael_Lessard_micles.biz’s picture

Back to the issue "Won't Allow Color Choice".

I had the issue with the Calendar version for August 2015, but I found the solution.

Under Fields in the View, I was using Taxonomy all.

I switched to the field that is only the vocabulary that works for the relevant content type for my events. Fixed.

rcodina’s picture

Status: Needs review » Needs work

Patch on #28 only fixes colors by content type. Taxonomy colors still fail.

rcodina’s picture

Status: Needs work » Needs review
FileSize
2.63 KB

I attach a patch which fixes taxonomy colors: now the selectbox gets populated. This patch also includes suggestions made by @Sata on #25. Please, review it!

ron_s’s picture

Title: Taxonomy Setting Won't Allow Color Choice » Taxonomy label empty when using field via relationship
Version: 7.x-3.4 » 7.x-3.x-dev
Category: Support request » Bug report
FileSize
1.29 KB

Patch #32 has three issues:

1) The patch code in options_submit attempts to fix code that @Cottser already added as part of his patch referenced in comment #22 (#1545240-6: Trying to get property of non-object in calendar_plugin_row->options_submit() (line 262)). Everyone should be using/testing that patch as a first step. If you think @Cottser's patch does not work correctly for content types, please modify his patch and add it to #1545240. We've been using his patch #6 on a live site for the past year with no issues.

2) The label displayed in the options_form for taxonomy terms should be the actual name, not the field name. This is how it is rendered when a label is available for use. I've created a new patch for review.

3) I understand wanting to clean up the calendar-mini.tpl.php code, but when things like this are identified, please create a new issue. The Calendar module is big, and it's hard enough to get even small patches reviewed and approved. We don't need to make it more difficult by trying to resolve multiple issues in one package. Also you've only made a couple of fixes in calendar-mini, yet those same problems exist in all the template files. I've created a patch that is more comprehensive: https://www.drupal.org/node/2581039

Also as a general comment, this issue has to do with using a taxonomy field that is accessed via a relationship, and needs to be displayed with stripes/legend. I've not found that it is a problem when the field is directly accessed.

Please review the attached patch. Thanks.

Christopher Riley’s picture

Patch 33 works just fine and dandy for me other than a trailing garbage warning.

ron_s’s picture

other than a trailing garbage warning

Do you mean a warning message until you saved your changes?

Neslee Canil Pinto’s picture

Status: Needs review » Closed (outdated)
ron_s’s picture

Status: Closed (outdated) » Needs review

This is still a valid patch and needs review. We have been using this successfully on numerous sites. It still applies cleanly to the latest 7.x-3.x-dev version.

Neslee Canil Pinto’s picture

Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

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