I used a view filter in 4.7 that filtered on voting api, and whether a vote had been cast on a node. After CAREFUL upgrading of my system to 5.0, the voting api is no longer exposed as a filter option, thereby breaking the view.
I've tried uninstalling and reinstalling views and the voting api, and then recreating the view. Still, the voting api options are not available when creating a views filter. This is preventing me from upgrading my website, since this view is critical.
I've tried exporting the view from 4.7 and importing it into 5.0. (see attached) When this is run, I get the following error:
You don't seem to have the following requirements: votingapi_vote, votingapi_cache
However, voting api IS INSTALLED and these two tables do exist in my database with live data, along with the other requisite voting api tables.
| Comment | File | Size | Author |
|---|---|---|---|
| top_blogs.txt | 2.08 KB | zoon_unit |
Comments
Comment #1
merlinofchaos commentedLet's ask Voting API why Views isn't picking up its stuff.
Comment #2
zoon_unit commentedI've submitted an issue with voting api 5.2. I've had tons of trouble with the voting api module under 5. I'm sure that is why views isn't picking it up. Voting api 5.2 won't update the 4.7 tables for some reason. So I finally dumped my votes and dropped the old tables, planning to install a fresh copy of voting api, only it won't install. No tables get created when I enable the module. And yet voting api installs fine on a fresh install of Drupal 5.
Unfortunately, I don't understand Drupal's structure well enough to sleuth out the reasons. I assume there's some flag in the system table that's not set right in the 4.7 upgrade? I even tried copying the correct 5.0 voting api tables over from the fresh install, but when I ran update.php I received tons of errors.
Surely, I'm not the only person using voting api and views together. I'm surprised I'd be the first person to discover this. :-(
Comment #3
zoon_unit commentedUPDATE: I've finally managed to eliminate the voting api install problems by deleting the module entry from the system table and reinstalling. Voting api is now installing properly and creating the votingapi_vote and votingapi_cache tables. Everything seems to be functioning properly. I can cast votes successfully using the vote up/down module.
(BTW, many of these module install problems seem to stem from the fact that the system table NEVER deletes old module records, or updates the module locations when one moves modules from the modules folder in 4.7 to the sites/all/modules folder in 5.0)
Now, back to the original problem of voting api not being exposed in views filters: Even though the voting api tables now exist, views is not picking them up. Views worked fine with voting api under 4.7 though. So, how does views know when the voting api is installed? Is there a variable set somewhere besides the system table? If so, the 5.0 voting api doesn't appear to be setting it properly. I can't sort a view by votes either.
Voting api hasn't been updated since 2006, so I have to assume that anyone else using votes in a view under 5.0 would be experiencing this same problem. I'm surprised no one else has brought this up, since the voting api and views modules are so popular.
I have even tried installing voting api and views in a fresh install of Drupal 5.0 and votes are NEVER exposed in views.
Comment #4
eaton commentedFixed in the new release -- Views integration has been rewritten.
Comment #5
(not verified) commented