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

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

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:

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.

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.

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?

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

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:

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