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:needs work
Description

There is some odd interaction between views.module and votingapi.module.

This is discussed here:

http://drupal.org/node/175289

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.

AttachmentSize
votingapi.module.patch895 bytes

#1

Matthew Davidson - January 15, 2008 - 03:31

Brilliant! This appears to have fixed my problem. Muchos gracias.

#2

Eugef - January 18, 2008 - 14:34

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

blackdog - February 13, 2008 - 11:05
Version:5.x-1.5» 5.x-1.x-dev
Status:needs review» reviewed & tested by the community

This is excellent! Views integration works perfectly with this applied.

This should also solve this issue.

Patch applies to 5-dev with fuzz.

#4

dnorman - February 15, 2008 - 20:50

+1 for this patch. Just manually applied it, and the missing-fields-in-Views problem went away (so far...)

#5

sethcohn - February 20, 2008 - 20:35

+1, works for me too.

#6

vitovonantwon - March 13, 2008 - 18:18

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

dani matielo - March 19, 2008 - 23:51

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

raintonr - March 20, 2008 - 02:49

Duplicates? Sorry, dani, but I'd imagine your issue is unrelated. What is the export of this view?

#9

yched - March 21, 2008 - 10:40
Priority:normal» critical

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

tj2653 - April 10, 2008 - 06:06

subscribing

#11

eaton - April 10, 2008 - 06:41

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

tj2653 - April 10, 2008 - 15:05

That would be great...thanks Eaton!

#13

fysa - April 11, 2008 - 14:04

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

moshe weitzman - April 11, 2008 - 15:30

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

moshe weitzman - April 13, 2008 - 11:02

@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

christefano - April 23, 2008 - 04:44
Status:reviewed & tested by the community» needs review

Rerolled patch that includes the votingapi_init() function in #9. Please review.

#17

christefano - April 23, 2008 - 04:46

Let's try that again. If this doesn't work I'll remember not to use Safari to upload patches.

AttachmentSize
189311_votingapi_init.patch 933 bytes

#18

bflora - April 23, 2008 - 05:01

I applied this patch (#16) and it seems to be working.

#19

bflora - April 23, 2008 - 05:05
Status:needs review» reviewed & tested by the community

like, I said, seems to be working.

#20

spatz4000 - April 28, 2008 - 18:04

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

Mark Theunissen - April 30, 2008 - 09:08

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

spatz4000 - April 30, 2008 - 13:11

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

siliconvalley1 - May 1, 2008 - 05:27

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

spatz4000 - May 1, 2008 - 12:57

#25

spatz4000 - May 1, 2008 - 13:48

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

eaton - May 1, 2008 - 15:45

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

spatz4000 - May 1, 2008 - 16:00

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

vitovonantwon - May 6, 2008 - 12:44

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

nvoyageur - May 27, 2008 - 03:59

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

sun - July 1, 2008 - 17:30

Re-rolled against latest DRUPAL-5.

AttachmentSize
votingapi-DRUPAL-5.views_.inc_.patch 739 bytes

#31

recidive - November 27, 2008 - 15:36
Status:reviewed & tested by the community» needs work

I have a problem, I think is related with this issue.

I have a view with 'Node: sticky' and 'VotingAPI percent vote result (average)' sorting criteria. After some time (can't yet identify what really happen), I start getting the following error, and the view appear empty:

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near &#039;DESC LIMIT 0, 15&#039; at line 1 query: SELECT node.nid, node.sticky AS node_sticky, value FROM node node WHERE (node.status = &#039;1&#039;) AND (node.type IN (&#039;mobileapp&#039;)) ORDER BY node_sticky DESC, DESC LIMIT 0

If you look at the error, what is missing is the votingapi sort criteria ORDER BY node_sticky DESC, DESC LIMIT 0, it only add DESC not the field it should sort by, hence the error.

When I go to edit the view, the votingapi sort criteria is there, but it's properties are all blank, then I have to remove it to make the view work. Then edit the content type I have setup voting and submit to make the sorting criteria appear as one of the options.

The above patch didn't solve the problem problem.

I'm using views 5.x-1.6 and votingapi 5.x-1.6.

#32

sun - November 27, 2008 - 15:55

We experienced similar SQL errors in Translatable module, when it included its Views include file in hook_menu() only. Views seems to rebuild its cache under certain (yet unknown) conditions in which other modules do not include their Views include files. The only working solution for Translatable was to move the module_exists/require_once code into the global scope, so it is loaded on all page requests if Views is available, regardless of the bootstrap phase.

#33

torgosPizza - March 25, 2009 - 03:08

It turns out the reason why VotingAPI's Views include is not getting included correctly is because of its placement within hook_init(). We were experiencing this problem with VotingAPI 1.6.

For testing I added a drupal_set_message() to the votingapi_views.inc file. The only times I was able to see the message was:

a) I removed the require_once('votingapi_views') line out of hook_init and to the top of the module, and
b) When I edited the system table and changed the Weight of votingapi to be lower than that of the Views module.

Setting the Weight to the row for votingapi.module to -1 made the Drupal message appear and allowed the VotingAPI fields to show up. So far this is testing successfully without any issue.

My recommendation is to edit the .install file to edit the weight in the System table for VotingAPI.

See here: http://drupal.org/node/279171

#34

ebeyrent - March 24, 2009 - 18:20

I had the exact same thing happen with v1.6 of the votingapi module. I made the changes recommended in #33 and it worked perfectly.

#35

add1sun - August 19, 2009 - 21:25

Hit the same thing. Made the weight change, cleared the views cache and all back to normal....

#36

GuybrushThreepwood - October 19, 2009 - 17:52

Unfortunately I´ve tried your solution but it doesn´t fix it. Still no fields in Views.

Could you please repeat exactly step by step what changes you did, because a few days ago I´ve updated to Drupal 5.20 and the latest version of Fivestar and it stop working.

In case this has no solution, the creator of Fivestar should add a message in his project page advising Drupal 5 users to keep from using that module if they are planning to use it together with Views, since it doesn´t work and it seems that version is not supported anymore.

Any help appreciated

 
 

Drupal is a registered trademark of Dries Buytaert.