Port OG Panels to D6

sub

Here's an initial patch. Seems to work so far w/dev versions of og, views and panels.

I focused initially on refactoring the hook_menu implementation, and then on minimal changes to the form functions so that the module would function again.

Feedback welcome!

Thanks ... I had a quick read of this.

• + 'access callback' => 'user_access',. Not needed. Thats the default.
• og_panels_menu_alter(). Only alter the properties that need altering. I think you can leave access callback, access arguments, and type alone.
• og_panels_menu_alter(). I think we can only hijack the page callback during specific instances. The problem with the hijacking in the patch is that we always fall back to node_page_view($node). Thats gonna screw folks who did regular panel pages for specific nodes - we are hardcoding the core drupal callback for this important path. I think you will have to dig into the Panels D6 code to see how they are handling this selective hijack issue. talk to sdboyer and merlinofchaos. This is tricky stuff. In the end, it might be really hard to do this right, so we won't (in D6). but lets try.

As per some discussion in #drupal-dev, the last point Moshe raised above will be addressed in the short term by having og_panels.module specifically register a menu callback for every group node that's implementing og_panels.

It's not a fully scalable solution, but works for now.

Here's another version. I needed to refactor the top of og_panels_page since we could no longer use %node to pass in pre-loaded objects. Should still work, though it's less pretty.

Also, still need to figure out the right time to call menu_rebuild() when a new og_panel is activated (or deactivated)....

Whoops. Here's the patch.

Downloaded and tested out the patch but received numerous "Access Denied" error messages when trying to edit any part of a new page. Looking at the code I noticed that in hook_menu numerous entries don't have an access callback

  $items['node/%node/og_panels/form'] = array(
    'page callback' => 'drupal_get_form',
    'page arguments' => array('og_panels_form', 1),
    'title' => arg(4) ? t('Edit page') : t('Add new page'),
    'access callback' => 'og_panels_access_admin',
    'access arguments' => array(1),
    'type' => MENU_LOCAL_TASK,
    'weight' => 0, 
  );
  $items['node/%/og_panels/%/view'] = array(
    'page callback' => 'og_panels_page',
    'page arguments' => array(3, 1),
    'type' => MENU_CALLBACK,
  );

note how $items['node/%node/og_panels/form'] contains

  'access callback' => 'og_panels_access_admin',
  'access arguments' => array(1),

but $items['node/%/og_panels/%/view'] does not.

I'm not sure what the access controls are supposed to be and I don't have time at the moment to really dig into old code to see prior permissions but wanted to point out that the quick fix of defining permissions on
$items['node/%/og_panels/%/view']
$items['node/%node/og_panels/%/panel_layout']
$items['node/%node/og_panels/%/panel_settings']
$items['node/%node/og_panels/%/panel_content']
$items['node/%node/og_panels/%/panel_delete']
gets the administrative interface working.

PS: POTX complains on the construct 'title' => arg(4) ? t('Edit page') : t('Add new page'),

So, for what it's worth, taking the HEAD (on 21 Oct) and applying the 2nd patch, then updating with jredding's code, I get the admin interface. I do not however get the panel as my group home page.

I should add that I haven't the faintest clue what I'm doing, but I'm eager to help with debugging/fixing this module. I'll monitor this thread/issue and jump in whenever I think I can help, or have something to offer. Feel free to make requests for me to test things also.

Colin

Re #3, I used hook_menu_alter to add in the og_panels stuff, and send the previous callback as an argument to og_panels_node_page_view so it could be called as a 'fall through'. But the I'd guess og_panels_node_page_view runs on every node/%/view page

What's wrong with the 'hack' approach?

I've fixed up the og_panels.module file, so that at least some of the functionality works. You can create pages and add the panel content. Still haven't tidied up, or converted the install file. Lots of work to do!

I'll subscribe.

I am eager for this module asap. Would a little extra seed funding help to speed things up?

Hello all and thanks for the effort to port this module in D6!

Anybody knows how long (aprox.) will be the deffinitive portation?

Thanks!

edward and sunescan.. nobody knows the exact time frame of things as they depend on who has the time to work on it.

If you can pay for a developers time, contact the maintainer of the project and ask about their availability, an estimate, etc.

josh - any update here?

here is a patch which adds schemapi to the install file

Anyone has to overview which should be done, and could be done?

I added both the patch and the install file so there would be no problem to use it

About the "descriptions" in schema - please use correct case and also use periods on sentences end. Additional use single quotes whenever possible. Indention seems also an issue here. Sum up - CNW.

here is a better version, hopefull better style

Nothing attached to your post #19.

damn

here is the patch

So, to use this patch:

1. Disable og_panels (if possible).
2. Uninstall og_panels by deleting its subdirectory from the og directory.
3. Untar the og package.
4. Apply the patch.
5. Move the og_panels subdir back to the og directory.
6. Run update.php
7. Test

Is this correct? Thanks.

subscribing

I'll be getting a new pass on this out soon. Sorry for the big delays, everyone.

subscribing

subscribering.

subscribing

@joshk #24: Are you able to give us any idea when this pass might be out? Before Christmas? Thanks for all your work!

+1

Just been playing with the patch in #21, panels alpha3 and the latest og (renaming the .inc files) and og_panels seems to be working without issue so far... only scratched the surface mind, wouldn't want to post false hope or bad practice here. Also, does anybody know what the future holds for og_panels with the panels 3x branch now in play?

Hi, are we supposed to use #11 with #21, or #11 with #21 and #17 og_panels.install.txt 2.78 KB?

Can somebody create a zip please?

here is a patch of the changed module file/info and the install file

and a tar.gz file, because we i use good free software

We should unt'ify the schema strings as it is planned to removed this from D6 core, too. D7 patch have already been committed. My free 7-Zip also have .ZIP and the great .7z that really gives you the very smallest files and is also free and open... :-)

you mean with that removing t strings out of the install file?

i liked 7-zip a lot on the good old times on windows.

But on linux i use gz or bzip because its very easy to use together with the gnu tar until

one advantage of tar.gz is that everyone on do can use it, because all core and all contribes all packed like this :)

Thanks dereine, but on my module page it says:

Organic groups panels. NOT COMPATIBLE WITH DRUPAL 6 YET. Enable group admins to create panel pages.
This version is incompatible with the 6.8 version of Drupal core.

I can't install this.

You need to edit the og_panels.info file.

Remove the semicolon from the following line:
; core = 6.x

I get the following errors:

    * warning: include_once(./sites/all/modules/og/modules/og_panels/includes/groupcontent.inc): failed to open stream: No such file or directory in /hsphere/local/home/cabanga/edu.cabanga.org/sites/all/modules/og/modules/og_panels/og_panels.module on line 665.
    * warning: include_once(): Failed opening './sites/all/modules/og/modules/og_panels/includes/groupcontent.inc' for inclusion (include_path='.:/hsphere/shared/apache/libexec/php5ext/php/') in /hsphere/local/home/cabanga/edu.cabanga.org/sites/all/modules/og/modules/og_panels/og_panels.module on line 665.

The groupcontent.inc is the main og includes directory, so i don't know why drupal expects to find it in the og_panels includes directory.

Here is the code resulting in the error message:

include_once './'. drupal_get_path('module', 'og_panels') .'/includes/groupcontext.inc';

There are a few instances of this which I needed to change to be found in the main og includes directory.

Attached is what works for me. (I'm on my mac, so zip is easiest)

These patches seem good enough to incorporate into the dev branch. This way people can begin testing for more obscure bugs in the code.

subscribing...

you mean with that removing t strings out of the install file?

We should not remove the documentation strings at all... only the t() around the string. See #332123: Remove t() from all schema descriptions.

here is a patch which includes the two stuff and the translation stuff of hass

I just realized I have no idea how to configure this har har. I turned it on and selected various panels. Now what?

I know how to use panels to replace group nodes, but where does this module come into it? So I suspect that's not the next step?

A few comments/bugs about the latest patch:

1. Also do not t'ify string in hook_menu...

2. There is an unsupported 'title' construct (panels fixed the same issue a few weeks ago...). For verification you should run POTX and/or coder on the modules code.

+  $items['node/%node/og_panels/form'] = array(
+    'page callback' => 'drupal_get_form',
+    'page arguments' => array('og_panels_form', 1),
+    'title' => arg(4) ? t('Edit page') : t('Add new page'),
+    'access callback' => 'og_panels_access_admin',
+    'access arguments' => array(1),
+    'type' => MENU_LOCAL_TASK,
+    'weight' => 0,
+  );

3. Shouldn't we better remove the //krumo lines?

4. We should rename t('Group page created.') to t('Group page have been created.')

i didn't created the patch

so here i fixed the first three problems

someone should comment to 4, because i'm not a native speaker

if 4 should be done:
t('Group page updated.') should be changed to t('Group page have been updated.')

forgot the file

which patch should i apply to which branch of code to use this module? both og_panels_current_6_1 and og_panels_current_6_2 to HEAD?

HEAD... the file naming of the patch is misleading.

And both og_panels_current_6_1 and og_panels_current_6_2? or just og_panels_current_6_2?

I have applied just og_panels_current_6_2 to head but the error in comment #37 still exists.

Can someone merge all the necessary patches and make any updates needed to be compatible with the current HEAD?

Once we get a good patch, it should take too long for one of the main developers to add it to the CVS.

Are we close to a stable release on this? subscribing.

+1 subscribing

subscribing

subscribing

I will try to roll out a new patch based on this idea here:

http://drupal.org/node/362031

Josh, this is very good of you! We are desparate for this module!

subscribing

Another desperate user of OG_panels here!

My entire site is at hault! I need og_panels. I am dying for it.

Subscribing

i have not transitioned yet. I assume this works with panels 2 not panels 3. if anyone knows, please share.

I cannot get this to work. I installed, but I get page not found errors when viewing panels pages. And the options for OG forum include the types of content to include, but nothing else (a bunch of checkboxes).

To get some basic support for Panels 3, you need to modify og_panels_load_display() and add these lines instead of the previous panels_context_create() call.

  ctools_include('context');
   $display->context = array('og_panels' => ctools_context_create('group', $group_node));

There is no Panels 2.x out until today... why are you talking about 3.x? I have not followed panels for some time... maybe I missed something? Will 2.x final never see the light?

Subscribing

@hass: Panels 2 will never get a full release. It is being deprecated in favor of Panels 3, which is close to surpassing it already.

Michelle

subscribing

Is there anyone who could explain what the process is leaving to a release of OG Panels? Must it wait on a full release of Panels? Is there any idea at all of a timeframe?

Subscribing , desperately need this.

This is the first web page that I check each morning. I have not had success with attempting to use the above listed patches so I am determined to wait it out and hopefully a person more resourceful than me will bring this important part of OG to fruition.

re-suscribing

I was having an error coming out of the context module, which was complaining about a non-object, etc...commenting out part of og_panels_load_display() killed the errors, but generated a whole bunch of new errors when attempting to add content (none of which actually prevented me from adding content to the panel).

This seems pretty close to me, just needs some loving. Maybe we can create a Chipin widget somewhere and hire a developer to finish this off for us?

<?php

function og_panels_load_display($did, $group_node = NULL, $ct = FALSE) {
  panels_load_include('plugins');

  $display = panels_load_display($did);
  if (is_object($group_node)) {
    ctools_include('context');
    $display->context = array('og_panels' => ctools_context_create('group', $group_node));
    /*if ($ct) {
      panels_load_include('common');
      $display->content_types = panels_common_get_allowed_types('og_panels', $display->context);
    }*/
  }
  return is_object($display) ? $display : FALSE;
}

?>

Errr, I meant ctools module for the errors, context.inc.

Also noticed that I was getting a weird duplication of pages on my front page (which is a view of a single node) suggesting some funniness with the hook_menu() declaration.

Dave

Merlin says that panels 3 beta for Drupal 6 may be ready by April!

Are any of the patches here for something that will work with panels 3? Just curious if I should try it with P3?

These patches are for Panels 2 it seems. Panels 3 for Drupal 6 is much, much closer to production ready than is Panels 2.

Dave

@dwees
If you are using this module on your site , can you provide us with a ZIP , so that the rest of us try it too.

Thank you.

subscribing

Hi, I'm not actually using this. I tried to get it to work for Panels 3, but there are still too many problems which I could not sort out and Panels 3 isn't stable yet (although it does exceed Panels 2 in capability). I'm planning on going with custom theming instead, because I realized that I don't actually want my group administrators to be able to choose different layouts...

Subscribe, also using Panels 3

Subscribing too.

subscribing

Alright cool kids. Here is a patch to get OG Panels support with Panels 3. It is not an all together easy task to take the wizardry of Moshe and combine it with the wizardry of Merlin. Please review and post bugs/patches/comments.

The basic work process here was to take the latest version of the Panels 2 patch (#46) as a starting point. I changed how OG Panels was handling the group context (basically, it doesnt need it but expected it), fixed some bugs with the Page Delete functionality (had some incorrect arguments in the form functions), modified the routine to build subpages to correctly display them, and made sure to update/include the relevant CTools/Delegator function calls that were previously part of Panels 2.

I have this all working in a sandbox Drupal install and will be deploying to a few client sites in the coming weeks. It would be nice if the hook_menu stuff could be cleaned up as per (http://drupal.org/node/362031), but its more important IMHO to get people using this for real.

Great work. The patch failed for me on the og_panels.info file, so I just cleaned out the ponies dependency (the module patch was fine.) Went forward and enabled.

Created a group page and am playing with it right now without issue. Looks good so far and I'll be sure to put it through the paces over the next few days.

I've been using it for a few hours, everything is running smooth and I haven't experienced any issues, thanks a heap populist.

Bless you.

A quick code review looks very clean. I noticed that " // Add specific callbacks for og_paneling nodes" should be " // Add specific callbacks for og_panels pages". Also, please add a comment about what we are doing in the 'oh dear' section of og_panels_node_page_view().

I tried this out and after creating a new page, i started the panels display creation wizard which is good. After choosing a layout, I got to an unexpected page which told me about panels content migration as if it thought that I was changing the layout of an existing display.

Also, I could get the main node/n to be taken over by a page but "additional" pages were not immediately visible in the local tasks. I had to clear cache and then they showed up. This suggests that a menu_rebuild() is missing. Likewise, if I unpublish an additional page, it is still visible as a tab. Similarly, deleted pages still show in local tasks until menu is rebuilt.

I'll commit this after you submit the next patch. I'm hoping that populist or someone else will then tackle updating menu handling as per http://drupal.org/node/362031.

I'm not sure if this is by design but in the Drupal 5 version when you click to add content to a panel the popup included a list of Organic Group related content. Not sure if this is a configuration or code issue. I've attached a screen shot of Drupal 5 and Druapl 6

@SeanBannister - good point. It can be in a follow up patch, but we do need to make sure that the contexts and content that OG offers are working properly.

subscribe

When I can expect this patch & all things applied with OG module?

thank you dear populist
may you please attach the patched version of og_panles module -
and what it the main version of the og module
thank you very much
and best regards
ya - what about the test result?

Wondering if someone with some experience can give me some bullet points.

Have done new install of Panels3 and the above patches and am trying to set style settings for a panel = in video (http://blip.tv/file/789296) it has a 'tabs' option under 'Edit Style Settings', on a page with a URL node/xxx/og_panels/XX/panel_settings.

Should I be expecting to see Tabs - or has that option been created by some other trickery in some other module - as I am not seeing that option.

Any advice on what needs to be set up at /admin/og/og_panels

I had a page that was showing just posts related to the Group etc, but oddly once I decided to allocate one of the pages to be the 'home' page, both my pages stopped displaying the layout/content I had specified and reverted to just showing 'view-og-ghp-ron' rather than the layout i have created for each of my pages.

Seems that once i set any page to be 'home' they all think they are 'home'-type pages - when I view any of my 'non group-home' pages the links across the topo that say "
Og panels tester

* ogpanel Home Page
* Edit
* Outline
* Broadcast
* Page"

have the ogpanel Home Page greyed - I don't think this is correct behvaiour.

Unless I have made some other tweak that I can't recall, the more I try and wrangle with this the more I have to suspect that things went wrong after selecting 'home' for one of my pages. Seems to now be rendering all pages with the default OG 'home' page view - not the content I am adding (eg event custom content).

Have tried deleting all group pages - no change. May try deleting all Groups. Otherwise guess I have to reinstall and see if that clears the problem and then see if I can replicate it.

Anyone able to report success with this, after having specified 'home' for one of the OG panel pages?

Subscribing too!

My suspicion is increasingly that something fails when Delegator is enabled. Will do more testing and report back.

So if I disable Delegator I get to at least view my pages as expected. But still odd behaviour in that an 'og' panel page shows in the tab bar of Groups it doesn't belong to. IE, a page called /node/1/events is visible in the header area of a Group that is /node/7

How do I apply this patch @ #83? I used the commands
(patch < patchFile and patch fileToPatch < patchFile ) and got the following error: 'found garbage as input file'.

Can someone please upload the patched file (at #83) so that we can all test it. I'm not able to carry out a patch operation. Thank you.

tamasco - here's a copy with the patch applied. applying patches is not hard, but you'll find plenty of advice how to elsewhere.

when i applied the patch in comment 83 to the most recent -dev release, it failed to patch the .info file - easy enough to apply the fixes manually but might prevent a few people unfamiliar with patch being able to test this

so, in the aim of generating some extra test feedback from users, here is the current (as at 20th april 2009) 2.x-dev with populist's patch from #83 applied (applied patch to .info manually). msg me via my contact page if supplying a tarballed, patch applied version is not the right thing to do in this circumstance.

Thank you very much xurizaemon. I will test it and will definitely provite feedback.

hi everybody, like some of you I too am in desperate need of this module, after seeing xurizaemon comment 99 I had to test it and see if it works.

Found error while attempting to add content to a new group new panel page:

An error occurred while attempting to process /panels/ajax/add-pane-config/1/middle/views/calendar-calendar_period_5
(this error occurs when trying to add any kind of content, so the path detailed here isnt really relevant)

Im using panels 6.x-2.0-alpha3 with the latest og module and drupal installation.

do you need panels 3 to work with og panels or is it something else?

@toomeir

you definitve need panels3 and ctools/delegator to get this working.

figured it out 5 min before seeing your msg. guess thats a lesson for myself to test it before posting.

Found another bug: I added og menu and other og related blocks to the panel page but they didnt show up on the panel.
I think it is related somehow to the bug SeanBannister reported on comment #87.
seems that the panel pages dont get the context needed to know that they are a group page or something like that, cant say for sure, I sill consider myself a newbie with drupal and og.

Anybody else can confirm that behavior? and if it isnt not just my local installation then does anybody have ideas on how to fix this?

I can only repeat that turning Delegator offer has resulted in OG Panels working better than when it was enabled. Maybe somethings I haven't tried yet that will require Delegator, but with Delegator disabled I am able to create and see the OG pages

I found that when setting a panel to be the default group homepage then the og related block do show up.
now there is still the bug that hides all the og related content that you could add in drupal 5 as shown in comment #87

@peted - in #104 you say it "works better" when Delegator is not installed/enabled - can you clarify what issues you see arise when Delegator is enabled?

So what used to work with Panels alpha 4 and Patched OG with Delegator turned OFF was

> go to Group

> click on Pages at far right

> click Add New Page

> give it Title and Path then Create

> Choose Layout eg Two Col Stacked

> Next > Save

> click on Edit Content for that page

> goes to /node/6/og_panels/10/panel_content?destination=node%2F6%2Fog_panels

You could then add content and view the page eg node/6/egret and eg /node/6/robin

but then if you enable Delegator, when you go to node/6/egret you actually see only /node/6/

and if you disable Delegator it works fine again

Finally!

Updated as per Moshe's comments in #86:

* Added a bit more verbose description of what we are up to
* Added menu_rebuild() on og panel page create/delete so tabs show up right away

Will look at #362031: Ideas for dynamic tabs for OG Panels now, but I'm not sure I really see whether or not it really adds a lot of value. Maybe I'm just not grokking peter's brain storm yet. ;)

Helps to attach the patch.

Moshe reminded me of the problem on the menu side: _og_panels_nodes_menu() basically has to go and we need a better way to handle tabs.

@Joshk

Is their a particular way to apply this patch? Because I tried to apply it on the OG 6.x.2.x-dev version of 5 may 2009, but it give me back a rejection on both og_panals.module and og_panels.info files.

Using Mac OS X Terminal:

$ cd /...path to og_panals directory...
$ patch > og_panels_panels3_0.patch
$ patch failed!

Is this patch ment to be applied on another version of og_panels then I did or am I forgetting something?

Thank you in advance.

you have to use it like this

patch -p0 < filename.patch

subscribe

Hi Josh - good work, but haven't had a chance to play with this. I had the previous patch #99 working on Panels3 beta1 but only after making the following fix.

By changing og_panels.info (was line 7) from

dependencies[] = panels_views

to

dependencies[] = views_content

A quick glance at your latest patch shows it still pointing at panels_views - not sure if this will be an issue but thought I would post it in case it is relevant to others. cheers.

subscribe

@xurizaemon,
Thank you very much for providing the patched version of the file. I have tested it and have also sent you my feedback through your contact page (as recommended in your post #99). For the sake of the rest of us viewing this thread let me give the feedback here too.
It worked very perfectly for me without any issue. At first I was experiencing problems so I had to disable the delegator module. I've since created groups and used panels and views to set up the content and layout. So far there is no issue with it, though I've been using it for about four weeks now. I will provide feedback when any issue arises. Senior xurizaemon, I appreciate your effort and support. Once again thank you.

Updated version of patch (and pre-rolled tarball) which combine og-2.x-dev of May 19th with joshk's update from http://drupal.org/node/307980#comment-1546446 and reflect the rename of panels_views (panels-2.x) to views_content (panels-3.x) as pointed out by petednz. Cheers all.

Tamascon, thanks for the thanks but you've got the wrong guy, I really just typed "patch" and "tar" and uploaded work of the other people in this thread :)

EDIT: damn, even though I checked "delete" on the .tar_.gz, it didn't delete it and I can't zap it by editing my post. Those two tarballs are identical except for the extension (which I tried to de-uglify).

Even with the latest patches I still have the duplication problem with tabs created bij OG Panels.
All OG panel tabs except the homepage tab, appear on very node. Even if its completely outside OG.

Terentius - I think I had same problem and overcame it by creating a 'home page' using Pages for each Group. Otherwise it seemed that any pages that were created for a Group which did not have a 'home page' were showing as Tabs 'everywhere'. Note that at %/og_panels it says "One of your custom pages should be designated as your group home page."
let me know if this fixes your problem too

@ 119 peted - Nope! it does not work for me. No matter if I have all my Group have a tab HOME (selected as homepage on node/%/og_panels). As soon as I add another tab (via node/%/og_panels) for example "NEWS". The "News" tab appears on ALL nodes, not only other group node types, but on all nodes types.

So I have the following situation:
When you visit a group page you see these tabs:

GROUP-1 = HOME | NEWS | EDIT | PAGES (both tabs (HOME + NEWS) are created by GROUP-1 with the use of node/%/og_panels)
GROUP-2 = HOME | NEWS | EDIT | PAGES (HOME is created by GROUP-2, the NEWS tab is the one from GROUP-1)
ANOTHER PAGE = VIEW | NEWS | EDIT (The NEWS tab is the one from GROUP-1)

As if that isn't bad enough, when viewing GROUP-2 pressing the "NEWS" tab brings you to the NEWS panel from GROUP-1, thus switching group.

I hope this explains it a bit more.

Let me give you my settings and modules:
Drupal 6.12
Ctool 6.x-1.0-beta3
Panels 6.x-3.0-beta2
og-6.x-2.x-dev-PATCHED-307980-117.tgz (from above)

Anyone have some insights for http://drupal.org/node/307980#comment-1654602 ?

I would love to help test these patches, but there is scant documentation on getting all of the modules (og, panels 3, views 2, etc) working correctly together, so anyone who knows can help us help these projects.

I would be glad to document, test patches, submit patches, but some of us are struggling with getting consistent results from basic functionality, and we are probably ignorant of key facts that will get us up to speed.

@moshe

Can xurizaemon's patch from http://drupal.org/node/307980#comment-1601692 above be applied to

og-6.x-2.x-dev ?

He has added the requests you gave earlier to populist's patch in

http://drupal.org/node/307980#comment-1388214
and
http://drupal.org/node/307980#comment-1392598

in this thread.

I would love to, but it does not implement the menu hook in a scalable way. Each page is its own router item. See http://drupal.org/node/307980#comment-1049754 for our proposed solution.

Further, the patch has not tackled any upgrade path - thats needed as well.

Lastly, it can be a separate issue but someone needs to refresh all the panels content/context/relationship that og exposes. see includes/og.panels*.inc

@moshe - thanks for clarifying what the next actions are for those of us in this issue - much appreciated

Here's a brief tweak to dereine's .install patch for using the schema api

'length' for an int appears invalid and was removed, size 'normal' should suffice. ( http://api.drupal.org/api/group/schemaapi/6 )

tested and installed fine.

Patch in #125 is wrong. Schema strings shouldn't be t'ified + the patch doesn't follow drupal code style rules (indention)!

@#120 Terentius
Sorry I can't help more - all I can confirm is that I had exactly what you described - but once I had set one of the pages to be the 'home page' for each and every Group the problem of the other pages showing as Tabs disappeared. It is all working for me as I think it is meant to.

of course what I am really missing is the functionality that was in D5 which meant I could choose to make an OG page appear as a Tab.

I was able to solve the problem of having sub-pages show up everywhere by doing the following:

function _og_panels_node_access($op, $nid) {
  if (arg(1) == $nid) { // only show item if we are looking at that node page...
    return node_access($op, node_load($nid));
  }
}

I am assuming there is a cleaner way to make this happen...

This suggests you are also having the problem - which makes fact that I don't seem to have it even odder.

An update of the .install patch with t() removed from schema and @file added per Coder module

Seems a wrong status

oops you are right

Sorry, I meant to say that someone has to implement #362031: Ideas for dynamic tabs for OG Panels for hook_menu handling.

subscribing

Drupal 6.12
Organic groups 6.x-1.3
Views 6.x-2.6
Panels 6.x-3.0-beta2
Pathauto 6.x-1.1

Hi,

I am looking to see if it is possible to get OG_Panels working the the above version of O_Groups... is there a patch that can be use to get this working.

I am a Newbie so any info on how to apply the patch would be appreciated

Thanks!

Taking on #362031: Ideas for dynamic tabs for OG Panels now.

Ok, we are rocking against DRUPAL-6--2 and Panels3beta2. The big idea from #362031: Ideas for dynamic tabs for OG Panels is implemented, and the patch includes my work from http://drupal.org/node/307980#comment-1546446

Also, made a number of other updates with this patch also:

* Updated install to use hook_schema (and one instance of drupal_write_record so far)
* More sophisticated path aliasing. Basically this functions a lot like the per-node path aliasing, and allows for fully semantic urls.
* Added a way to un-set the "Use as group homepage" setting

However, I am stuck how to get that homepage setting to work in the first place. We used to just override node/% for this, but no more. Building a new task_handler for this seems like a lot of additional code, and I'm running out of gas for today. Is there an easier way? Maybe I'm being dense and can't see the forest through the trees here. Any ideas?

WIN!

I think this patch should supply all the needed fuctionality. I will test it more thoroughly tomorrow, but I put it thorugh its paces on localhost, and it's all good. Here's what's added:

• Require delegator
• Implement an uber-simple task_handler for the homepage override
• Include a default handler so it's enabled by default
• Added a hook_menu_alter and associated logic to handle user-friendly naming of that node/view tab
• Include a tgz of the plugins dir that's needed for the delegator stuff to be picked up.

Feedback welcome. I'm pretty happy with this overall. Many thanks to Earl for rescuing me from despair on the delegator front. :)

TODO:

A hook_update is necessary to bring old installs up to speed. There's the associated issue of hook_update for panels 5-2 to 6-3...

#138

Used OG version: 6.x-2.0-rc3 2009-Jun-11 255.21 KB

I get an error: warning: Invalid argument supplied for foreach() in /public_html/sites/all/modules/og/modules/og_panels/plugins/task_handlers/og_panel.inc on line 52.
On NON og nodes the view tab is labeld "Home".

Also the radio button "[] Use normal node view for group home page." is not checked by default. And causes an error for not having a homepage for your og group-node.

I applied the og_panels_menu_schema_and_delegator.patch from the og module base directory. All went well except for the info file. There still was a small error, and the changes where not applied to it. So I did the og_panels.info file by hand.

Did I applied the patch on the wrong OG version?

subscribing

subscribing

+1 sub

I'll be testing this patch in a project shortly.

Finally reviewing most recent patch

Well done!

1. clean install: warning: Invalid argument supplied for foreach() in /Users/mw/contrib62/modules/og/modules/og_panels/plugins/task_handlers/og_panel.inc on line 52.
2. When creating page, I get a screen like "There is no content in the panel display. If there were content, you would be given an opportunity to select where in the new layout the old content would be placed". Can we easily skip that?
3. " Use normal node view for group home page." Should not show if pages table is empty. Could we try replacing with a second submit button? The radio looks awkward to me.
4. og_panels_node_node_og_panels_form_title_callback(). Too verbose, no?
5. Add %node to "Allow the overriding of the default node/%node/view tab!"
6. typos: implementation (should be upper case), hook_ctools_plugin_dierctory
7. if ($tab['published'] == 1) {. Can we remove the ==1 part?
8. path_alias() does not appear in path.module AFAICT. Can't delete a page.
9. We added a call to the dreaded menu_rebuild(). Can we put a condition around that? Perhaps be more selective about our cache clear? Just hoping.
10. if (module_exists('path')) {. I prefer #access instead of if().

I hear that panels upgrades displays for us. Lets upgrade our panelscontext, panelscontent, and panelsrelationships as needed.

Thanks for the reviews, all. I will look at closing out these bugs and style issues shortly. I'm not sure what can be done about that layout page, but will see if there's a way to skip it. Everything else should be doable.

One question:

if (module_exists('path')) {. I prefer #access instead of if().

Are you saying we should use a check to user_access('create url aliases') instead? I'm slightly hesitant here because I think there's a real use case here where as an admin you don't want to give out wholesale url-aliasing permissions to users, but do want them to be able to create human-friendly paths for their group sub-pages.

E.g. for groups.drupal.org we probably don't want to let normal users hand-tool their url aliases, but we would like clean/simple urls for group pages. og_panels allowed this before as a part of how its menu system works. That's all changed, and I think what we have here (where you can use clean_url/to/group/og_panel_alias rather than node/256/og_panel_alias) represents an improvement.

Initially I'd thought maybe this should be answerable via pathauto, and probably that's still the ultimate answer, but it's a bit more work to implement a new pathauto hook, create tokens, etc.

Agreed ... All I mean is that we should do #access = module_exists('path') so that the form element is always present in $form and be more easily altered.

subscribing

@moshe in #145: understood! I'm still getting used to the #access attribute in FAPI. It's quite awesome though. Rolling a new patch (and attempting a hook_update) now.

Ok, I got through most of the comments in #143. I also found a tricky issue w/path aliases given that our src values can change frequently due to compaction. This is fixed now too.

When creating page, I get a screen like "There is no content in the panel display. If there were content, you would be given an opportunity to select where in the new layout the old content would be placed". Can we easily skip that?

This is sort of wired into how panels runs, so not easy to remove.

I still need to figure out the schema update. Too late tonight for that, but it's just a matter of adding the tab_num column and running a mass-renumber of existing og panels. I'm also not sure the right way to transition from direct sql (the 1.x version) and hook_schema.

Anyway, this patch is a lot better.

Dear joshk,

Thank you for the great effort and time you put in this.
I do have have a small request. Can you please specify (and also on future patches) on what og_panels version we have to apply the patch on?
I mean. Do we need to grap the latest OG dev version?
Or do we apply this patch (#148: og_panels_june_24_2009.patch) for example over previous patched og_panels (#138: og_panels_menu_schema_and_delegator.patch)?

Thank you.

I had some time to test the new patch. There where some things that are still not working as they suppose to. ( I know some of these issues I address where not covered in the latest patch).

1. Question: Do you still need to use the og_panels_plugins.tgz ?

2. The OG Panels homepage tab does not displays panels you add to it. It still only displays the default "mission" + "og_ron.view". On additional tabs it does work well.

3. I experienced a very strange effect on all non homepage tabs. Their breadcrumbs link to totally different nodes.

The situation is as follow: (pay attention to the node numbers)

- I have 3 pages (content_type=page). (WELCOME | ABOUT | INFO) node/1, node/2 and node/3 respectively.
- 2 OG Groups (content_type=group). "GROUP-A" (node/4) and "GROUP-B" (node/5)
- Each group has 3 tabs. (HOME | NEWS | EVENTS).

The breadcrumb of tab "HOME" from "GROUP-A" points to /og (GROUP DIRECTORY). NORMAL.
The breadcrumb of tab "NEWS" from "GROUP-A" points to node/1 (WELCOME). WRONG!
The breadcrumb of tab "EVENTS" from "GROUP-A" points to node/2 (ABOUT). WRONG!

The breadcrumb of tab "HOME" from "GROUP-B" points to /og (GROUP DIRECTORY). NORMAL.
The breadcrumb of tab "NEWS" from "GROUP-B" points to node/3 (WELCOME). WRONG!
The breadcrumb of tab "EVENTS" from "GROUP-B" points to node/5 (GROUP-B). NORMAL

It seems that if I would add another page (node/6), the breadcrumb of tab "EVENTS" from "GROUP-B" will be pointing to node/6.
Of course I tried and guess what, it did. Event adding more pages resulted that they took over the BC of the first new OG panels tab as soon as it was created.
I have no idea how this came to be. The only way I could shut down this effect was by commenting out some lines in og_panels.module, // drupal_set_breadcrumb().

I hope this helps solving some issue's.

Took another look at this. have some UX improvements which are non urgent but if someone is in the mood ...

1. New pages should be published by default, no?
2. We should add drag and drop instead of weight (can wait for a follow-up patch)
3. the reset homepage button should be to the left of save. more importantly, i wwant to get rid of this button and the column of radios for homepage. what if we add a checkbox below the table that reads 'The top most page should replace the standard group homepage.'. Should be disabled by default. I think this handles homepage much more cleanly. We'll need a new column to store this value.

subscribing

suscribing

I'd be keen to try and work on the schema update, if I could be pointed in the right direction - how are the tab_num values calculated from existing panels and what do you mean by:

I'm also not sure the right way to transition from direct sql (the 1.x version) and hook_schema.

Oops. I committed this by accident. I'll revert if this makes further development difficult.

We still have holes in the upgrade path and in panels content/relationships/context so i leave this at 'needs work'.

filed #518152: skip "there is no content" page with panels project

Hey, it seems that this is on the edge of being added to the organic groups module finally, and I'm also on the edge of going live with my site. So, I'm not totally sure what to do about this in terms of holding back. Could this be considered a week or two for completion or much longer? Could anyone give a sense of whether It would be worthwhile to hold off on going live in order to slip this in, or is it too far off to even bother with?

Hope this is not too much trouble.

OK - I did a clean d6 install to see how the tab_num values are calculated. It looks like the tab_nums are generated based on weight, and then alphabetically, with 1 being the home page.

So, purely from a sql point of view, looking at the d5 og_panels table, the sql to select the tabs in the correct order is:

SELECT * from og_panels ORDER BY nid, default_page DESC, WEIGHT ASC;

So we now have the correct order, and can then add the tab_num value to the results returned here, starting at 1 and incrementing by 1 for each record, until the next different nid, when we start at 1 again. Could we also use the default_page = 1 to indicate that we're at the next one? There may not always be a default_page indicated in the database if the panel page is the first one, so best to check if we're on a new nid, and reset tab_num to 1.

I've never created a database update for an install file but will look into it to see how to write this. Any advice would be welcome :-)

OK - I think I've got an install file which will now update an existing og_panels table - I would love some feedback on how I did it - all criticism welcome, as this is my first attempt at this kind of thing.

I also need some advice on creating the patch - the current patch at #148 og_panels_june_24_2009.patch patches a number of files, while I've only been working on og_panels.install. How do I combine my work with the previous patch? Or do I just create a patch against og_panels.install? I also changed the status to "needs review" - hope that's right.

If anyone is desperate to try it out before I get answers to the above questions, here is what I added to og_panels.install (after applying the patch at #148 og_panels_june_24_2009.patch):

/**
 * Update og_panels table and data from Drupal 5 site to Drupal 6.
 * 
 * Add the tab_num field, plus add as index, and a primary key
 * Update all existing records in the table with a tab_num value
 * To get the tab_num value we just need to select the records in the
 * correct order, then run through them, resetting the tab_num when we get
 * to the next nid.
 */
function og_panels_update_6000() {
  $ret = array();

 // Add the tab_num field
  $new_field = array(
   'description' => 'Tab number for this node_tab.',
   'type' => 'int',
   'unsigned' => TRUE,
   'not null' => TRUE,
   'default' => 0,
  );

// Setup the indexes
  $keys_new = array(
    'indexes' => array(
      'nid' => array('nid'),
      'page_title' => array('page_title'),
      'tab_num' => array('tab_num'),
      'did' => array('did'),
     ),
  );
  // Don't want did to be primary key anymore - will use nid and tab_num

  db_add_field($ret, 'og_panels', 'tab_num', $new_field, $keys_new);
  
  // Select all records in the table, order by nid, default_page and weight
  $result = db_query("SELECT * from {og_panels} ORDER BY nid, default_page DESC, WEIGHT ASC");
  $old_nid = 0;
  $tab_num = 0;
  while ($row = db_fetch_object($result)) {
   $tab_num ++;
   $current_nid = $row->nid;
   $did = $row->did;
   // Reset the tab_num value to 1 when we move to the next node
   if ($old_nid != 0 && ($old_nid != $current_nid)) {
    $tab_num = 1;
   }
   $ret[] = update_sql("UPDATE {og_panels} SET tab_num = $tab_num WHERE nid = $current_nid AND did = $did");
   $old_nid = $current_nid;
  }
  
  // Can only add the new primary key here because there are were no values in
  // tab_num before, so would cause "duplicate entry for key 1" errors  
  db_drop_primary_key($ret, 'og_panels');
  db_add_primary_key($ret, 'og_panels', array('nid', 'tab_num'));
  
  return $ret;
}

I've also attached the og_panels.install patch just in case this is the right way to do it. I wasn't sure which directory to make the patch from, so made it from the og module directory.

that patch looks really good. the only flaw i see is that one db_query() could be an update_sql(). i hope we can get some folks to help test it.

note that the most recent patch here was committed so you can just roll patches from HEAD now. Also, creating the patch from the og directory is perfect. See http://drupal.org/patch/create for more info.

subscribing...

sorry i'm subscribing too - looks fantastic

ctools is out in beta4. delegator is dead, page manager replaced it. similar to the old boss, but with a few changes.
joshk and i rerolled og panels, merlinofchaos made a change in ctools to support. updates here include:

• started with joshk's patch in #148
• replaced delegator functions with appropriate page manager functions. og panels is implemented as a variant to node/%node with weight -99
• og_panels_install implementation from #154. did not test this, but included for completeness
• patch required to ctools-beta4 (http://drupal.org/files/ctools_handler_add_finish.patch)
• og panel pages are now published by default (suggested by moshe in #151)
• the node/%node page manager page is now enabled in og_panels_enable(). if you disable it later in admin/build/panels you lose og panels.

to get this up and running, install ctools beta 4 (with patch here), panels beta 4, and og 6.x-2.0-rc3 (with patch here). i did some basic tests here, but more testing is needed.

I will install the patches tomorrow night and let you know if there are any issues. Thanks for all your hard work!!!

reverted prior patch and committed latest by populist. please test it, folks. upgrade path is untested and still need some porting for context/relationship/content items i think see /includes dir.

Hello,

is it possible that someone could upload the current patched OG with the latest patch? I am using a shared webhosting so I cant patch. I would be very thankful if someone could patch the latest version and upload it here :(

Regards

@karmalo: Please don't change issue titles. Resetting.

Michelle

Can I get some advice on the og_panels.install script:

So if someone is upgrading from a d5 version of og_panels, there's a database update that must be run which adds the tab_num field to the og_panels table. But for a clean d6 og_panels install, this is not required and will give errors as I initially wrote it.

To rectify, is this the right way to check for this in the script:

function og_panels_update_6000() {
  $ret = array();

 // Only want to perform this update if it's an upgrade, not a clean install
 $fields = drupal_schema_fields_sql('og_panels');
 // If there's already a tab_num field, no need to perform this update
 if (in_array('tab_num', $fields)) {
  return $ret;
// Otherwise it's an upgrade, and continue with the changes to the database...
...
...
...
 }

Also, is my numbering correct: og_panels_update_6000?

I did a bit more cleanup here and added the following (to the -dev branch) in this latest patch:

• incorporated #168s code for the install. did not test.
• added nifty draggable table sort to og group page list, suggested by moshe in #151
• changed dependencies in .info file and renamed it so it can be enabled
• made "save settings" button on the left and "reset homepage" on the right. its more intuitive i think

update functions do not run on clean installs. i comitted this patch without that code.

subscribing - dev branch seems to be running fine on testing server, am trying my best to break it tonight.

Hello Populist,

I cant use the patch on my virtuel server. Would you upload an already patched version where I just need to upload it? I would apreciate it very. Thanks in advance.

I tested the recent patches as described above. But all my initial issue's I posted earlier #150 are still there. Did anyone looked into them already or can someone confirm that they also have the same problems.

Just testing it out the new dev version, Maybe I'm missing something but didn't the Drupal 5 version have a way to specify a default panel layout that applies when users create a new group?

subscribe

please upload an already patched version of OG panels I cant use the patch files.

subscribe

#176: All patches appear to already be committed. Just go download the -dev.

@Terentius Wanted to go through and let you know what I've seen for issue you mention in Post #150.
I upgraded from a D5 install with current version of -Dev here's what I'm seeing with regard to these issues.

"1. Question: Do you still need to use the og_panels_plugins.tgz ?"
Not sure.

"2. The OG Panels homepage tab does not displays panels you add to it. It still only displays the default "mission" + "og_ron.view". On additional tabs it does work well."
I can't confirm this one -
For my install, depending on how things are configured I see one of three things:
- If a group has no content, and does not have a panel page assigned to it, displays default "mission" homepage
- If you add a panel to a group, setting it as group homepage, but don't add content, group homepage appears blank.
- After adding content, content appears as expected.
In short, panels on the group homepage seem to be working just fine for me.

"3. I experienced a very strange effect on all non homepage tabs. Their breadcrumbs link to totally different nodes.
[snip]
The breadcrumb of tab "EVENTS" from "GROUP-B" points to node/5 (GROUP-B). NORMAL"
I can confirm this one -
I don't have breadcrumbs enabled on my theme, but when enabled, yes I can report this is a problem.

Hope this helps.

I found that my og_panels pages were always showing up with blocks in the sidebars, even if I'd un-checked the "Show blocks" checkbox. It turns out that the function og_panels_page was not passing the correct 'show_blocks' value when displaying the panel page. The attached patch fixes this.

Regarding #150 point 2: "2. The OG Panels homepage tab does not displays panels you add to it. It still only displays the default "mission" + "og_ron.view". On additional tabs it does work well."

On a clean D6 install it works for me - home panel pages display the panel content, but on my upgraded install from D5, I'm not getting the panel displaying for the group home page either. Will debug when I get a moment.

Do these updates work with the recent RC1 of Panels? I rolled my initial upgrade back since it appeared to "mostly" work but OG Panels still needs delegator, etc.

I downloaded the current -dev (July 18th) and removed the Delegator dependancy from the OG Panels module .info file, on the assumption that the necessary functionality is elsewhere within the latest CTools. So far, it seems to be ok. Still experimenting though.

Just confirming I had the same issue and removed the the Delegator dependency from the .info as the Delegator module has become Page Manager as mentioned in #163

Committed. #180. Hope foxtrotcharlie or other can debug #181 or disprove the bug report.

Also, the panels content/relationship/context stuff needs work.

I'm posting here as this is still active. I can make a new issue if needed.

I'm using rc1 of panels and ctools and latest dev of og.

If I go into the Edit layout settings page (node/528/og_panels/9/panel_settings in my case) and submit it I get this fatal error:

Fatal error: Cannot redeclare panels_ajax_style_settings() (previously declared in /var/www/vhosts/cssa_new/sites/all/modules/panels/includes/display-layout-settings.inc:302) in /var/www/vhosts/cssa_new/sites/all/modules/panels/includes/display-edit.inc on line 1449

There is an old issue for panels (#424176: Fatal error: Cannot redeclare panels_ajax_style_settings()) that says this Edit layout settings page is not needed anymore so it probably should be removed from og_panels too.

foxtrotcharlie wrote on #181 that one a clean install, point 2 of my previous comment (#150) where not present.
I did a clean install but unfortunately its still there. Aswell as point 3 of #150.
I used the OG 6.x-2.0-rc3 and the latest stable/recommended Ctools 6.x-1.0-rc1 + Panels 6.x-3.0-rc1.

EDIT:
When using the latest OG 6.x-2-dev version it now works on a clean install. foxtrotcharlie was right about that.
However the breadcrumb issue is still unresolved. #150 - Point 3).
In fact there are no breadcrumbs at all when adding panels. (Home >> (no breadcrumbs here .....). Can it be that you have to provide a bc in the panel you add? I ask since there is a option to override the url (on add panel content screen, last option below the argument line)

Override URL:
[ add url here ]
If this is set, override the View URL; this can sometimes be useful to set to the panel URL

Did some testing and the bug mentioned in point 2 of #150 where group home page was displaying the river of news group view was actually not a bug for me as mentioned in #181 after all - it turns out that the page Node template was disabled (see screenshot) (this is found at admin/build/pages). After enabling and making sure that the OG Panels variant was enabled, it worked. Sorry for the false bug report.

I committed some work on this over the weekend. It is pretty close. I have spun off og_panels into is own project. Please help test and improve it over there. This og project will now focus on more core functionality. Expect a 2.x release of OG very soon.