votingapi_views.inc included in wrong place

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

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

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

This should also solve this issue.

Patch applies to 5-dev with fuzz.

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

+1, works for me too.

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

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!

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...)

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

subscribing

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.

That would be great...thanks Eaton!

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

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.

@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.

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

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

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

like, I said, seems to be working.

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.

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.

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.

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

http://drupal.org/patch/apply

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?

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..."

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.

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

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

Re-rolled against latest DRUPAL-5.

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 'DESC LIMIT 0, 15' at line 1 query: SELECT node.nid, node.sticky AS node_sticky, value FROM node node WHERE (node.status = '1') AND (node.type IN ('mobileapp')) 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.

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.

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

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.

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

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

subscribing...

Thanks guys for sorting this ugly thing out! Solved my issue with #30 and #33 (changing system table weight property manually)

GuybrushThreepwood, this should work for you to.

I'm using Drupal 5.21, VotingAPI 5.x-1.6, Views 5.x-1.6 and Fivestar 5.x-1.16. Im sorting my view results with VotingAPI percent vote result (average).

Support for the 5.x branch of VotingAPI has ended with the release of Drupal 7 and the upcoming release of VotingAPI 7.x-2.4.