Vertical tabs fieldset configuration breaks horribly for multi-step node forms
Flying Drupalist - June 26, 2009 - 17:43
| Project: | Vertical Tabs |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Jump to:
Description
When I try to go to
/admin/content/node-type/project-issue
It redirects me to node/add/project-issue
Am I not supposed to be able to edit project issue content types?
Thanks.
#1
It works fine for me (no redirect) on my test site and here on drupal.org. Must be something screwy with your setup. Make sure you're running the latest code in HEAD (which includes some file reorganization, so if you're updating from CVS, use "cvs up -dP"), clear your menu cache, etc.
#2
I'm having the same issue.
Checked that I have the latest 6.x-1.x-dev.
Tried reinstalling the module but still keeps redirecting.
#3
I just saw this bug in the wild. I still can't reproduce it locally at all, which sucks. But, I think it's a real bug. I definitely do not understand it yet. This makes no sense at all.
#4
Yay, I can finally reproduce this locally. The problem is Vertical tabs. If you disable that, everything works.
The bug is that vertical_tabs is doing some very unholy things. In vertical_tabs_form_alter(), if it sees you're trying to use a node type form (e.g. /admin/content/node-type/project-issue), and if so, it does the following:
<?php
// Build a psuedo-node for a sample node form.
$node = (object) array(
'type' => $node_type,
'name' => '',
);
// Build a sample node form to find fieldsets.
$node_form_state = array('values' => array());
$node_form_id = $node_type .'_node_form';
$args = array(
$node_form_id,
$node_form_state,
$node
);
$node_form = call_user_func_array('drupal_retrieve_form', $args);
$node_form['#post'] = $node_form_state['values'];
drupal_prepare_form($node_form_id, $node_form, $node_form_state);
uasort($node_form, 'element_sort');
?>
However, the project_issue node form is expecting a valid project to be selected, since it's sort of a multi-page form thanks to #199138: Remove multipage form for issue nodes. So, when the form builder doesn't see a valid project, it assumes you landed on the 2nd page by accident or malice without a valid project, generates a drupal_set_message() about it, and redirects you back to the first page. Therein lies the problem here.
Not sure if this should be considered a bug in vertical_tabs, project_issue, or both. :(
#5
#6
Duplicate of #494020: "Content type import/export" conflicts with "Vertical Tabs"
#7
Not true. That patch doesn't solve this problem at all. Please read comment #4 closely. This has nothing to do with the form being #programmed or not.
#8
never mind
#9
This is a vertical tabs issue. The current way vertical tabs works is it builds the node form, finds all fieldsets on it, and puts them into checkboxes, on the node type form. #320475: Configure which fieldsets are rendered as vertical tabs - no one ever got a chance to review the patch, that's probably why it slipped through. There should be some other way than building the node form. This also doesn't account for multi-step forms.
#10
More accurate title, and unassigning myself.
#11
So, how do we solve this? If it's not an easy fix please consider #577266: visiting node admin screen invokes hook_form (and shouldn't).
#12
Can someone test using the latest code (6.x-1.0-beta6) now that it is using a pre_render callback on the form instead of using form_alter?
#13
I can now visit /admin/content/node-type/project-issue on my site and it doesn't break horribly. And the content type fieldsets are vtabs now. ;) But, I no longer see any UI for #320475: Configure which fieldsets are rendered as vertical tabs -- where does that live? That seems like the thing that's still going to break with multi-step node forms...
#14
Darn I was hoping to respond to you on IRC. Basically there are two ways to control vertical tabs. The first is through our beloved $conf in settings.php. The other is by using Form controller. See #644790-7: Simplify the module and integrate with form_controller to allow customizations for more details.
#15
Yup, all working now. Thanks!
#16
Automatically closed -- issue fixed for 2 weeks with no activity.