Drupal - Feeling a bit let down now (no uninstall functionality for modules??)
I'm in sort of a pickle here and I'm feeling a bit let down after ditching my old CMS to move to drupal.
I was trying several different modules to get a good voting/rating system going. Some of the modules started to conflict so I went through and disabled all of them and deleted them from the modules/contrib directory. I did this in order to start over from scratch.
Well after re-uploading and enabling them I was having the same issue. So I disabled them, deleted them and dropped the tables.
NOW, when I attempt to upload and re-enable them, the modules are not creating the tables in my database, WHY?
Can someone please offer a word of advice? And better yet, can someone answer the question of why drupal does not have uninstall functionality for the modules? That's very frustrating!
Quick notes
Drupal stores the 'current installed version' of a given module in the system table -- it uses that to determine when to run update functions for module schema changes. Going to that table and deleting the rows for the modules you've uninstalled will get things back to their 'pristine' state, and allow the automatic installation to occur again. If you're in deep enough to do that, I'd suggest you download a copy of the 'devel' module for Drupal. It's got a lot of development/troubleshooting tools, and also includes a feature that lets you force a full 'install from scratch' for a module without manually deleting any records.
The 'completely uninstall' functionality (which is really just a matter of dropping the tables AND deleting the entry for the module in the 'system' table) was on the table during the 4.7 development cycle, but there were some controversies about users not realizing their old data would actually be nuked.
Also, are there any particular voting issues you're running up against? As the maintainer of VotingAPI, my ears perk up whenever the subject is brought up...
--
Eaton's blog | VotingAPI discussion
Eaton, much appreciated
Thanks for the kind response, Eaton. I had no idea that there was a system table which an entry specifically for the module. Shows what I know!
So if you're suggesting that I delete any records from this table, I'll give that a try and report back.
As for the particular voting issues, I was using nmoderation and every time I would vote on a node it would unpublish it. There was no logical reason why, it just wasn't working as intended (and I followed the instructions to the "t"). So I started over with Node Vote and figured through voting_actions I could set up an action. Well, that's where I started noticing errors like
* Failed: ALTER TABLE {votingapi_cache} ADD COLUMN timestamp int(11) default NULL;* Failed: UPDATE {votingapi_cache} SET timestamp = 1150340242 WHERE timestamp IS NULL;
which means although I dropped the table and reinstalled the module, the module was not recreating the tables (obviously now, because the system module still thought the module existed?)
Again, thanks for your help, i'll work on this more tonight and report back!
Uhoh.
First off, I was the one who ported nmoderation to Drupal 4.7, and completed its migration to VotingAPI. There have been a few people reporting the same problem that you were seeing with it, and I've been swamped enough over the past month or so that I haven't had a chance to go in and troubleshoot it. I'll take a look at it over the weekend and see if there's any rhyme or reason to the promotion/unpromotion bug.
The errors you mention getting are, in fact, due to what you suspected. When you dropped the tables (without deleting the entry in the 'system' table for VotingAPI and nmoderation), Drupal was left thinking that the tables were already there. When you re-installed the modules, they didn't recreate their tables, and when you upgraded to the latest version of VotingAPI (which adds the 'timestamp' field), it tried to change the existing table -- which wasn't there at all.
Confusing as all heck, but it makes sense when you know what's going on "under the hood."
Sorry that your experience has been so rocky! I've been working on getting a number of tools for voting and voting-based workflows ready for 'prime time' in Drupal. Some of them are still a bit rough... I'm sorry that it's been such a strange trip trying to get things set up. I will say that the newest version of VotingAPI has some much improved capabilites for integration with actions, promoting nodes, etc. (Things like, 'If at least ten people have voted, and the average vote is 75% or higher, and the node is a 'story' node written by Bob, promote it to the front page...')
I'm working on building the UI for it, but if you know a tiny bit of PHP, there are ways to configure it directly and set up your own complex moderation rules. I can put together a quick reference to some of that information, if you'd like...
--
Eaton's blog | VotingAPI discussion
Awesome
It is confusing as all heck, but this whole experience has helped me to better understand the application, so I'm thankful.
I am a long time Movable Type user who recently converted one of my community sites to drupal. It's been a major adjustment but it's definitely for the better. I appreciate developers like you giving your time to make the entire community better; So I apologize if I was a bit brash on my initial post when I mentioned not being able uninstall a module.
After hearing that you're porting nmoderation, I think I'd like to hold out and wait for the bug to be fixed and use that as my solution. I read another thread where you gave instructions for setting the criteria (percentage & count, I think) and that's exactly the solution I was looking for.
In the meantime, I've got some tables to drop ;-)
to clarify
It was actually advice that you were giving on another module, voting_actions found here. I think I may go this route.
http://drupal.org/node/47496#comment-89432
*edit - they actually have the same end result I think . . . I can't decide! :-)
A heads up :)
Just to keep things interesting (Ergh...) here's the plan for votingapi, actions integration, and the future:
voting_actions.module is going to go the way of the dodo. The 'engine' it uses -- the part that launches actions based on votes -- will be built into votingapi.module. Other modules (like nmoderation) will be able to tap into that engine to do their promoting and unpublishing. Users interested in customizing the rules that govern those actions -- and the specific actions to be executed if the rules are met -- will be able to use the votingapi_actions.module, which will be bundled with votingapi. That additional module will only be necessary if users really want to tweak the rules.
I *will* be providing a migration path for data from the old voting_actions module to the newer votingapi infrastructure. Since the new approach has all of the old functionality and then some, there will be no loss of function for the folks who are using it now.
--
Eaton's blog | VotingAPI discussion
Migration is good
Thats awesome, thanks so much.
Hey I'm running into a few snags with voting_actions. A node is showing in the logs as being promoted to the front page, but it's not actually going to the front page.
(should I create a new thread?)
Thanks for all of your help, I can't thank you enough.
(here is the site in question http://stlphotoblogs.com)
Actually, it is going to the front
It is going to the front page, cool! But it's using the original posting date which can push it very far down the front page. I'm going to see if there is a way to make it go to the top of the front page . . . .
Aha!
One of the actions that can be triggered is "touch creation date" ... That sets the creation date of the node to the current date/time, so that it will pop up on the front page at the right time. Slowly but surely, progress is made! ;-)
--
Eaton's blog | VotingAPI discussion
Does order matter?
I have 2 actions set for this one "action set".
One is "touch creation date" and the other is "promote to front page". Does it matter what order they go in? (i.e. - Does touch creation date need to go before promote to front)
What we're doing is posting images into photo galleries which by default are set to not promote to the front page. Then the users get to rate the images; Higher rated images get pushed to the front page.
---
Glad you liked the lightring tutorial! I have a few more tutorials here and am getting ready to build a revised lightring for about half the cost (and much lighter / more portable!). Thanks again!
The solution!
OK, after some investigation I figured out what was going on and why it wasn't touching the creation date. The short answer is this: download the latest version of voting_actions.module, THEN go to admin/settings/votingapi and turn 'actions integration' off. It's counter-intuitive, but I'll explain why.
1) First, a recent minor change in VotingAPI had broken voting_actions.module and I hadn't realized it. There was no visible failur, but it Just Stopped Executing Any Actions. The new version fixes that.
2) VotingAPI has its own built-in action handling now
3) SimpleVote exposes a 'default' action that promotes nodes to the front page if they get enough votes, but DOESN'T touch the creation date.
4) SimpleVote's "default" internal action set was doing the promoting, and the voting_actions set you had created was being ignored.
So. Get the new version of voting_actions, disable VotingAPI's 'built-in' action settings, and all should be well. This is precisely the sort of confusion I want to eliminate with the refactoring that I'm doing -- it's only visible now because of the (temporary) situation where there are two overlapping methods for action-handling.
Using the setup I outlined above, I did create an action set that does what you're describing: it promotes stories AND touches their creation date so they appear at the top of the list.
--
Eaton's blog | VotingAPI discussion
Eaton, thanks dude!
That worked like a charm. I can't thank you enough for your help. Do you have a paypal account or some type of deal for people to support your efforts? It wouldn't be much but I'd like to contribute. Let me know. . . .
Excellent!
Well, I'm *very* glad to hear that it can be made to work after all the hassles. ;-) If you're interested, I never refuse a gift; my account is under jeff@predicate.org. If you're interested in keeping up on new developments with Drupal's voting systems (and the news on the upcoming developments with votingAPI), you might also check http://groups.drupal.org/voting-systems. I try to post there with news and developments before anything major hits the 'official release'.
(Also... put together the DIY lightbox this weekend. Thanks for the instructions. It's an awesome tool!)
--
Eaton's blog | VotingAPI discussion
Cool man, done
Right on. I'll definitely stay tuned!
Hey also, guys like you should have some sort of drop box so when people want to contribute, they can.
A lot of people benefit from the code you write. I'm not sure of the statistics but say only 5% of people who use your code felt the need to contribute, and say 500 people download and use your lastest simplevote / voting API. That means if 25 people contribute an average of $10 than that's a nice little chunk of change. (it's not a huge amount but it's enough to take the lady out for a nice dinner, lol)
I dunno I'm a newbie so maybe I'm off, lol. Anyway I'll definitely stay tuned for the latest voting module, I saw the screenshots on flickr so I'm pretty stoked. Cheers!
Oh, and...
I just spotted your flickr groups. The DIY light ring rocks and I'm going to work on putting one together this summer. :-)
--
Eaton's blog | VotingAPI discussion
Oops, now it's not :-0
Now it's not touching the date again. I hope I didn't break anything. You can see by the front page, all of the thumbnails that you see in the content section of the front page are promoted (by default, they do not make the front page).
You'll see some of them are down on the page and they have the original date still, weird!!
http://stlphotoblogs.com
Doh!
Looks like our celebration might have been premature! When you go to the /admin section, there should be a log entry for each node promoted to the front page. There should ALSO be a second log entry for each time a creation date was 'touched' by that action. Is it possible that the nodes that were promoted initially didn't get their creation dates touched, but new ones have?
When you vote a new node up, and it's promoted, what shows up in the /admin page's log entries?
If you're interested, there's also one other option that involves using the 'CVS' version of votingapi, and setting up a custom action set with the 'new' actions integration. It's definitely more reliable in the long term, and easier to troubleshoot, but there's no 'friendly' user interface for it just yet (oif!). I can walk you through that process if you're interested; it will also allow you to exercise a lot more control over the vote criteria if you're interested. (ie, only promote certain types of nodes, only promote if enough people have voted, etc).
--
Eaton's blog | VotingAPI discussion
Things that make you go "hmmm"
Thanks Eaton, I appreciate your patience and perseverance! :-) The node shows as promoted but I don't see anything in the logs that shows a 'touched' creation date. In retrospect, I should have been looking for that in the logs (can I pull the newbie card on that one?) Let me do another test. . .
Opened my mouth (or keyboard) too soon, it is, in fact showing the node as touched. It's weird though because I can almost swear that this wasn't the case before, ah well. I set the threshhold to be 1 vote with at least 80% and gave it 5 stars, it worked.
Hey the CVS does sound interesting though. So is the CVS basically like the 'beta' of a module? If so, I'm definitely down to give it a shot. I did have a couple of questions though, that are somewhat unrelated. I feel sort of bad for asking you so many questions though.
Will the voting_actions module work with any voting system? I like the simplicity of simplevote but there are no settings for allowing anonymous voters, deleting votes, etc. I know this was by design, and that you created simplevote for the sole purpose of showing others how to use the API. But anyway that was my question, can I use any ole voting module (like medium vote) and will it work properly with the voting_actions module? I like the idea of an administrator's vote bearing more 'weight' if you will than a vote coming from an authenticated / anonymous voter.
Anyway, I'll wait to hear back before I mess with anything! I hope this thread will help others who are going through a similar situation. (of course, it could be said that I'm keeping you from actually doing the dev work on the API, lol)
Some answers, at last!
A couple quick notes. First, after a long sojourn in the land of 'buggy,' I figured out what was causing nmoderation to behave erratically when promoting or demoting nodes. Those who do want to use it can now rest easy that it will actually calculate total scores correctly. ;)
Second, the CVS version is a bit like 'beta', though generally it's *stable*. The biggest difference is that features are present in the CVS version that are not quite 'done' yet -- like the ability to interact with the new and improved votingapi actions integration. There's not a pretty UI to manage and set up new actions yet -- instead, there's a big text field where you can edit the textual representation of the action set data. ;) It's a little arcane, but no more difficult than tweaking HTML or a bit of simple PHP, if you know the format that it expects. It also lets you see how modules that expose their own actions do their thing: you can examine, for example, SimpleVote's default promote-to-front-page action as an example.
Obviously, the next step is adding a user friendly UI, not unlike what Views.module uses, but that's also a complex undertaking given the system's flexibility. That's why it's still in the CVS build rather than the DRUPAL-4-7 build. ;)
And, to answer your question, yes. both voting_actions and votingapi's new 'built in' actions integration will work with any votingapi based module. UserVote, MediumVote, Vote Up Down, even NModeration.
--
Eaton's blog | VotingAPI discussion
:-)
Thanks for the update Eaton. I appreciate you taking the time to look into this and basically hand-hold through the whole thing, lol. If I was savvy enough I would have tried to submit one of those ticket thingies instead of dragging it out on the forums ;-)
----
I tried the voting up/down module briefly (for a few hours) last night and really liked the functionality. One thing I couldn't figure out was the voting_actions. I could get it to promote and touch creation date, but could not set it correctly to demote. Since voting up/down uses +1 and -1 I had to adjust voting actions like so:
(Value Type | function | comparison | value)
Percentage scale | average | greater than | 1
Percentage scale | count | greater than | 4
Action:
Touch Node Creation date
Promote Node to Front page
Which technically would promote a node if after 4 votes the average was one or more (which, since voting up/down scores in 1's then we're good)
Then to demote I reversed the logic. I created another seperate voting action (action set name)
(Value Type | function | comparison | value)
Percentage scale | average | less than | 0
Percentage scale | count | greater than | 4
Action:
Remove Node from front page
Which technically should remove from front page.
----
I also tried to use nmoderation but in short, the demote functionality wasn't working, and I couldn't figure out why a negative vote would show as a value of two. (also while attempting to delete votes I was getting some stuff like "You have an error in your SQL syntax near '' at line 1 query: SELECT n.nid, n...")
I also tried a bunch of other stuff with pretty much every voting module available and couldn't quite get it nailed down.
So . . . . . . I think I'm back to simplevote and voting_actions as I was before. I think I'll wait until the final rollout, from reading the forums it sounds like you're going to eventually roll all of this stuff into voting API? I've spent probably a combined 15-20 hours on this so I'm humbly downgrading to the original configuation. I wish I knew a thing or two, i'd lend a hand! Thanks again for all of your help Eaton . . .
System Table
You need to take a look at the system table. It holds the state of the different modules. If the module is still in the system table, Drupal will think that the module is still installed. So it won't re-create the tables automatically.
I agree that a module uninstaller would be a useful tool.
Steve Hanson
Principal Consultant Cruiskeen Consulting LLC
http://www.cruiskeenconsulting.com
I subscribe
Idem.
-----
http://para.ro