Make OG HEAD compatible with new Views API

I tried this out and it is pretty close but there are still some problems. I can get to the Views list and the og views show up on the list and can be edited.

1) in the file og_views.views.inc $date['og_uid']['is_manager'] should be using the new name for the handler, 'og_views_handler_is_manager' or you get a 'broken handler' message.

2) When I try to view the og directory, I get a message 'Class 'views_handler_field_numeric' not found in ...og_views_handler_field_og_post_count.inc on line 5.

That second message indicates that the parent handler isn't getting included correctly. The code looks like it is set up right so I don't know why that is broken. The parent is correctly declared in the views_handlers hook, so it should be working.

3) Nothing seems to be actually generating queries. That could be because the handlers aren't getting found, so fixing #2 may take care of that.

I don't have any more time to spend on this right now, but thought I'd add those observations.

+function og_views_views_api() {
+  return array(
+    'api' => 2,
+  );
+}

This probably misses

'path' => drupal_get_path('module', 'og_views') . '/includes',

(if that's where the new handler files are added)

Er, scratch that, that would be if the hook_views_plugins() etc implementations lived in a separate file.

Nope, you're right. The files *are* in an 'includes' subfolder. That's what's missing. I added that and my problems went away.

I'll add that and my other fix in and roll a new patch.

I can't get a patch to include all the new files as the original did, so maybe backdog can re-roll his patch.

Add the change in #4 and rename the handler for $date['og_uid']['is_manager'] to use the new name and things should be working.

how can I help with the module?

One more change is needed. If you change the path in hook_api(), which you must, you also have to move og_views_views.inc into the includes folder along with all the other .inc files or you'll get messages about missing handlers.

With that last change everything works.

Agh!! I take it back, if you move that file the broken handler messages go away, but the views quit working.

I don't have any more time to mess with this now, but it's a path issue, one way or another. You'll have to play around with placing files in different locations and changing the way you declare the paths, then test which combination produces no 'broken handler' messages and creates the right queries.

[Edit] We cross-posted. If you got that much working you got further than I did.

Thanks for your work, all. I'm hoping someone will review this until is RTBC. I will be sure to commit quickly at that point.

About the search and file library Views depending on other modules - see http://drupal.org/node/279257. I am waiting on Views2 to fix it like Views1 did.

Removing the _numeric part of the class name is *not* the right fix. That means you're extending the wrong class. It fixes the error because the class you really need is not available, so if you put the right class back, you're back to the original error I was finding.

Yes, I also noticed a few views that generated errors because modules were not enabled. The file view won't work if upload module is disabled. So there are a few places that need to do some module_exists() checks before enabling those default views.

Found it!!

It's a typo, in hook_views_handlers() we have:

      'og_views_handler_field_og_post_count' => array(
        'parent' => 'views_handler_filter_numeric',
      ),

but it *should* be:

      'og_views_handler_field_og_post_count' => array(
        'parent' => 'views_handler_field_numeric',
      ),

Fix that and fix the class name that you altered to avoid the fatal error and it might be working right :)

This gets rid of all the missing file and broken handler messages and I can go into Views and edit and preview my views with no problem. I would say this is ready to commit.

Looks like you guys are all making good progress on this - and thanks for all your efforts.

I'm having trouble applying the patch though. It looks like the #17 patch requires the module to already be patched with previous patches...? Is this correct? If so what patches do I need to apply and in what order?

Better yet... anyone got a patch that will update from the module as downloaded all in one go?

Thanks again

P

No, the patch works fine applied against the current HEAD of og. If you're having trouble, just sit tight because I suspect moshe will quickly apply this patch and then you'll just have to get the latest HEAD.

Seems to be working well. I have one minor gripe - too much 'og' prefixing. I took a look at how Views handles its comment handlers/fields at views/modules/comment and its filenames are not prefixed by comment_. The names are just views_handler_field_comment_depth.inc, for example. So, ideally I'd like to see

1. remove 'og_' from the front of all files in og_views/includes
2. rename the classes within those files as per #1
3. rename classes in hook_views_api as per #1

If noone gets around to this task, I will probably just commit whats here.

I fear that i have too much OG prefixing in the UI as well for field names and filter names and so on. Thats for a different patch.

moshe : see #298823: Views integration using Views' namespace in CCK issue queue
As a result, CCK does now prefix all its handlers with content_...

Very well then. Committed. Thanks all.

Sorry to be thick but how do I get the fixed version? The downloads on the module page are still "old" version!

You wait up to 12 hours. Thats how often packaging happens for dev snapshots

Thanks.... off to look up web sites on how to be patient!

lil error:

/og/my

I get some weird text:
OPML feed containing feeds from all your subscribed groups.', array('!url' => url('og/opml'))); ?>

else, seems to work so far. Great work.