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!
Comment | File | Size | Author |
---|---|---|---|
#33 | calendar-taxonomy_label_relationship-1614566-33.patch | 1.29 KB | ron_s |
#32 | taxonomy_setting_won_t-1614566-32.patch | 2.63 KB | rcodina |
#3 | Taxonomy_vocab_missing.jpg | 91.35 KB | rsgracey |
Comments
Comment #1
johnvIt will work if you add the taxonomy fields themselves, not via the relationship.
Comment #2
kscott22 CreditAttribution: kscott22 commentedThanks 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!
Comment #3
rsgracey CreditAttribution: rsgracey commentedYes, 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--
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...
Comment #4
johnv@rsgracey, what happens if you create the view again? You can use the template views for that.
Comment #5
rsgracey CreditAttribution: rsgracey commentedWell, 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:
As I say, this seems to be working for me so far.
Comment #6
rsgracey CreditAttribution: rsgracey commentedActually, this hasn't really worked. Somewhere in the process, the taxonomy term disappeared again from all the displays.
I'm really hoping two things:
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.
Comment #7
johnvTry out the Legend block. It has a new setting 'take legend from display X'.
Comment #8
rsgracey CreditAttribution: rsgracey commentedYes. 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.
Comment #9
johnvWell, 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.
Comment #10
rsgracey CreditAttribution: rsgracey commentedI 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--
Comment #11
rsgracey CreditAttribution: rsgracey commentedIn 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.
Comment #12
johnvIf 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.
Comment #13
rsgracey CreditAttribution: rsgracey commentedI'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.
Comment #14
salateenoo CreditAttribution: salateenoo commented@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 ?
Comment #15
TelFiRE CreditAttribution: TelFiRE commentedWhat are you talking about? It's impossible to add the term without adding a relationship....
Comment #16
blackspiraldancer CreditAttribution: blackspiraldancer commentedI'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.
Comment #17
blackspiraldancer CreditAttribution: blackspiraldancer commentedI 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.
Comment #18
blackspiraldancer CreditAttribution: blackspiraldancer commentedI'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.
Comment #19
ToRum CreditAttribution: ToRum commentedI got the same issue. Renaming the machine name for the default view from "
my_custom_machine_name
" to "page_1
" fixes the problem.Comment #20
humanaut CreditAttribution: humanaut commentedI can confirm the above comment fixes this issue.
Comment #21
star-szrIn 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:
Comment #22
star-szrUploaded 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 :)
Comment #23
Jumoke CreditAttribution: Jumoke commentedHi 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.
Comment #24
pobster CreditAttribution: pobster commentedWouldn'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
Comment #25
Sata CreditAttribution: Sata commentedFatal 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:
Comment #26
peterx CreditAttribution: peterx commentedI have this error on master display. I did the following.
Comment #27
rcodina CreditAttribution: rcodina commentedI 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!
Comment #28
rcodina CreditAttribution: rcodina commentedThis is the same patch by @Sata on #25 but in file format ;)
Comment #29
rcodina CreditAttribution: rcodina commentedComment #30
Michael_Lessard_micles.biz CreditAttribution: Michael_Lessard_micles.biz commentedBack 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.
Comment #31
rcodina CreditAttribution: rcodina commentedPatch on #28 only fixes colors by content type. Taxonomy colors still fail.
Comment #32
rcodina CreditAttribution: rcodina commentedI 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!
Comment #33
ron_s CreditAttribution: ron_s commentedPatch #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 incalendar-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/2581039Also 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.
Comment #34
Christopher Riley CreditAttribution: Christopher Riley commentedPatch 33 works just fine and dandy for me other than a trailing garbage warning.
Comment #35
ron_s CreditAttribution: ron_s commentedDo you mean a warning message until you saved your changes?
Comment #36
Neslee Canil PintoComment #37
ron_s CreditAttribution: ron_s commentedThis 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.
Comment #39
Neslee Canil Pinto