votingapi_views.inc included in wrong place
raintonr - November 5, 2007 - 00:09
| Project: | Voting API |
| Version: | 5.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | patch (reviewed & tested by the community) |
Description
There is some odd interaction between views.module and votingapi.module.
This is discussed here:
I traced this to the fact that the votingapi_views.inc file is not always included and therefore the options it adds disappear after some time.
The enclosed patch moves the include from within votingapi_menu which is working on our sites.
| Attachment | Size |
|---|---|
| votingapi.module.patch | 895 bytes |
#1
Brilliant! This appears to have fixed my problem. Muchos gracias.
#2
Thaks it help me too.
When i use calendar module and voting api - after adding new node - calendar rebuild views and voting api crashes.
After using this patch - everything seems to be ok
#3
This is excellent! Views integration works perfectly with this applied.
This should also solve this issue.
Patch applies to 5-dev with fuzz.
#4
+1 for this patch. Just manually applied it, and the missing-fields-in-Views problem went away (so far...)
#5
+1, works for me too.
#6
Will this patch be committed to an update in the voting.api?
I ussually download the updates from update status.
I don't know how to apply patches yet.
Antonio
#7
I have tried the patch, but the problem persists: I am creating a views which should display the teasers according to the timestamp of the last vote cast. The problem is that it duplicate posts, for some reason. The problem can be observed here:
http://redehumanizasus.net/apagueme
Does someone have any other suggestion on how this could be solved? Thank you!
#8
Duplicates? Sorry, dani, but I'd imagine your issue is unrelated. What is the export of this view?
#9
Let's bump this to critical. It does translate into erratic behaviors that is nasty to track down.
The preferred way around contrib seems to be through hook_init() (see OG, CCK...)
<?php
function votinapi_init() {
// only bother when we are not serving a cached page. check for which function that only exists afterwards
if (function_exists('drupal_set_content')) {
if (module_exists('views')) {
include_once(drupal_get_path('module', 'votingapi') .'/votingapi_views.inc');
}
}
}
?>
I'm can't roll a patch just right now, will do asap
#10
subscribing
#11
The include() call was migrated to hook_init() some time ago, but I just noticed that an official D5 release was never rolled for that fix. Thus, the dev version of votingapi had the change but not the official version. I'll double check that there are no other problems in the dev release as it currently stands, and roll an 'official' release.
#12
That would be great...thanks Eaton!
#13
I do not believe using _init is safe.
I am having the same issue with og_views.inc disappearing and corrupting my views cache. i.e., it works for a week, then og_views.inc disappears while the views cache updates, causing OG nodes to spill everywhere. It's a horrible mess.
The only way either VotingAPI Views or OG Views has consistently worked for me is including outside of a function completely.
I believe the culprit is the assumption that we do not want to include that file if serving cached pages. This is incorrect as it seems the views cache still may update while serving a cached page.
The first patch in the initial bug works perfectly for me.
My related OG issue: http://drupal.org/node/245436
#14
fysa - i cannot believe your hypothesis. what would be invalidating the cache during a cached page view? views.module does not even load since it does not implement hook_exit() or hook_init(). so it would have to be quite a rogue module that wipes cache in this instance.
fysa - you are running votingapi and views on same site? it only takes one rogue module to screw up the views table building. i suspect that rogue module is right here - votingapi. and hopefully eaton will commit soon to fix it. this votingapi problem is currently affecting groups.drupal.org.
#15
@eaton - yched's code in #9 better than what is in DRUPAL-5 votingapi. your code unnecessarily parses the votingapi views file even on cached pages. the check for drupal_set_content() avoids that. not a big deal though.
#16
Rerolled patch that includes the votingapi_init() function in #9. Please review.
#17
Let's try that again. If this doesn't work I'll remember not to use Safari to upload patches.
#18
I applied this patch (#16) and it seems to be working.
#19
like, I said, seems to be working.
#20
I am not so sure this is working. I patched my votingapi.module, go to the Views page and I still do not see any VotingAPI choices in the filters or any other drop downs.
#21
I had the problem described over at #168282: Views fields appear and disappear, where I was getting the "Unknown column 'votingapi_cache_vote_percent_average.value'" message.
I applied the patch and it didn't immediately solve the problem. So I went into the view and removed the voting API field, and it's working now.
#22
My issue is that I don't have a view to remove and recreate. I am just trying to create a view from scratch, and there are no ( under fields) entires for VotingAPI at all.
#23
How do you install the patch? I'm guessing you add it to one of the files in the voting api module, I would appreciate if someone could confirm which file and do I just add it in at the top? Thanks
#24
http://drupal.org/patch/apply
#25
When the latest release came out, I manually removed the VotingAPI directory, and installed fresh. Enabled the module, went to Views and the VotingAPI items have returned. Imported the saved View I had exported when this all started and it appears to work okay.
Should we mark this as fixed then?
#26
Sorry for the silence on the issue for the past x weeks -- I've been juggling quite a bit of random unrelated stuff, and I wanted to ensure that the dev version DID in fact fix what I thought it fixed before rolling it out to an official release.
I believe that the patch that made it to VotingAPI 1.6 did in fact solve this issue, but before marking it fixed I'd like to let it sit for a moment and make sure that nothing's been missed. Let's call this one "probably fixed, and being watched closely..."
#27
Sounds good to me. This issue was driving me crazy because I had thought I was doing something wrong. I'll report any issues I see.
#28
HI,
Remember to empty your cache. That was a temporary solution for me. The latest update fixed my problems, thanks.
Great Work.
Thank you.
Antonio
#29
Not sure if this applies, but I was running fine on 5.x-1.5 Voting API, I upgraded to 1.6 and bam! VoteingAPI was no where to be found in Views. I emptied every cached table I could find. Nothing I could do seemed to make VoteAPI show up for Views.
1.6 seems to have the opposite affect than the rest here. I was fine on 1.5. I've restored from backups to the 1.5 version and everything is fine now.
URL in particular
http://www.wildpaddle.com/bwca-campsites
Thanks for the great module.
-Shane
#30
Re-rolled against latest DRUPAL-5.