Views handler is broken (Views 7.x-3.x-dev)

Subscribing.

Hello,

Sorry but I didn't understand your comment :). What do you mean by "subscribing"?

@bizzz12345: hello, welcome to the community :-)
When a person want to "watch" and be automatically informed about developments in a certain "issue", we need to post "something" so that we are "subscribed" to it. After that, it will pop up in the activity list on the user dashboard whenever someone is updating it with new comments, or changing its status, etc. So if we have nothing in particular to "say" or comment on, we just type "Subscribe" or the like. Some combine that by typing "+1" to show that they are in favor of whatever is the main suggestion. Many "+1" comments are actually just subscriptions...

This is not an ideal solution, as "subscribe" posts by themselves will make the topic pop up in the activity queue of all current "subscribers", stealing their attention even if nothing of interest has happened. Many of us are annoyed about this, but we have as of yet no other way to follow an issue easily when we have nothing of value to actually comment about.

Ok ok :) now it's clear. Thank your for the explanation.

I am getting a slightly different error (but probably the same cause):
Strict warning: Declaration of votingapi_views_handler_field_value::element_type() should be compatible with that of views_handler_field::element_type() in _registry_check_code() (line 2789 of D:\Collaboration\Apache Software Foundation\Apache2.2\htdocs\drupal7\includes\bootstrap.inc).

Just change in votingapi_views_handler_field_value.inc

// function element_type() {
function element_type($none_supported = FALSE, $default_empty = FALSE) {

Cheers

subscribing

solution did not work for me (testing with view that also filters content by feed item). made sure voting for comments was not supported as readme suggested that views integration for comment-votes was not supported.

also i am using the stable 7.3.0-rc1

and the rate module as well but the problem is similar to eglobal's

Im getting this along with a system/ajax error with the 'call' method being undefined whenever I add a new view.

I got it to work when I changed it to:

// function element_type() {
function element_type($none_supported = FALSE, $default_empty = FALSE, $inline = FALSE) {

Thanks, that worked for me too!

Thx, did the trick for me. I was on 7.2.4

does this call for a new release? (critical/views related affects lots of sites)

what did you guys do with /return 'div';/ part?

Committed; this is in the dev snapshot and will be part of the next release.

function element_type($none_supported = FALSE, $default_empty = FALSE, $inline = FALSE) {
    return 'div';
  }

there is no this fix in dev or final release. pls add

Indeed I still get the error.

Strict warning: Declaration of votingapi_views_handler_field_value::element_type() should be compatible with that of views_handler_field::element_type() in require_once() (line 8 of ...\sites\all\modules\votingapi\views\votingapi_views_handler_field_value.inc).

Changing from:
function element_type($none_supported = FALSE, $default_empty = FALSE) {

Changing to:

function element_type($none_supported = FALSE, $default_empty = FALSE, $inline = FALSE) {

Worked for me.

#23 worked for me!

Patch has been added to #1244850: No way to avoid this warning - Strict warning: Declaration of votingapi_views_handler_field_value. Posting the patch file here and marking the other issue as duplicate as this issue has more of the relevant details.

@eaton: what was actually committed in #19?

The patch in #26 by @jaydub solves the error. Tests for views and votingAPI runed and passed.

Fix committed and in the current dev-branch. I plan to make a bug-fix release that also contains other fixes within the next week.