When building the form, panels_node_form looks for $node->panel_layout . If that's not set (for example when creating a new node) then it looks to arg(3) to see if the panel layout is specified there. If it's not there, drupal_goto bounces you back to layout selection.

This is a problem when trying to deal with new panel nodes programmatically, since the URL will not be of the form panels_node_form is looking for and, rather than build the form, it'll drupal_goto to layout selection.

I am personally running into this when using panels_node together with hierarchical_select.module. HS allows for ajax-based widgets for drilling down into hierarchical taxonomies. If I try to drill down while creating a new panel node, hierarchical_select calls a function which attempts to build the panel node form again and return deeper part of the hierarchy via JSON. But, since the path which invokes that function (/hierarchical_select_json) doesn't meet the criteria above and so drupal_goto takes you to layout selection. Since the response is now HTML and not JSON, hierarchical select fails.

I tested this with a bare installation, only non-core modules installed were hierarchical_select, ctools, and panels.

Let me know if I can provide any more info. I'm happy to write the patch myself given a bit of direction but I don't want to go in a direction that doesn't make sense to the maintainers.

CommentFileSizeAuthor
#2 terrible-solution-656848.patch833 bytesSteven Merrill

Comments

merlinofchaos’s picture

I'm not really sure what can be done about this. Panels node NEEDS to have layout selected before doing anything else. That is pretty unusual in standard node creation.

Steven Merrill’s picture

Project: Panels » Hierarchical Select
Version: 6.x-3.2 » 6.x-3.0
Component: Panel nodes » Code
Status: Active » Needs work
StatusFileSize
new833 bytes

Here is a really ugly fix that works by changing hierarchical select module. The ugliness lies in parsing the correct path out of $_SERVER['HTTP_REFERER']. I'll take the time later to write a much better patch that actually puts the current $_GET['q'] value in Drupal.settings for retrieval by hierarchical_select_json().

I'd love comments on (the better implemented version of) this solution. This might also fix compatibility with something like nodereference_url.module that depends on arg(3) during node creation.

The patch (bad as it is) is against 6.x-3.0.

wim leers’s picture

Wow, that's indeed super hacky!

IMO this is just a demonstration of how Forms API in Drupal 6 is still a total failure in very advanced use cases.

Honestly, I'm not sure what to do: commit this beyond ugly patch or just let this issue sit here for the extremely few that need it. Going to think about it. More feedback is of course welcome.

wim leers’s picture

Status: Needs work » Closed (won't fix)

Closing due to lack of response.