Several errors when trying to reach "Configure Views" for adopted table.

Line 143 is:

              $current_handler = get_parent_class($current_handler);

It's a while loop that goes until it reaches the Views base class:

            $finished = FALSE;
            while (!$finished) {
              $current_handler = get_parent_class($current_handler);
              if ($current_handler == 'views_handler') {
                // We've reached the top; don't add the root class to the list.
                $finished = TRUE;
              }

In theory that should work because every Views handler descends from that. But maybe you have modules that break that pattern?

Can you debug it to print out the current class so we can see at which actual class it falls over?

Aha! Managed to reproduce this while investigating your other bug.

It's views_handler_filter_float which is causing the infinite loop. And that's because that class no longer exists in Views 7.x-3.x.

Not sure what you're meant to use instead... but our module code is mentioning it in the helper for hook_views_data(), and so that's what's causing your views to fail, and also what causes the loop here since the function to get the form options is digging in hook_views_data() data... from which is gets a class that doesn't exist.

- #1412014 by joachim: Fixed use of non-existent Views filter handler class.

Committed and pushed.

You'll need to clear your cache for this to take effect as the bad class will still be somewhere in the Views data cache.

Did you clear your cache? You might need to clear it more than once.

Which module does that come from? I can't find that anywhere on my system.

(BTW debug: you can just do something like print $current_class . '<BR>'; and see the list in your browser.)

Hi,

I had a similar infinite loop issue with external tables which I tracked using netbeans debugging to 'views_handler_sort'

I fixed by adding it to the if statement in data.views.inc around line 150.

if ($current_handler == 'views_handler' || 'views_handler_sort' ) {

Don't know enough about views handlers to know if it is the correct fix for everyone so use with caution.

Rich

I have been using and testing this module a bit. I am actually presenting on it at Capital Camp in 12 hours (:

The code edit in #10 works for my needs and I am including that as a patch to be ported unless a different solution is desired.

Thanks for your work with this module.

But:

class views_handler_sort extends views_handler {

so if you get to views_handler_sort you're only one step away anyway.

get_parent_class() will return FALSE if it can't find the class definition for the class name you provide. This will happen if a module fails to add its Views' includes to the files[] array in the module .info file.

Here's a patch for data.views.inc. I'm not sure what the pitfalls are of using is_subclass_of but it makes for simpler code.

Perhaps there should be an 'else' that throws a warning if it encounters a views_handler it can't find?

I'll file a separate issue/patch for the missing files[] definition in data_node ;-)

Woops, here's a better patch not specific to my drupal install~

> I'll file a separate issue/patch for the missing files[] definition in data_node ;-)

Oh, was that us? Whoops!!! Yes please, let's get that fixed right away. Though isn't data_node not yet upgraded to D7?

Also, your patch will remove a bunch of classes from the list, for the reasons given in the comment.

My understanding is this.

The patch in #15 is no good because it doesn't collect all possible handlers.
The current code is no good because it goes into an endless loop if the class definition can't be found (something broken in some other module?).

So here is a patch that fixes the problem.
I think it needs a little improvement to give a warning if the class definition can't be found because that means there is a broken module somewhere.

So this fixes one of my problems.
Now to find solutions to the multitude of others :-(

@davew You are correct!

I've been busy so I forgot to post this follow-up patch. It should capture all classes that derive from views_handler and creates a watchdog notice when it can't auto-load the parent class.

@krlucas Thanks for that.

I have applied the patch you posted and can confirm it works.

What I'm not understanding is why does your patch result in more choices in the list of handlers than mine did. Logically they are the same.

The watchdog notices are great. I can now see that the date API has a broken ancestry which might be the root of my overall problem.

Thanks again.

+++ b/docroot/sites/all/modules/contrib/data/data.views.inc
@@ -140,17 +140,28 @@ function data_get_views_handler_options($type = NULL, $reset = FALSE) {
+              switch($parent_handler) {

Needs a space after the switch -- check coding standards.

More generally... hmmm I don't like to babysit other modules' broken code. Has someone filed a bug on Date API?

Woops.
Ah, spoke too soon in #19.
The problem the watchdog is reporting is not a fault of the date API at all.

Turns out data is returning a default of 'date_api_filter_handler' if the date_api module is installed. Problem is date_api doesn't contain such a handler. In fact nothing does.

I'll open a new bug report for it.

Doesn't solve my overall problem but gets me one step closer to a solution.

@davew1970 I'll try to figure out why my patch provides more handlers. Yeah, data.views.inc hardcodes "date_api_filter_handler" in data_get_views_handler(). Should probably be "date_views_filter_handler" but if babysitting other modules' code is a concern maybe it shouldn't be provided as a default at all.

@joaquim Sorry I missed the space. Would you prefer not to have the watchdog notices?

Forgive me if I'm speaking out of turn.

Please keep the watchdog notices. They are so useful.

To a certain extent this module already babysits other modules code. It reports on schema mismatches and data tables that aren't known. Basically situations that shouldn't happen.

And its great as a rapid development tool too. Providing code to create a schema for a module.

Just my 2p

Here's the patch again with the space.

@davew1970 I quickly tried your patch and mine and didn't see a different in the number of returned handlers.

I think it was a cache thing. Sorry.

@krlucas I know this is the wrong place but.
I want to move forward with my application and quickly. I have problems blocking this which I need to resolve. The immediate problems are related to the MySQL datetime type.
Is there somewhere we can talk about this?

> To a certain extent this module already babysits other modules code. It reports on schema mismatches and data tables that aren't known. Basically situations that shouldn't happen.

Fair point. You've convinced me :)

Patch applied.

Issue #1412014 by krlucas: Fixed infinite loop when trying to compile list of views handlers."

BTW, for future reference, to make a patch for contrib modules within your own project's git repository, stand in the module folder and do:

$ git diff --relative .

(see https://github.com/joachim-n/git-aliases-drupal for other git tricks.)