Port Vote Up/Down to D7

subscribing

Since there are many feature request on the queue for 6.x-3.x I think we can postpone it until we have at least a stable 6.x-2.x. So the 7.x-1.x version would be the port from 6.x-2.x, but still not sure about it, any feedback about pros/cons is welcome.

Please note that we should rethink the module on the port, since we now should be able to vote on fields, so a new vud_field should need to be written, so thinking it a little more, I think the best solution is to wait until a stable 6.x-3.x to make a D7 port.

since 2.x isn't released yet, I would much rather see a simple port to 7 first instead of waiting to release 3.x before porting.

How much of this is dependent on a 7.x version of votingapi?

Yep, this is naturally dependent on votingapi port to d7, but I see there is already a 7.x dev version, so let's see in what version we are in when the first testing release on votingapi is out ;-)

+1 (or vote up :D) subscribing

Subscribe

voting api now have release for 7.x !

thinking about what to do now(follow 3.x or port the 2.x branch).

I say port the 2.x branch, but that's just me. :p Interested to see this in D7 as well.

Subscribing.

Yeah, it would be great to have a stable D7 build. :) 3.x can come later..

YA, stable D7 build is important. Subscribing

I think it would be better to port 3.x version, specially since there is a key feature there that IMHO would make the port easier: #857888: vud_field module

So, please help me to have a stable 6.x-3.x soon

Most interesting :)
Subscribing

Subscribing - this is required for a lot of sites to upgrade to D7 + there should be a way to bulk import vote counts

Subscribing

+1

vote up ;-)

subscribing

On a related note - you can keep up-to-date on progress of similar modules here #990382: Voting/ Rating Modules that work with D7

subscribing

+1, subscibing :)

great module, thank you
subscribing

vote up, subscribing

subscribing

Not sure if this will be useful as I agree with the notion that some work needs to be done to include new methods, but, I have started porting this module to 7 (as it is) just because I need it to start some testing on a drupal 7 installation. I'm about 60% done and will be more than happy to post the code once I make sure it doesn't take down my site. The conversions related to the db calls are kind of a bitch.

sbscrbe

sbscrb

sbscr

subscribe

subscribe

subscribe

subscribe

Well, time has gone by and:

• The amount of features on 6.x-3.x is not so large as I would expect.
• Drupal 7.0 has been released.

So, I end up creating DRUPAL-6--3 branch and releasing a first alpha, and now HEAD will be targeting 7.x

@irritare: If you have a patch on top of current HEAD, this is the time to upload it here, or I am going to start from scratch.

I've made progress but it's nowhere near ready to post. I would start
from scratch too. I haven't been as systematic about it as i should
have been so my work will likely be useless to you. That being said,
the port seems pretty mechanical.

Let me know if there's anything i can do to help.

subscribing

subscribing

subscribing

don't mind me, just renaming for dashboard blocks.

Just created 7.x-1.x, so, battle plan:

• Port vud module and figure out changes on ctools implementations if so.
• Create vud_field
• Do not have more modules unless needed(aka it should be enough with the field, but I know I would require modules for specific features on 6.x, but that probably will be deferred).

subscribing

subscribing

+1

subscribing

vote up

Here's a bit of a start converting this module to D7. I mostly just implemented API changes, and have not really tested for functionality (i.e. a lot is still broken). I'll keep working though.

UPDATE: Whoa...my patch is formatted weird. It should still apply cleanly. Anyone know what's up with that?

OK, this patch is looking a little better.

I follow in a zip, has had visits @theunraveler

The patch doesn't work for me. Error: won't apply

subscribing

The patch was made against the 7.x-1.x branch in git. It that what you are applying it against?

Here's a re-roll of the patch using --no-prefix, so it's easier to apply on non-git installation (I had a problem myself). No code change from theunraveler's patch in #46

Setting to correct status.

subscribing

Patch in #51 doesn't work at all, I'll soon submit a patch with some fixes.

Here's a first stab. I only need the comments for now, so I work on it.

Many things are still missing, but you can see voting on comments.

And in this versoin vud_comments views integration works.

I move the development to my sandbox, so others can easily clone and collaborate:
git clone --branch d7 http://git.drupal.org/sandbox/amitaibu/1115336.git

Perhaps we should be writing tests to upgrade this module as well. I'll try to make a pass at that tomorrow.

> Perhaps we should be writing tests to upgrade this module as well.

Sounds good, you can git clone my sandbox and use your own sandbox, and we can merge each other's work.

Note that I've pushed some fixes:
- Ajax is now working!
- Plugins are now declared the new system (i.e. $plugin) instead of hook_vud_widgets().

Subscribe

subscribing

Will this version have an youtube like option (like / unlike without sum the votes)?

Something like this http://drupal.org/node/811694

@lesleyfernandes: This thread is focus solely on porting the module to Drupal 7.

subscribing

@theunraveler: Sorry, I will change my question, what's the version that will be ported? 6.x-3.0-alpha1?

Subscribe

Subscribe

@Amitaibu, @theunraveler: Hey! thanks! it's great to see code around \o/

I will be taking a look at it this week and hopefully follow my plan on #39 using the code provided in Amitaibu sandbox ;-)

/me hoping to get that code upstream soon

ok. i've got the latest stab "vote_up_down 7.x-1.x-dev" and patch it with #55 "749438-vud_comments-55.patch"

everything just fine now, but ajax didn't work at all. every submit of the voting form reloads current page. what i'm doing wrong?

hi,

i don't know yet how to do proper patches against git yet, but here is what i changed to get node votes working (because i just needed them to and couldn't wait :) ) .. maybe someone can benefit from this too..

in vud_node.module,
in function vud_node_node_view($node, $view_mode, $langcode)

/**
 * Implementation of hook_node_view().
 */
function vud_node_node_view($node, $view_mode, $langcode) {
  // avoid showing the widget in some node builds
  //$exclude_modes = array(
  //  NODE_BUILD_PREVIEW,
  //  NODE_BUILD_SEARCH_INDEX,
  //  NODE_BUILD_SEARCH_RESULT,
  //  NODE_BUILD_RSS,
  //);
  //if (in_array($node->build_mode, $exclude_modes)) {
  //  break;
  //}
  
  if (($can_edit=user_access('use vote up/down on nodes')) || user_access('view vote up/down count on nodes')) {
    $node_type = in_array($node->type, variable_get('vud_node_types', array()), TRUE);
    $widget_showmode = variable_get('vud_node_widget_show', VUD_NODE_DISPLAY_BOTH);
    $tag = variable_get('vud_tag', 'vote');
    $widget = variable_get('vud_node_widget', 'plain');
    $vote_on_teaser = (bool)variable_get('vud_node_widget_vote_on_teaser', TRUE);
    

    $widget_message_code = VUD_WIDGET_MESSAGE_ERROR;
    if (!$can_edit) {
      $widget_message_code = VUD_WIDGET_MESSAGE_DENIED;
    }
    elseif (!$vote_on_teaser) {
      $widget_message_code = VUD_NODE_WIDGET_MESSAGE_TEASER_DENIED;
    }

    if ($node_type) {

      switch ($widget_showmode) {
        case VUD_NODE_DISPLAY_TEASER_ONLY:
          if ($view_mode == 'teaser') {
            $node->content['vud_node_widget_display'] = array(
              '#value' => theme('vud_widget', $node->nid, 'node', $tag, $widget, !$vote_on_teaser || !$can_edit, $widget_message_code),
              '#weight' => -10,
            );
          }
          break;
        case VUD_NODE_DISPLAY_FULL_ONLY:
          if ($view_mode == 'full') {
            $node->content['vud_node_widget_display'] = array(
              '#value' => theme('vud_widget', $node->nid, 'node', $tag, $widget, !$can_edit, $widget_message_code),
              '#weight' => -10,
            );
          }
          break;
        case VUD_NODE_DISPLAY_BOTH:
          if ($view_mode == 'teaser') {            
            $readonly = !$vote_on_teaser || !$can_edit;           
          }
          else {
            
            $readonly = !$can_edit;
          }

          // grabbed and edited from vud_comment.module

          $tag = variable_get('vud_tag', 'vote');
          $widget_theme = variable_get('vud_node_widget', 'plain');

          $variables = array(
            'entity_id' => $node->nid,
            'type' => 'node',
            'tag' => $tag,
            'widget_theme' => $widget_theme,
          );
          $node->content['vud_node_widget_display'] = array('#markup' => theme('vud_widget', $variables));
          break;
      }

    }
  }
}

what i changed:
- commented out the exlude_mode thing because didn't know yet how to fix that in d7
- changed all the teaser checks to $view_mode == 'teaser' and $view_mode == 'full'.
- changed the rendering and adding to $node->content in lines starting from 200.

i'm also doing thumb up and down widget, but that's coming later if anyone needs.

.b

Subscribe

hi all.

is there any way to make a voting viget with ajax support? now everytime user casts a vote - oops, we are refreshing a whole page. it's no good, really

Amitaibu, what is your sandbox URL?

http://drupal.org/node/749438#comment-4300700

Gah, damn this machine with its twisted small fonts. Sorry :(

no problem ;)

I have pushed a fix that doesn't exist in D6 -- allow non-privileged users to see the vote-up-down handlers (and get a modal opened to give them an error/ login).

pressing the "voting details" in node view, brings up this error:

Fatal error: Cannot use object of type stdClass as array in /var/www/fs2/34/hankkeet/public_html/hankkeet/includes/theme.inc on line 800

any ideas?

.b

i don't know if these are any helpful, but no harm posting i guess... and i'm learning drupal coding at the same time.

here is what i fixed today to get rid of the voting details tab error:
in vud_node.module, in function vud_node_tracker:

theme('username', array('account' => $account, 'name' => $account->name)

$output = theme('table', array('header' => $header, 'rows' => $rows));
$output .= theme('pager', array('quantity' => 30));

so I just put the theme function variables into array, as drupal 7 wants.

.b

subscribing! Really need this

@amitaibu, #76 - you mention having pushed something, but there's no commits in your sandbox since early April. Is something missing?

> Is something missing?

Right, this time I pushed to the correct branch ;)

subscribing

+1

sub

+1

subscribe

Subscribing.

subscribe

Subscribing

Installed Amitaibu's sandbox, just tested votes for comments, working fine for now... Great work :)

subscribing, keep up the good work

Initially had some difficulties with Amitaibu's code, but I applied the patch posted by Atellier and it seems to be working. Thanks guys!

sub

I've pushed more cleanup code to "Amitaibu" repositoty.

@marvil07,
If you'll give me commit access I can push it to original repo (or go ahead and do it youself) -- I think it's better if people start using it, and *hopefully* providing patches.

Oh, finally, it's been a while since I have some time to work on this module.

I am really sorry for the delay.

Again, thanks to Amitaibu and theunraveler for providing code.

Remembering again what I proposed as battle plan:

Just created 7.x-1.x, so, battle plan:

• Port vud module and figure out changes on ctools implementations if so.
• Create vud_field
• Do not have more modules unless needed(aka it should be enough with the field, but I know I would require modules for specific features on 6.x, but that probably will be deferred).

Naturally, I am integrating changes from Amitaibu sandbox, but I touched them a little to actually give attribution to theunraveler and squashed two little commits(actually my original idea was to massage that history to reflect major changes and avoid too tiny commits, but I can live with that for now :-p). That code is pushed.

After integrating the code on mainline(7.x-1.x branch), I decided to start a vud_field module and see how difficult it would be, and now we also have a vud_field module pushed too!

So, why I wanted a vud_field instead of updating all vud_* modules, because I wanted to embrace 7.x core API.

Now, I would really want to remove vud_* modules in favour of vud_field, since now we can just add fields to comments, nodes, terms, any entity drupal knows about. What it's left is upgrade path from 6.x to 7.x.

Does it sound OK?

BTW, at this point I think we better create specific issues instead of following this never-ending issue :-p, but let's defer it until I get some of those issues open and get some feedback.

> Does it sound OK?

Field idea sounds great. Let mark as fixed an move to follow up issues

That is a wonderful idea (and it should be much more maintainable!).

this module looks very nice - waiting for port 7

subscribing

Subscribing

Subscribing

subscribe

If you would like to follow development, do not subscribe to this issue, as it has been marked as "fixed". Instead, subscribe to the other, more specific issues where work is still being done.

The actual issues that need to be done or need review (please review and test) are http://drupal.org/project/issues/vote_up_down?version=7.x

if the release was made visible on the project page instead of just here http://drupal.org/node/48774/release then people would probably stop subscribing to this issue

It's probably not in good enough shape to show publicly yet. As I remember nodes don't even work yet (although I see there's a patch in needs review)

I tested the D7 port of vote up down module. It seems well on its way, but I found 2 issues:

• 1. One time, it went to a white screen when I voted on my own comment; the vote did count afterwards. I tried voting on another commment of mine again, but it didn't happen when I tried it again.
• 2. When I went to review my voting history from my user page, it produced a white screen with the following: Fatal error: Call to undefined function db_rewrite_sql() in /sites/all/modules/vote_up_down/vud.module on line 134

Also, I figure I'll throw in a feature request. It'd be nice for the D7 version to have the ability to allow users to shuffle the comments by votes or by date of comment. That way if the user chose to shuffle by vote, as the vote tally changes, the comments would change positions with higher ranking comments at top. Just a thought, not a necessity, but the name vote up down seems to beg the question.

Subscribing

subscribing

(delete, typo)

I have an existing D7 site to be migrated to D7, so vud_node is better than vud_field for this case.

So, testing vud_node, pulled from git:

a) First problem is that I did not see the widget on the node view, despite enabling for that content type in admin/config/search/voteupdown/node. There are no voting options (e.g. field positioning) in admin/structure/types/manage/MYCONTENTTYPE. What am I missing here?
FIX: One bug found here is that "theme('vud_widget'" must be called with an array argument, i.e. around line 256 in vud_node.module

               //theme('username', $account),
        theme('username', array('username'=>$account)),
        $vote['value'],
        array('data' => format_date($vote['timestamp'], 'small'), 'class' => 'nowrap')
      );
    }
    drupal_set_title(check_plain($node->title));
    //$output = theme('table', $header, $rows);
    //$output .= theme('pager', NULL, 30);
    $output = theme('table', array('header' =>$header, 'rows' =>$rows));
    $output .= theme('pager', array('quantity'=>30));

B) Similar to #107, node/NID/vud-votes gives a white screen, but the error is different:
Fatal error: Unsupported operand types in /disk2/www/drupal-7.8/includes/theme.inc on line 832.
Debugging seems to indicate that the problem is the arguments to the theme function.
FIX: Correct vud_node.module around line 251 as follows:

    //$output = theme('table', $header, $rows);
    //$output .= theme('pager', NULL, 30);
    $output = theme('table', array('header' =>$header, 'rows' =>$rows));
    $output .= theme('pager', array('quantity'=>30));

Note to "subscribers": use the new Follow button on the top right :-)

Any chance of verifying and committing these fixes to git please?

Created full patch for #111

Has anyone tested/debugged the views integration?
Would like some help there..

Just found another bug as regards the use of NODE_BUILD_* in vud_node_node_view.
Fix, use:
function vud_node_node_view($node, $view_mode, $langcode) {
// avoid showing the widget in some node builds
$exclude_modes = array('search_index', 'search_result', 'rss');
// @todo: what about $node->in_preview ??
if (in_array($view_mode, $exclude_modes)) {
return;
}

No warnings in watchdog any more..

Just noticed that node votes are not preserved after a D6 > 7 upgrade

Forget the fixes I proposed above, apply the patches in #1194274, fixes most stuff.

Quoting myself on comment 95:

BTW, at this point I think we better create specific issues instead of following this never-ending issue :-p, but let's defer it until I get some of those issues open and get some feedback.

there is still no D7 version available on project's page.

@clashar: Right, but I would like to not link it on project page until an upgrade path is ready, details on #1360572: Roadmap for D7 of Vote up/down

where i can download this VUD module for drupal 7

@dantebreath: at the bottom of every project page, right after the listed available versions there is a "view all releases" link. From there you can get to a page that lists all versions of a module and can even filter them by branch (6.x, 7.x etc). Anyways, for VUD, the 7.x dev version is available here:

http://drupal.org/node/1088740

sub'in

Update

For any of the 84 followers still interested...

I have offered to co-maintain the vud_node module. Here is something to test. I think everything is working.

Attached is an updated vote_up_down module (7.x-1.x-dio). It can be installed in the normal manner or unzipped over an existing 7.x-1.x-dev vote_up_down directory without impacting any vud_fields that may have been added with 7.x-1.x-dev release.

Only the code in the vud_node directory has changed (with one small exception). So unzipping the 7.x-1.x-dev archive over the 7.x-1.x-dio install will restore your 7.x-1.x-dev code.

This version has a new vud_node configuration page (see attached screen shot) which allows any one of 5 vote widgets to be selected for each content type. The configuration page is a table form that automatically adjusts to the addition and deletion of new content types (see /admin/config/search/voteupdown/options).

The vud_node module should now work and be easy to setup and test. A vote tracking tab page will appear on each node page to help you track voting.

Please take a few minutes to test it out. If it works and you like it and if you want it to be supported, change the status below to RTBC (Reviewed and tested by the community) and offer a few words of support.

If something does not work, let me know and I'll get on it.

@Diogenes In the code you provided above, function vud_configure_page has a hardcoded form which removes a functionality of creating custom vote up/down widgets.

Attaching a patch for 7.x-1.x branch which maintains that. Please review.

Sorry for the previous patch(was created using a wrong branch). Uploading another patch.

@piyuesh

Thankyou for your interest, effort and the post.

Short answer - No, your patch will not allow for the automatic addtion of a custom vote widget.

It took me awhile to figure out how to apply your patch. It did not work against the above version but it did work against a recent 7.x-1.x git pull. While some error messages disappeared, the voting widgets failed to appear. Then I realized you manually applied some changes to to 7.x-1.x and made a patch from that.

You are correct that the new vud_configure_page() does not automatically add custom widgets. There is a function -- wud_widget_get_names() that dynamically creates a radio button list for the vote widgets found in the widget subdirectory. I am assuming this works on the old Node configuration page but I do not have a custom widget to test with.

The old configure page also created a dynamic checkbox list for content types. This did not work because every content type had a widget whether it was selected or not as long as one content type was checked.

I crafted a new config page (and the plumbing to make it work) that has a dynamic table for content types. The admin can select the any of the standard widgets for each content type (or none at all). The vud_configure_page() is a bit unconventional because the table is largely hand crafted. The idea was to show a sample of each vote widget as it might appear with votes registered. This is a challenge to do dynamically.

If you do have a custom widget that you would like to add to the configure page, it will be considerably less work that that required to create a custom vote widget in the first place. To make a custom vote widget you need to hand craft a css file, a tpl file, a couple of image files and a definition file.

After this is done, adding the custom widget to the vud config page page code is pretty easy. If you have a custom vote widget and have trouble doing this, send it to me and I can add it for you.

@Diogenes

I am sorry for the trouble my patch caused you. I created it out of 7.x-1.x branch taking the code from git version.

My intension of preserving the hook is just to allow any developer to code their own widget without modifying the contrib code. I don't think that should be difficult to handle(Probably we might need to change the way the form is rendered). I will give that a shot and add an updated patch over here.

My question is which branch should i be using to create a patch that would apply to the zipped version of the code uploaded in #126?

@Diogenes - have you been given commit/co-maintainer status for this or vud_node yet? If so, it would probably be best to commit what you have already and then allow others to create additional patches. If not, I would suggest creating a sandbox repo with your code that people can create patches against until the current maintainer is ready to merge the code or gives you access to do this directly.

managing big patch files and/or patches to zip files is less than ideal.

@piyuesh23

I am sorry for the trouble my patch caused you.

So you made me scratch my head and think? That is never a bad thing! No apologies necessary. :-)

I think I understand what you want here (correct me if I'm wrong) and I'm all for it.

I'd like another vud widget myself, a horizontal inline version with flyover activation like they have on StackOverfow for comments (to a question or an answer).

My first step in creating vud_config_page() -- this name will be changed to vud_node_config_page() -- was to create a simple html page for the the UI presentation. I used a table. In the table head is a widget gallery which includes a sample vote widget from every subdirectory in /vote_up_down/widgets. The 'panel.php' file in the zip file in #126 is that html prototype page (http://localhost/sites/all/modules/vote_up_down/panel.php). It includes vud_node_options.inc. The function vud_config_page() should work with or without drupal.

I'm thinking a module called 'Vote Widget Gallery' or something along those lines would work best here. The job of the module would be to construct a vote widget gallery and add it to the config table which means using php to construct the widget gallery (which is now hand coded).

The VUD gallery module would extend vud_node, vud_comment, and possibly vud_term and vud_field (which would all be hived off into separate modules).

The vud_config_page() table body is dynamic (php code) but the table head is not. I'll admit that the vud_config_page() form is a hack but it seems to work ;-). I'm open to suggestions here. If you can do a proper drupal form on this puppy, I'm not going to stand in your way.

-Dio

P.S. Oh yeah, the question - I created my own branch of the 7.x-1.x repository. There are many changes and the patch file to the 7.x-1.x git release is getting a bit silly. I used to develop on a Windows platform and I hated dealing with unix patches. It was so much easier to simply replace the whole module with a different version and see if that worked. So that is was I did in #126.

@rcross

have you been given commit/co-maintainer status for this or vud_node yet?

Not yet -- waiting on that decision.

If not, I would suggest creating a sandbox repo with your code that people can create patches against until the current maintainer is ready to merge the code or gives you access to do this directly.

I could do that, but sandbox projects are virtually invisible on Drupal.org and unless one is familar with Git and the Drupal way of doing things, they only make things more complicated, especially for Windows developers. There are also some namespace conflicts to resolve here. It would be far simpler and less work if I was promoted to a co-mainatainer.

If you unzip #126 and compare a proper git branch 7.x-1.x with #126 -- use meld (unix) or windiff (windows) -- you will see no changes to vud_field. As far as I can tell (with testing), vud_node and vud_field are compatible but they are two on separate vectors - use one or the other, but not both, unless you are a masochist or know exactly what you are doing. Hence the need to hive off into different modules.

I hope this explanation will result in your support of my application to become a co-maintainer.

-Dio

@Diogenes - regarding the co-maintainer status, I think you'd be best to create a dedicated ticket for it. See https://drupal.org/node/363367 and https://drupal.org/node/251466 for the process.

Regarding the sandbox, the point is to create a place where you can commit/store code that others can also access following the normal d.o process (by trying to cater for windows sitebuilders/devs, it makes it much harder for every other developer to assist since this doesn't follow the normal dev process). Sandbox's won't have naming conflicts, and they can easily be deleted once this code is merged with this project's repo (that's kind of half the point of sandboxes). Agreed its probably best if you're promoted to co-maintainer, but in the mean time...

Looks like your version works pretty well (except comment dimming, but we have patch for this bug), thanks

Thank you oneshot for testing this and for the RTBC. Just curious - when do you dim the vote widget? Anon users?

I am preparing a new patch now. As far as I can tell, there should be no impact on the behavior of the vud_comment module.

I haven't touched the code in vud_comment so the patch you mentioned should still work.

Update -- a new zip and a new patch file posted: https://drupal.org/node/1194274#comment-7721449

@Diogenes: Hey Jim, Happy new year!

Do you still have interest in taking over maintenance of this project? If so, I'd suggest you wait no longer and follow what Ryan links to back in #134. I mean, from the usage stats of this project it seems as though as its users are slowly twiddling as they move away and it would honestly be a shame to loose a respectable amount of user base.

I agree that this might seem like overriding the maintainer, but you did contact to express interest and to me personally it seems that he is procrastinating without any real reason other than personal attachment to his "baby". This is totally understandable/human and respected, but if he doesn't have the time or energy for it, then the honorable thing to do would be to step down. Even if he has objections to the road you mean to take implementation-wise, you can always create a 7.x-2.x branch and work there leaving his 7.x-1.x branch untouched for when he finds time to work on this again.

Alternatively, I'd simply start a separate vote_updown project. If you do, please let us know. Thanx.

@klonos - and a Happy and prosperous 2014 to you too klonos. Thanks for that post.

Uh, no. It's not going to happen. To be honest, I have lost my enthusiasm for Drupal.

The core is great software but the Drupal.org website provides no evidence of this. Almost 3 years to switch from D6 to D7? Ouch.

The project pages on Drupal.org offer no means of rating a module or leaving a review. Or rating a review. (Hint - there is a module for that, but it is not this one). They have tools for measuring code quality but no metrics are run on existing contributed modules.

There are way too many modules that are old, buggy and outdated -- that should be purged or demoted to make way for new blood, especially while other more worthwhile candidates languish for months in an opaque review process.

Drupal org has some funny notions about "open-source" and "community". Ideas to improve the site, the processes, or the community are just lost in the cloud.

Nothing much has changed in the last few years. I can't see that changing.

Au revoir,
-Dio

I'm so sorry that you got frustrated to that point :/

I guess I have more patience (perhaps more than we normally should) and I must be more forgiving than most but you are definitely well-justified and your decision understandable and respected. I hope things change real soon too so that we don't "loose" any more valuable community members.

Bless you.

Since this has been RTBC several years ago what is preventing to get the 7.x release out? IS this still maintained?

Since this has been RTBC several years ago what is preventing to get the 7.x release out? IS this still maintained?

As the time of this reply evidence, I have been making a bad maintenance job on this project. I guess I started the D7 port assuming all submodules would disappear in favour of vud_field, but I have just failed to convince the users about the advantages of that.

So, now that I do have time, I know, really late; I will just branch out to have two versions:

• 7.x-1.x will contain the port of all vud submodules, but I will mark it as non-supported unless a co-mantainer would like to help with that. I will also try to add all the existing patches in the queue fixing things for them.
• 7.x-2.x will contain only vud and vud_field, which may replace all the others as I originally proposed, but the initial version will not migrate from vud submodules to to vud_field. Please notice the open issue #1363928: Upgrade paths from vud_{node,comment,term} to vud_field about that, patches welcome!

About D8, I posted a GSoC project to mentor, to bootstrap that, and hopefully it gets accepted, but general notes on the main issue about that #2844432: Port vud to D8.

Closing this now that I added most of the changes to 7.x-1.x and released 7.x-1.0-beta1 and 7.x-2.0, let us use #1360572: Roadmap for D7 of Vote up/down for anything else not specific.