repeated warnings

The RSS issue is addressed in #1490566: Views RSS support missing

The other strict warnings are probably because that handler needs to be rewritten -- it was copied pretty much directly from Views 6.x-2.x

But the word "RulesEventSet" doesn't appear anywhere in the module, so I'm not sure where that's coming from. Line 171 of that file is the closing curly-brace of that class, followed by just a blank line before the end of the file, so it's not a very descriptive error.

am getting similar warnings after creating a VIEW that includes status TAGS:

Strict warning: Declaration of statuses_tags_views_handler_filter_has_this_tag::op_equal() should be compatible with that of views_handler_filter_string::op_equal() in require_once() (line 11 of C:\xampp\htdocs\DRUPAL\sites\all\modules\CONTRIB\social\statuses\submodules\statuses_tags\views\statuses_tags_views_handler_filter_has_this_tag.inc)

Strict warning: Declaration of statuses_tags_views_handler_filter_has_this_tag::op_word() should be compatible with that of views_handler_filter_string::op_word() in require_once() (line 11 of C:\xampp\htdocs\DRUPAL\sites\all\modules\CONTRIB\social\statuses\submodules\statuses_tags\views\statuses_tags_views_handler_filter_has_this_tag.inc).

Strict warning: Declaration of statuses_tags_views_handler_filter_has_this_tag::op_regex() should be compatible with that of views_handler_filter_string::op_regex() in _registry_check_code() (line 3080 of C:\xampp\htdocs\DRUPAL\includes\bootstrap.inc).

these spewed relentlessly (about 30 times) on the system message & dlog.

i am on a set up with

DRUPAL 7.22
STATUSES 7.x-1.0-beta2+6-dev
CHAOS TOOLS 7.x-1.3+2-dev
VIEWS 7.x-3.7

the main distribution is PANOPOLY (which is also acting up due to Status).

Same thing to me, first after enable an OG context module it shows a fatar error: Class 'RulesEventSet' not found at statuses_tags_views_handler_filter_has_this_tag.inc

After disable the module it keeps showing the same kind of error seen above.

added all noteices

I just now got these "strict warnings" below. The only thing I did prior to is install and enable these modules:

• date_ical module enabled
• date_ical module installed
• calendar module enabled
• calendar module installed

=================
STRICT WARNINGS
=================

• Strict warning: Declaration of statuses_tags_views_handler_filter_has_this_tag::op_equal() should be compatible with views_handler_filter_string::op_equal($field) in _registry_check_code() (line 3179 of /includes/bootstrap.inc).
• Strict warning: Declaration of statuses_tags_views_handler_filter_has_this_tag::op_contains() should be compatible with views_handler_filter_string::op_contains($field) in _registry_check_code() (line 3179 of /includes/bootstrap.inc).
• Strict warning: Declaration of statuses_tags_views_handler_filter_has_this_tag::op_word() should be compatible with views_handler_filter_string::op_word($field) in _registry_check_code() (line 3179 of /includes/bootstrap.inc).
• Strict warning: Declaration of statuses_tags_views_handler_filter_has_this_tag::op_starts() should be compatible with views_handler_filter_string::op_starts($field) in _registry_check_code() (line 3179 of /includes/bootstrap.inc).
• Strict warning: Declaration of statuses_tags_views_handler_filter_has_this_tag::op_not_starts() should be compatible with views_handler_filter_string::op_not_starts($field) in _registry_check_code() (line 3179 of /includes/bootstrap.inc).
• Strict warning: Declaration of statuses_tags_views_handler_filter_has_this_tag::op_ends() should be compatible with views_handler_filter_string::op_ends($field) in _registry_check_code() (line 3179 of /includes/bootstrap.inc).
• Strict warning: Declaration of statuses_tags_views_handler_filter_has_this_tag::op_not_ends() should be compatible with views_handler_filter_string::op_not_ends($field) in _registry_check_code() (line 3179 of /includes/bootstrap.inc).
• Strict warning: Declaration of statuses_tags_views_handler_filter_has_this_tag::op_not() should be compatible with views_handler_filter_string::op_not($field) in _registry_check_code() (line 3179 of /includes/bootstrap.inc).
• Strict warning: Declaration of statuses_tags_views_handler_filter_has_this_tag::op_shorter() should be compatible with views_handler_filter_string::op_shorter($field) in _registry_check_code() (line 3179 of /includes/bootstrap.inc).
• Strict warning: Declaration of statuses_tags_views_handler_filter_has_this_tag::op_longer() should be compatible with views_handler_filter_string::op_longer($field) in _registry_check_code() (line 3179 of /includes/bootstrap.inc).
• Strict warning: Declaration of statuses_tags_views_handler_filter_has_this_tag::op_regex() should be compatible with views_handler_filter_string::op_regex($field) in _registry_check_code() (line 3179 of /includes/bootstrap.inc)

I just disabled the "Statuses Tags" module for now

I just wanted to post a couple of notes, based on my install.

1) These strict warnings appear to be coding standards errors coming from PHP, as of 5.4(?). From what I read, there is probably a function call that needs an argument appended/prepended or something. I'll see if I can sort out the specifics and try to contribute a patch.

2) Even with the errors, statuses tags appear to be working properly. I get the errors one time, on saving a statuses view, and they go away after a single page refresh.

I'm attaching an attempt at a patch. It applies for me and the repeated errors are gone. Additionally, hashtag suggestions and the view at /tags/tagname are both working, which is about the extent of what I know to test and/or need to test.

Please note that I'm new to patching, and new to statuses, so it's (extremely) likely that I missed something.

Details: It appeared that the views_handler_filter_string() class had changed in updated versions of Views, and only takes one argument now, but the statuses_tags_views_handler_filter_has_this_tag() was passing two arguments. The second (culprit) argument was "$db_or", which appeared(?) to allow chaining together query conditions. I removed the argument from the calls to the class functions and initialized it instead inside of each functions. I'm sure there are consequences of this that I don't yet know, but it appears to be working for my own, limited, use case.

Also, please refer to comment #8, point 1), with regard to why the errors may suddenly be appearing: upgrading PHP to 5.4+.

Thanks for the patch, jweirather. The purpose of the $db_or variables (and the reason for providing the class in the first place) is to allow specifying which tag types (e.g. @mentions or #hashtags) to include in the query. Most likely D7 Views has a better way of doing this, but some investigation will be required before that code can just be removed.