Drupal 8 port of Voting API

I don't have any plans on porting votingapi to D8. IMHO it would need a complete object oriented rewrite.

The developers of Rate are thinking about writing their own pluggable storage:

If possible - we will use the VotingAPI for storage of votes. If not - we should consider writing our own pluggable storage which can be replaced by a VotingAPI plugin later. But that will increase the amount of work to be done, while it doesn't add value in the long run.

D8CX: I pledge that rate will have a full Drupal 8 release on the day that Drupal 8 is released.

I've added this as a proposal for GSOC, let's see if there's someone interested https://groups.drupal.org/node/455978#project9

I am interested in porting this module to D8.
Please join #drupal-google (my nickname is andreimarius) if you want to discuss more about porting this module as part of the GSoC 2015 or leave comments here.

I'm going to take a stab at creating some form of port within the next couple weeks, so I'm assigning this to myself.

That's great. @andrei.dincu has submitted the D8 port of votingapi as GSoC project. You might want to get in touch with him too.

Thought I'd be able to get this up here sooner, but ended up with a bad sinus infection last week. At any rate, better late than never.

I've tried to start making use of D8 APIs, so this definitely doesn't look like the D7 version of Voting API. Among the changes are:

1. Votes are proper Drupal entities. This has resulted in a number of tweaks to how Voting API is used. Many of the Voting API functions have been dropped in favor of using the standard Entity API to interact with votes. For example, when retrieving votes, you'd use an entity query now.

   Before:

   $criteria = array(
     'entity_type' => 'node',
     'entity_id' => 123,
   );
   $votes = votingapi_select_votes($criteria);
   

   After:

   $vote_ids = Drupal::entityQuery('vote')
     ->condition('entity_type', 'node')
     ->condition('entity_id', 123)
     ->execute();
   $votes = Drupal::entityManager()->getStorage('vote')->loadMultiple($vote_ids);
   

   This isn't 1:1 in terms of how hooks work for prior versions. The vote entity comes with the normal entity hooks, which act on individual entities, rather than a group, as was the case when using something like votingapi_delete_votes() previously. You also don't have the whole $criteria array thing going on anymore; I always found that to be a little awkward.

2. In lieu of the "tag" concept, which has been around in previous versions of Voting API, there are now vote types — i.e. bundles for the vote entity. See tests/modules/votingapi_test/config/install for an example definition.
3. I dropped the idea of having a "value type" for votes to simplify a bit, so all votes act more or less like the "points" value type did previously. If you wanted a "percent" type of vote, you'd just ensure to add votes between 1 and 100 and then interpret from there. This is just a first step, so that concept could be reintroduced if necessary.
4. Vote result calculations are defined using the Plugin API (e.g. src/Plugin/VoteResult/Average.php).

This implementation is only meant as a starting point/rough draft/conversation starter, so I don't expect all my implementation decisions to be the best choice. Some parts of Drupal 8 are still a little in flux, and I'm learning all this new stuff, just like you. ;)

Some things that should probably receive more thought:

• Should vote results be entities too?
• SQL index choices for the votes and results.
• And, of course, more documentation, once things are stabilized.

There are even some tests to make sure that things were in reasonable working shape.

Adding a reference to an issue where we can get some good ideas to add during d8 port.

I really see no actual profit in making votes and entities, path aliases is a nice example in core how to do that.
old procedural API could be left as @deprecated

I think using entities for votes will not scale well. Turning it's data into entities would bloat what should be light and simple to calculate and add/remove, IMHO.

entity wrapper in 8 is small so entity could be inherited from EntityInterface directly or entent entity with own storage
profit - access with entity_query and aggregation

Yep, it's certainly possible that using entities is a bit too heavy. (I didn't do any performance testing to see how it much it might be impacted at large volumes. There were a number of performance criticals being worked on at that point, so I wasn't sure that results would have much meaning.) I was definitely exploring some of the different APIs in D8 with this patch, so not everything in there may be viable.

At any rate, I was mainly trying to help get the ball rolling. I don't believe I'll be able to continue development effort any further, so anyone else can feel free to take the reins.

I'm starting to work on this, with another guy helping me, and we are supposed to have it working in less than 2 weeks, so our goal is to make a 1 = 1 port from D7 version to D8 apis. I'll keep exactly the same data structure, etc. I'm going to test @kevin.dutra code, for sure, but as I have much votes on the current data structure, i'll need to check what costs me more: develop or migrate the data.

I'll keep posting things here.

I tried to purely upgrade D7 version, like I said(1 = 1 port) and also compared it to @kevin.dutra's code. His code is more OO and uses more D8 concepts, what is good, but it sounds more like a new version than a port, so i'm not sure if it's the best approach for now.

Is anyone actually working on this module port to D8 to give some hints?

I just created a BOF on Drupalcon Barcelona to discuss about Voting API for Drupal 8: https://events.drupal.org/barcelona2015/bofs/voting-api-drupal-8-how-do-...

Would be great if some people could be there to share experiences, problems, ideas and, why not, code.. hehe

As a co-maintainer of Advanced Poll https://www.drupal.org/project/advpoll I'm watching this thread with interest.

The tyranny of distance keeps me from Barcelona. I wish you a productive BoF!

A BoF can help, but I think the BoF can use some preparation. I commented on you BoF proposal.

@Sutharsan I never started a BoF, to be honest, and participated in only one, so please give feedback if it's not the best place to such conversations.

BTW, the module is coming to a usable version pretty soon, as i'm working on it daily(despite only partial time). I ended up combining what @andy.post and @kevin.dutra, and now i'm creating what is missing to have the basic features from D7 version, but already with some interesting concepts from D8.

Our question about using entities being "heavy weight" was great explained on http://drupal.stackexchange.com/questions/170062/when-to-use-basefieldde..., so i'm actually building with vote and vote_result as what D8 call "native entities".

You guys can check the development on https://github.com/pedrorocha-net/votingapi/tree/8.x-1.x

The module seems to be working now. It's already with a basic test suite to help us in this process.

I also created a migration from D7 for it, but needs to wait a little more to have D7 users and nodes migration inside Core release. Probably the next beta will have it, as some patches for it are near to be commited.

Now i'm going to extend Voting API 8.x with my other module, Like & Dislike(http://drupal.org/project/like_and_dislike), then i'll be able to really test this 8.x port in production.

Is there any maintainer of Voting API looking at this thread? What is the best way to evaluate this port to actually become Voting API 8.x?

updated IS with link to GH

Another drawback of entity system that tables could be altered and entity loaded from a set of tables.
So translation and "caches" should be disabled without ability for content translation module to alter entities schema.

We actually need to gather a list of modules that depends on the module.
That will allow to investigate use cases so we will understand what bottlenecks in entity usage.

Right now only recalculation could be an example to check the performance.

Looking at current code I'd suggest to set static_cache, render_cache, persistent_cache, translatable annotations to FALSE

Now that i'm getting more used to @ContentEntityType, i'm really excited with this new API on D8, as we have many benefits right out-of-box from using Entity API and it doesn't seem to bring any overhead. In fact, my project didn't even need my other module(http://drupal.org/project/like_and_dislike) extending Voting API anymore, because the API is much easier to deal with while using Entity API.

I'm not into the details about those drawbacks @andypost mentioned, so please someone with information give some feedback here.

My main doubt now is about Vote Tag becoming Bundles or not. I think it's working perfect now with Tags as we have on D7, but maybe using Bundles we can bring benefits for other modules extending Voting API, like Rate, etc. An Entity Type and it's Bundles integrates better with other Drupal systems, and also open room for improvements like Votes with Fields(good for projects where votes are part of a workflow with more data to be detailed while voting).

About recalculation, one of the features i'm wanting to develop after this initial definition gets done is to remove the whole recalculation on every new vote, working with incremental changes. My idea is to do like I did on https://www.drupal.org/project/datawarehouse

@andypost, about the annotations, are you suggesting it for Vote, VoteResult or both?

@pedrorocha Would you mind posting more details about how you reproduced the behaviour of your "like_and_dislike" module with you 8.x version of VotingAPI. I need to dig into this, and of some work have already be done there, it would be awesome.

Thanks.

@Haza, my excitement while learning D8 and porting the module made me say it wrong: I didn't need to port like_and_dislike module because I actually combined the JS part of it(that handle the clicks on the interface) into one of project's modules. The code needed was really smaller, but it needed some pieces indeed.

After some discussion with Kris Vanderwater on Drupalcon Barcelona about architectural approaches to go(Plugins, Entity Types, Bundles), we came up with the decision that Vote Types("Tag" on D7) would give much power for the module becoming bundles.

I worked on it in the Friday Sprint and during the weekend, so it's already completed :D

I also created the Like & Dislike module 8.x branch to be a sandbox and reference on how to extend Voting API 8.x, and it's already working.

As I really need this module, I have it done and working in production, and doesn't seem to have much engagement on this issue, I asked to co-maintain and take care of 8.x branch.

Awesome ! I'll test you "Like & Dislike" module, and if I find anything about it, I'll post some issues in it's issue queue.

Thanks !

The module is going through the abandoned modules process and is waiting for ownership transfer(https://www.drupal.org/node/2574857#comment-10428223).

And here we are! Voting API 8.x-3.x release created.

https://www.drupal.org/node/2584415

The code was changed a lot and I don't have an easy track of what came from where, but @andypost and @kevin.dutra helped a lot with their code also.

So, for now, anyone that can test and give feedback, would be great. Right now, the only compatible module is https://www.drupal.org/project/like_and_dislike.

I'm closing this issue, as we already have the port created, so from now on, please create issues pointing to the new branch.