Panels integration

There was already an issue existing there, but I don't find it. Maybe it was under panels module itself

+++ b/plugins/content_types/entity_form_field_group.incundefined
@@ -0,0 +1,116 @@
+// $Id$

$Id$ shouldn't be in files anymore since the great git migration.

+++ b/plugins/content_types/entity_form_field_group.incundefined
@@ -0,0 +1,116 @@
+ * @author

I'm not sure whether it's wanted to have such things in a contrib module. The module itself doesn't have this at the moment. Personally i would throw it away.

+++ b/plugins/content_types/entity_form_field_group.incundefined
@@ -0,0 +1,116 @@
+ * Handle rendering fieldgroups as panes.

Could you move this @file below and describe that this file is about handling fieldgroups forms? Yes this is perhaps a small bug in ctools as well.

+++ b/plugins/content_types/entity_form_field_group.incundefined
@@ -0,0 +1,116 @@
+ * Return all field content types available.

Left over from the field integration. |This should probably be better "return all field group content types availible" or something like that.

+++ b/plugins/content_types/entity_form_field_group.incundefined
@@ -0,0 +1,116 @@
+  // Load the entity type's information for this field.

... same as above :)

+++ b/plugins/content_types/entity_form_field_group.incundefined
@@ -0,0 +1,116 @@
+    if (isset($context->form['#pre_render'])) {
+      foreach ($context->form['#pre_render'] as $function) {
+        if (function_exists($function)) {
+          $context->form = $function($context->form);
+        }
+      }
+      unset($context->form['#pre_render']);

Perhaps it would make sense to refer to the ctools issue which made the same change, so people understand this part of the code.

+++ b/plugins/content_types/entity_form_field_group.incundefined
@@ -0,0 +1,116 @@
+  $field = field_info_instance($entity_type, $group_name, $context->restrictions['type'][0]);

This can't work on field groups

+++ b/plugins/content_types/entity_form_field_group.incundefined
@@ -0,0 +1,116 @@
+  return t('"@s" @field form', array('@s' => $context->identifier, '@field' => $field['label']));

I'm wondering whether this line should be addapted as well.

+++ b/plugins/content_types/field_group.incundefined
@@ -0,0 +1,111 @@
+// $Id$
+/**
+ * field_group.inc
+ *
+ * @author
+ * Pascal Crott <pascal.crott@erdfisch.de>

See above.

+++ b/plugins/content_types/field_group.incundefined
@@ -0,0 +1,111 @@
+//    'defaults' => array()

You could remove this left-over lines totally.

+++ b/plugins/content_types/field_group.incundefined
@@ -0,0 +1,111 @@
+  foreach (array('nid', 'links', 'leave_node_title', 'link_node_title', 'identifier', 'build_mode') as $key) {

You need only the "build_mode" key. The other ones are not part of the form.

+++ b/plugins/content_types/field_group.incundefined
@@ -0,0 +1,111 @@
+          ¶

Here are some unneeded spaces :)

In general this patch looks really fine and provides the same amount of integration as fields for field_groups.

+++ b/plugins/content_types/field_group.incundefined
@@ -0,0 +1,115 @@
+  ¶
+  $elements = entity_view($entity_type, array($entity_id => $entity), 'default');
+  $entity_types = $entity_type.'s';
+  $element = $elements[$entity_types][$entity_id];
+
+  $block = new StdClass();
+  $block->module = 'field_group_panels';
+  $block->delta = 'field_group';
+  $block->content = drupal_render($element);

As we realized this can't render a single fieldset. This should be changed to the same method as above ...

Hey,

Thx for the patch, I did a very very quick review.

function field_group_entity_form_field_group_content_type_content_types() {
  $groups = field_group_read_groups();
  foreach ($groups as $entity_type => $bundles) {
    foreach ($bundles as $bundle => $modes) {
      foreach ($modes as $mode => $fieldgroups) {
        foreach ($fieldgroups as $group_name => $field_group) {
          // Only use form field groups
          if ($field_group->mode == 'form') {

Coulnd't you just do

function field_group_entity_form_field_group_content_type_content_types() {
  $groups = field_group_read_groups();
  foreach ($groups as $entity_type => $bundles) {
    foreach ($bundles as $bundle => $modes) {
      foreach ($modes['form'] as $group_name => $field_group) {
        // Skip this foreach completely, since you were targetting 'form' anyway.
        //foreach ($fieldgroups as $group_name => $field_group) {
          // Only use form field groups
          if ($field_group->mode == 'form') {

And even a step further, in

function field_group_entity_form_field_group_content_type_content_type($subtype) {
  $types = field_group_entity_form_field_group_content_type_content_types();
  if (isset($types[$subtype])) {
    return $types[$subtype];
  }
}

You are calling the function without filter parameters. I know you are wanting to create new keys later on, so you could as well give $entity_type and $group_name as separate parameters. That will spare you another loop, since you then know which bundle (content type) to target.

Maybe I've written some errors inhere, but what I would suggest is:

function field_group_entity_form_field_group_content_type_content_types($entity_type) {
  $groups = field_group_read_groups(array('entity_type' => $entity_type);
  // Skip this one entirely$entity_type
  //foreach ($groups as $entity_type => $bundles) {
  foreach ($groups[$entity_type] as $bundle => $modes) {
  //foreach ($bundles as $bundle => $modes) {
    foreach ($modes['form'] as $group_name => $field_group) {
        // Skip this foreach completely, since you were targetting 'form' anyway.
        //foreach ($fieldgroups as $group_name => $field_group) {
          // Only use form field groups
          // Check is not needed anymore
          //if ($field_group->mode == 'form') { 
            $types[$entity_type . ':' . $group_name] = array(

Correct me if I am wrong ofcourse, but if this works as well, this would certainly lead to some faster execution time.

I also saw that that function is called "field_group_entity_form_field_group_content_type_content_types", which has the word "content_type" in it. I did never use fieldgroups in panels in D6, but field_group now works with all entities, not just nodes. Is this just a start or won't it never work on user, term, ...

Last thing for now, I would also prefer to handle the logic in field_group_field_group_content_type_content_types and field_group_entity_form_field_group_content_type_content_types in the same function. They are not that different.

I hope I have more time later on to test this out.
Thx in advance! I am glad that somebody started this :)

- EDIT - $subtype could be handled by something like

list($entity_type, ) = explode($subtype);
$types = field_group_entity_form_field_group_content_type_content_types(entity_type);

After a talk with Swentel (in person) and Hydra (IRC), I feel like forcing the UI to choosing a field_group and then allowing a choice of view modes to determine a scope. After that a list of links will be shown with all the real fieldgroups.

In code, you can progress as you are.

I need this feature, fast. Am willing to sponsor. Contact me if you're interested.

Thanks,
Tal

I'll check if we can speed this up. Good to know it's a wanted feature.

I guess hydra will come up with a new version in some time.

subscribe

Actually it did not take too long. It's just a very much wanted feature ;)
Thx for the patch.

Just tried it , but nothing seems to appear. Must be something wrong with the applied patch :(. Investigating ...

I merged it manually but I could not get it working.
problems:
- The ajax path is not found
- If I leave everything configured default, so I can pick a fieldgroup, I get "Fatal error: Cannot access empty property in /opt/d7/field_group/plugins/content_types/field_group.inc on line 252" on the node view (overridden by panels)

You probably need #1259430: Convert entity_field to use #ajax for formatter options

@dereine, did not test it yet, but that sounds like the problem :)
Thx for the feedback

@Hydra: Do you have time to create a valid patch?

I'll postpone this then for branch 2. We decided that branch2 will include some bigger features like panels integration, the move of horizontal tabs to elements module and the integration with the Renderable elements module.

Thx for the patch.

The entity requirement and according code has to go I'm afraid.

+++ b/plugins/content_types/field_group.incundefined
@@ -0,0 +1,286 @@
+  $elements = entity_view($entity_type, array($entity_id => $entity), $view_mode);

Okay so this is all about entity_view. Personally i don't know another way to render a general entity/just a single field_group. Perhaps the depedency could be optional, but required for the panels integration?

@dereine that's true, my thoughts would be on the same path: no dependency enforcement but optional on the panels integration. Worst case (which is not even that bad) is to have the integration in a submodule.

+++ b/plugins/content_types/field_group.incundefined
@@ -0,0 +1,286 @@
+  ¶
+  $elements = entity_view($entity_type, array($entity_id => $entity), $view_mode);
+  $entity_types = $entity_type . 's';

You probably talk about that part of the code. Only the entity api provides a general way to render an entity, that's a sad fact :(
But what about making JUST the panels integration depend on entity api module?
I'm not sure what would be the best place to document such things, but i think it's okay to install entity api for people which require this feature.

Correct. But you have three possibilities I see for this (not taking documentation in consideration):
- work with a simple module exist
- work with a internal small pluggable system that takes care of this
- work with a submodule fieldgroup panels , which depends on the entity api module.

I would prefer approach 3. Ok with you?

I don't have anything productive to add here. I just wanted to voice my desire to see this as a feature. My migration from D6 to D7 has gone fairly well but this is the largest hiccup.

Thanks for your attention.

What is the current status of this issue which seems to be related to these?

#1405792: Panels 3 integration for field_group
#1119204: Support for Panels module

I also have a similar need .. a sub-module would be fantastic. I am currently manually creating a mini-panel per field group.

I think the idea of a sub-module would be a very good one (gives people who haven't sipped the panels kool aid options).

Did this ever happen?

I did review it and it is very nice. I am sure this will be very useful. Any plans to make this a contrib?

closing this as the solution in #38 is the way this issue turned out.

Would it not be better to merge the sandbox into the main module, rather than requiring Yet Another Module just to add CTools/Panels integration?

We have a need for this also:

1. Hydra's sandbox module in #38 seems to be working on latest dev versions of panels/panelizer

2. I also would appreciate this as a sub-module vs a sandbox -- any chance of integrating this into the parent module?

Thanks

Re-opening this because I agree with the two above; people don't expect to go find another module for panels integration these days, fold it on in!

Setting to needs works based on being some work, but not a current patch to add it to field_group itself

Here's it folded into field_group

Changed some stuff related to required context based in entity_form_field from ctools as wasn't showing till I did that.

@hefox
Does your patch require the 7.x-1.x-dev version of ctools and therefore the ctools patch that's listed in @Hydra's sandbox module?

Thanks in advance!

Using 7.x-1.3 of ctools, no patch

Using it now. Working well.

Thank you, kindly!

I needed to configure it so it didn't show all fields below the fieldgroup, so updated patch for that

Hi,

Thanks for this patch, it has been very useful.

I did find that I was having issues with the add panel configuration with this patch when I clicked on the subcategory containing the field group panes while using the panopoly distribution. I tracked the problem down to the content type render function in field_group.inc

I Added an early return to the function when no context or context data is available, which will be useful regardless of the Panopoly distro.

@ln 202

/**
 * Render a field_group as pane.
 */
function field_group_field_group_content_type_render($subtype, $conf, $panel_args, $context) {
  // We don't have context, return.
  if (empty($context) || empty($context->data)) {
    return;
  }

I also rerolled the patch with the above code if that's more useful.

Cheers!
thebruce

how i can add fieldgoup in panel?

@Hydra: I'd recommend continuing to improve the patch here and we can see if we can persuade Stalski to commit it, having this in a separate module is a mistake IMHO.

@Hydra: FYI the project page says "CTools content type and Panels integration will be merged into 7.x-1.x", so lets continue in this direction.

I would love to see panels integration in field group. It seems to be fairly standard practice to add panels/ctools plugins within a module, rather than as a separate contrib; it would make it easier as a user to have all the functionality available automatically. It's certainly something I expected to have available when I looked at my fields in panels and was surprised that it wasn't. So, this would be fab.

The patch with #48 worked for me.

One usage note: it doesn't seem to like it when you have any fieldgroup fields placed in the panel alone (with an add/edit panel); it says they don't exist. Behaviour only manifests once you've added at least one fieldgroup, but happens to fields in other groups who were placed individually, even if their group isn't placed. I think it's fair to expect users to either use the fieldgroups or not, though -- if they want to use a field independently on the form, they can remove it from the group -- so this doesn't feel like a bug to me, but might need some clarification in docs for users.

@Renee: Could you please provide a little more detail on the glitch you found? Thanks.

To reproduce:

1. Add a fieldgroup -- works
2. Add an item that's within a fieldgroup, but not the actual fieldgroup itself -- breaks

This will produce an error. The way to fix it is to remove the item from the fieldgroup.

.

Subscribe. Me too I'd love fieldgroup panes, expecially to apply different styles to different groups.

For all of you who landed here looking just for a way to integrate fieldgroups in your panels: I found a way around this bug
- at least I'm able to use some fieldgroups in panels (horizontal tabs and accordion are working)

Please be aware:
1. I'm German speaker - so I have to translate the German localization back into English and some labels might be slightly different in the English drupal localization:
2. I'm not a programmer - don't ask me anything about php, ...
---------------------
My way:

I created a new content type named (e.g.) page-2
- goto admin/structure/types/manage/page-2/fields and create all the fields you need in your panel
- goto admin/structure/types/manage/page-2/display
Just create a display containing only the fieldgroups and fields you need for the accordion or horizontal tabs (maybe others might work to)
Don't insert more fields.
- goto admin/structure/panels/layouts/add to create your custom layout, include a row / region where you are going to use your fieldgroups
- goto admin/structure/panels
Under manage pages you find the Node template. Click edit.
- Add a new variant (admin/structure/pages/nojs/operation/node_view/actions/add), give a title and create it.
- choose the custom layout you just have created
- in the next tab just hit 'next'
- create the variant
- IMPORTANT: under selection rules you need to restrict the panel view only to the page with the content type page-2: Add criteria 'node type' and select page-2
- save the selection and update and save your panel
- create your panel content: select the region for your fieldgroups and add content of the type entity - rendered content, in the next window choose view mode full and save it
- save your panel
- create new content (node/add) using page-2 for content type - the display should show the tabs

With this I could even create an accordion within the horizontal tabs within the panel.

Hope it works for you.
.........................................................................
modules in addition to panels:
fieldgroup (http://drupal.org/project/field_group)
Entity API (http://drupal.org/project/entity)
-------------------------------------------------------------
my installation: drupal 7.26
panels 7.x-3.3
Entity API 7.x-1.3
fieldgroup 7.x-1.3

I don't know if necessary - because of a lot of Error messages I updated
Chaos tools to 7.x-1.3+30-dev. Maybe this is not related to the problem.

Have fun!

Patch attached...Setting to NR

We used to have this patch for an OA2 client, but then it was dropped. Just tested the re-roll in #61 against the 1.3 field_group and it applies and works well.

Tempted to mark RTBC but seems that some people had issues in the past. Would encourage people to try this. Will probably have the Panopoly guys take a look at this as well since it affects them too.

This patch still needs work. It actually applies to v1.3 but it redeclares field_group_ctools_plugin_directory() so gives an error on the site. Need to look into this a bit more.

Can somebody pleaaaase fix this problem? Unbelievable, we have no possibility to group fields inside panel regions :(

Well I think this is still a major problem, general issue and as visible above some tests fail in #61 so this truely needs work and a bit love of the people who know how to solve this.

I will have a look at the code myself and try to fix what I can.

These are my results:

I modified the patch from 48 to make it work with the latest .dev version.
The patch from #61 had many flaws so I decided to not use it. #48 is far more cleaner and logically correct from my point of view.

Anyway #48 adds entity_form integration which might be interesting for future development and combining both patches?

Patch had a dfb in it, sorry. Now clean:

First off, the patches need to be checked against the -dev version.

Secondly, @anybody, given that you're making changes because you say the previous version had flaws, could you please detail them and/or upload an interdiff? Thanks.

@Damien: Sorry in the existing field_group.module file there is just a little change which adds the ctools plugin directory registration.

The field_group.inc file is completely new and does not exist in the current .dev release.
So it seems I truely made a mistake in the patching process.

Regarding the flaws question: Simply have a look at the patch #61 and see the comments and lots of bugs. Nothing worked for me in this. #48 was much more cleaner, I even think they are not related that much.

I'll have a look again when I have a bit more time. I hope my work already helped.

Is someone interested to have a look at the implementation to bring this forward?

We're using the patched module successfully for over a month now. It would be nice to offer this feature to other users too.

I'm not sure, but this issue from Ctools might be related as well #2222513: Provide Field Group panes for entity edit forms

@Anybody: Are you still using patch from #73 or do you have a new version (#73 failed testing). Did you also check #2222513: Provide Field Group panes for entity edit forms how your patch compares to that. The patch there is much shorter than yours, but not sure if it does the same. I didn't test it yet, currently I am just evaluating the topic.

Yeah we're still using the patch from #73. The failed tests are due to patch formats. I'll create a proper one ASAP and upload it here. Is there an active module maintainer who can apply that patch in the future perhaps?

The topic from #80 may be related but doesn't seem to be the same for me?

Patch attached. Entity edit forms are excluded in the patch. They share the same topic: ctools_plugins! ;)

Please review and RTBC as soon as possible :)

The patch is against latest dev (7.x-1.x-dev)

I left a comment in #2222513: Provide Field Group panes for entity edit forms to relate both issues.
@all: Please test the patch now and provide some feedback. As said above we're using it since month successfully.

The patch from #83 works, but only when applied manually. It's using some weird encoding (reported as UTF-16). I also had a problem when patching using GIT (the reason being that it creates a new file), with PATCH it's fine.

#83 works for me too

Could not apply patch in #83 with Git.

The error message is: "fatal: unrecognized input"

The downloaded version is not a text file
patch -p1 < field_group-panels_integration-1278618-83.patch
patch unexpectedly ends in middle of line
patch: **** Only garbage was found in the patch input.

Re-test

Re-roll of #83 with hopefully correct format.

@Anybody I think it's failing on the Windows line endings maybe?

1. +++ b/plugins/content_types/field_group.inc
   @@ -0,0 +1,272 @@
   +  // Probably not the best category to find this?
   +  'category' => t('Miscellaneous'),
   

   Maybe put it into a 'Field Group' category?, otherwise that should be fine...

2. +++ b/plugins/content_types/field_group.inc
   @@ -0,0 +1,272 @@
   +  // TODO: Trying to handle arguments like nids.
   

   Likely needs to be resolved before RTBC.

3. +++ b/plugins/content_types/field_group.inc
   @@ -0,0 +1,272 @@
   +//      'path' => 'ctools/content/ajax',
   

   Should this line be commented out or removed?

@joelpittet, thanks a lot. I fixed the issues.
1. Good idea! I now used "Field Groups" (plural).
2. This was unused and removed. Perhaps the original creator of the patch tried something there...
3. removed!

Patch against the latest .dev attached and ready to be tested.

If it works please review and RTBC to get this finalized.

Yeah, finally :) #94 RTBC

The PHP 7 fails are outside the module I think. Please provide more feedback. :)

I fixed the PHP 7 issue already https://www.drupal.org/node/2528736. The test bot is using ctools 7.x-1.9, which doesn't have the PHP 7 commits yet (https://dispatcher.drupalci.org/job/default/77054/console).

Thank you very much. I'd say if we get a bit more feedback we can set this RTBC.
Is there an active Field Group maintainer willing to integrate this into the .dev release soon? I think it would help many people a lot.

hi
thanks for the work on integrating to panrl

I am on Php, 5.5.26 with MySQL 5.5 and Open atrium distribution base on Panopoly.
Can i use the patch without problem?

Try the patch on a local environment, make backups if you have doubts. We can't anticipate problems you may have with it but with a bit of testing you can see if it works for you or not. Please report back any issues which arise or whether it works.

@joelpittet
I try the patch with my configuration mentioned above on the latest version of Open Atrium base on Panoply distribution (2.60) and it work without any problem..

thanks

@Anybody I was trying out the patch today and noticed plugins/content_types/entity_form_field_group.inc was missing, which as in #48 (which is a patch I've got in production). Was that intentionally removed?

Here's an interdiff between 48 and 94 if anybody is interested. And The patch I've attached just includes the plugins/content_types/entity_form_field_group.inc file that I mentioned in #102 assuming it was a mistake (for me it's broken handlers because I've got it on forms)

I have used the most recent patch, it works for allowing you to add field group forms. But wasn't the original issue about adding fieldgroups as panes i.e. Content display, which is what I need it for.

Sorry ignore my last comment, I hadn't cleared my cache!
Patch works great for me

Patch works for me too. Very useful.

Can we please get this commited? This is really an important, useful and well tested feature. Is there an active maintainer?

hi @ joelpittet

Should we use your last uploaded patch..

@animare

Which patch worked for you ?

I restarted the tests, it's not likely to get committed if there are test failures. I don't remember if those were testbot bugs, the module failures or this patch.

Yes always use the latest patch, unless otherwise directed

@joelpittet:
Regarding #103: Yes it was. See #93+#94 (2. point). The file was unused and removed. Sorry if I was wrong. But to be sure please retry on a clean installation.

The PHP7 errors are deprecation messages, they can be ignored I think.

Hi, at least some of the test failures here are due to #2871785: Tests failing in Drupal 7.50+, which needs committing before any tests will pass on 7.x-1.x-dev.

Reroll.

Retry.

Confirming RTBC fpr #119, works perfectly with latest version and solves a long long issue!

@Maintainer: Please test and commit to latest dev.

Confirmed. #119 works great +1 RTBC.

Thank you so much for all the work, after breaking this on an inherited site, I understand fully the need for this patch. I recently updated field_groups and ctools to the latest release versions and after repatching with #119, panels is still complaining about "Deleted/missing content type field_group". I tried re-adding them but I can't see the field groups in the addable content.

Scenario:
Drupal 7.58
Ctools Version: 7.x-1.14
Field Group Version: 7.x-1.6

Applied patch #119 (only that, no ctools patch)

Did I skip a step or am I not seeing something?

Will this ever become part of the module? It would be great to have this in the dev and next stable release please.

#119 didn't work for me.

I got a new field type in "Form elements" that has the field-group fields, but it asks if i want to disable any fields, where all labels are "f".
I didn't disable any field, and no fields appears on the form.

I don't believe this is working anymore. I lost all my configuration so its not worth using if it won't be part of the module.

I don't believe this is working anymore. I lost all my configuration so its not worth using if it won't be part of the module.

I've been using #103 for three years now for a custom feature-based distribution on several live-sites without ever loosing configuration or having any problems at all.

#119 so far is working for me like a magic trick. The patch applied clean against field_group (7.x-1.6 from 3 November 2017), I have it working with the Bootstrap Fieldgroup module in a moderately complex panels layout, everything worked like I hoped it would.

Details and words for future searchers: after enabling the module and applying the patch, I was able to define field groups in the content type > fields UI, nesting the fields as needed into the groups. Then in panels I was able to add the "parent" group item, which brought with it all the fields (and corresponding subgroups) that had been nested under it.

In my case I had several sub groups in order to create bootstrap fieldgroup tabs (per that module), each tab with its own field grouping. Just adding the parent group in panels brought in all child groups and nested fields. Worked like a charm.

+1

I think this isn't needed anymore since #2222513: Provide Field Group panes for entity edit forms got committed?

Closing as duplicate of #2222513: Provide Field Group panes for entity edit forms.

@MustangGB it might not be an exact duplicate, there was some configuration to disable fields in this, but I don't know how much that was being used... I'm attempting to convert to the other one.

Diff looks like this which amounts to a pane->type change so pretty close:

-  $pane->pid = 'new-7d98e90f-4c38-42a8-aff4-20c28c1556aa';
+  $pane->pid = 'new-7be2cbee-47e0-4130-ac6c-ffcc6c7eb24b';
   $pane->panel = 'right';
-  $pane->type = 'entity_form_field_group';
+  $pane->type = 'entity_form_field';
   $pane->subtype = 'node:group_metadata';
   $pane->shown = TRUE;
   $pane->access = array();
   $pane->configuration = array(
     'context' => 'argument_node_edit_1',
-    'disable_children' => array(
-      'group_docs_approved' => 0,
-      'group_docs_resources' => 0,
-      'group_docs_review' => 0,
-    ),
     'formatter' => '',
     'label' => '',
     'override_title' => 0,
+    'override_title_heading' => 'h2',
     'override_title_text' => '',
   );
   $pane->cache = array();
@@ -5000,9 +4996,9 @@ function MODULE_page_handlers_default_page_manager_handlers() {
   $pane->extras = array();
   $pane->position = 5;
   $pane->locks = array();
-  $pane->uuid = '7d98e90f-4c38-42a8-aff4-20c28c1556aa';
-  $display->content['new-7d98e90f-4c38-42a8-aff4-20c28c1556aa'] = $pane;
-  $display->panels['right'][5] = 'new-7d98e90f-4c38-42a8-aff4-20c28c1556aa';
+  $pane->uuid = '7be2cbee-47e0-4130-ac6c-ffcc6c7eb24b';
+  $display->content['new-7be2cbee-47e0-4130-ac6c-ffcc6c7eb24b'] = $pane;
+  $display->panels['right'][5] = 'new-7be2cbee-47e0-4130-ac6c-ffcc6c7eb24b';
   $pane = new stdClass();
   $pane->pid = 'new-9bf657e3-f05d-4d08-aefd-b2d2aec47fd1';
   $pane->panel = 'top';