Problem when creating node panels

What you ask is conceptually very difficult, because Panels has no knowledge of these additional fields at all. I'll see if I can find a way to rework the flow, but it will almost certainly be to pick the layout first. I'll see what I can do here.

Thanks for your fast answer.

If it can't be changed that the layout has to be picked first, would it at least be possible, that only the layout chooser appears but not all the other fields?

I'm not sure. In order for that to happen I'll have to take the page over entirely, and that could have some complications; but I think it should be ok. I'll have to see when I get a chance to get to it.

As a temporary solution I have changed a line in function panels_node_form:

Before, it was $layout = arg(3);, I have fixed the layout like this: $layout = "twocol";.
Now, when creating a new node-panel, one starts at the second step and the problem is gone. (This is likely not portable to other sites but for our specific problem it is ok.)

I've put in a better way to do this; it will go out in alpha14.

In alpha 14, node panels don't work anymore. One just gets to the layout choosing page. Choosing a layout there just adds the layout-name to the URL, but one stays at the layout choosing page.

I think the problem is here:

function panels_node_add() {
 $output = '';
 panels_load_include('plugins');
 // If no layout selected, present a list of choices.
 foreach (panels_get_layouts() as $id => $layout) {
 $output .= panels_print_layout_link($id, $layout, $_GET['q'] . '/' . $id);
 }
 return $output;
}

From the comment I'd guess that there should be a check if $layout has already been set but there is none.

I searched a bit more and found the apparent real reason:

In alpha 14 you added this:

 // Hard override of node/add
 if (arg(0) == 'node' && arg(1) == 'add' && arg(2) == 'panel' && arg(3) == NULL) {
 $items[] = array(
 'path' => 'node/add/panel',
 'title' => t('Panel'),
 'access' => user_access('create panel-nodes'),
 'callback' => 'panels_node_add',
 'type' => MENU_NORMAL_ITEM,
 );
 }

This code is good. But at the beginning of that function there still is this:

 $items[] = array(
 'path' => 'node/add/panel',
 'title' => t('Panel'),
 'access' => user_access('create panel-nodes'),
 'callback' => 'panels_node_add',
 'type' => MENU_NORMAL_ITEM,
 );

So, panels_node_add will always be called, no matter if the layout has already been selected.
Commenting out that second piece of code solves the problem.

Argh! Left the one that didn't quite work right for me in. Sorry about that. AT least it's a fairly simple fix for the moment.

I believe just the 'callback' needs to be removed because that is still necessary to provide access control on the visible menu item.

I've committed that change (and an update I forgot that sets the panel node weight high enough, which can matter a bit too).

Thanks for the fast fix. :)

Apologies for creating duplicate issues on this one. Thanks for posting the link anyway. As instructed, I tried commenting out the following code in panels_node.module:

 // Hard override of node/add
 if (arg(0) == 'node' && arg(1) == 'add' && arg(2) == 'panel' && arg(3) == NULL) {
 $items[] = array(
 'path' => 'node/add/panel',
 'title' => t('Panel'),
 'access' => user_access('create panel-nodes'),
 'callback' => 'panels_node_add',
 'type' => MENU_NORMAL_ITEM,
 );
 }

But it doesn't seem to have solved the problem of "Choosing a layout there just adds the layout-name to the URL" for me. The easiest solution would seem to be to download the version of panels_node that Merlin committed the fix to. A second apology for my ignorance on how to download the cvs for this. I went to http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/panels/pane... where I would expect to see it, but it wasn't there.

In the other $items[] entry that looks like the one you posted, (the one that is right below the line if ($may_cache) } remove the part that says 'callback' => 'panels_node_add', then TRUNCATE cache_menu and everything should work ok.

Merlin, thanks very much, your instructions fixed the problem for me. I was missing the truncate cache_menu table in the database step before, which was why no amount of debugging was having an effect. I'll file this detail away for future menu troubleshooting as well.

Automatically closed -- issue fixed for two weeks with no activity.