Extend the support to different modules / form pages
kiamlaluno - June 23, 2009 - 18:11
| Project: | Vertical Tabs |
| Version: | 6.x-1.x-dev |
| Component: | Documentation |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Dave Reid |
| Status: | closed |
Description
It would be good if the module would allow any third-party modules to offer a summary for the field set they add to the node editing form. As the code actually is, the support for field sets of different modules must be added manually by editing the JavaScript file the module uses.
#1
This request came from a request in the XML Site Map module queue: #499374: Provide summary for Vertical Tabs
#2
Also don't know if it would be possible, but it would be extra awesome if other 6.x contrib modules could somehow implement vertical tabs in their own settings as well (we have a fairly long settings page in xmlsitemap).
#3
I changed the title to reflect the new request added.
#4
Here's a patch to allow modules to provide their own module_name.vertical_tabs.node_form.js which will automatically be included. With this its no longer the responsibility of the vertical tabs module to provide the js for modules that add fieldsets to the node form.
#5
Why does not the patch calls a custom hook to know of any additional JavaScript files third-party modules offers for integration with Vertical tabs? It's what is done from Views, in example, which doesn't need the administrator to copy files into a module directory.
#6
After talking with quicksketch today at DrupalCampColorado, it's actually best for the modules to call drupal_add_js on their own. For instance, in xmlsitemap_node, this is what works:
<?phpfunction xmlsitemap_node_form_alter(&$form, $form_state, $form_id) {
if (isset($form['type']) && isset($form['#node']) && $form['type']['#value'] .'_node_form' == $form_id) {
...
$form['xmlsitemap'] = array(
'#type' => 'fieldset',
'#tree' => TRUE,
'#title' => t('XML sitemap'),
'#collapsible' => TRUE,
'#collapsed' => TRUE,
'#access' => user_access('administer xmlsitemap') || user_access('administer nodes'),
'#weight' => 30,
);
...
// Add the vertical tabs JavaScript but set it to deferred.
if ($form['xmlsitemap']['#access'] && module_exists('vertical_tabs')) {
drupal_add_js(drupal_get_path('module', 'xmlsitemap_node') . '/xmlsitemap_node.vertical_tabs.node_form.js', 'module', 'header', TRUE);
}
...
}
}
?>
Note that because the vertical_tabs.modules has a staggering weight of 300 in order to pick up on all the form_alter changes to the node edit form, you need to set the 'defer' parameter to TRUE in drupal_add_js. Otherwise you will get a JavaScript error "Drupal.verticalTabs is undefined". This should really be documented with Vertical tabs module.
Setting this back to active to address the original issue of allowing other modules to create vertical tabs for their own forms, which could be used by XML sitemap on admin/settings/xmlsitemap.
#7
#8
Side not to #6, your module's vertical tabs JavaScript should have
Drupal.verticalTabs = Drupal.verticalTabs || {};in the beginning instead of using the defer attribute in drupal_add_js().#9
Simple patch that adds a vertical_tabs_add_vertical_tabs() function so that other modules can re-use the vertical tabs creation code.
#10
<?php+ if (vertical_tabs_add_vertical_tabs($form, $fieldsets)) {
+ $form['vertical_tabs']['#weight'] = 100;
+ $form['vertical_tabs']['#vertical_tabs_js'][] = drupal_get_path('module', 'xmlsitemap') .'/vertical_tabs.xmlsitemap_settings_form.js';
}
?>
links to xmlsitemap.module - I think this can't be right...
#12
Thanks for seeing that! Here's a revised patch with documentation and a fix for an E_ALL error if
$form[$key]['#weight']was undefined.#13
On a deeper review, the second check for
isset($form[$key]['#summary_callback']) || in_array($key, $fieldsets)is completely unnecessary since either condition will always be TRUE due to the previous if condition.#14
The previous patch is not the patch you are looking for. Stupid Dave didn't even check to make sure there weren't any syntax errors.
#15
I am not sure if it still valid for the last Drupal versions, but once I tried to handle the
$themevariable, and I discovered it doesn't get any value if not insidehook_footer().#16
This could should and would not be called from hook_footer() at all. It should be used in form building functions or form_alter hooks.
#17
I meant that outside
hook_footer()the variable$themewas not set to any useful value (I found it to be set to an empty string). That is what I found out when I was trying to use a different CSS file basing on the theme name; it could be that with the actual code used by Drupal, the issue is not present anymore.I am referring to the fact the code is referring to the global variable
$theme.EDIT: as I was saying, that is not anymore the case, with the latest Drupal version.
I created a page, and I used the following code as body of the page:
<?phpglobal $theme, $theme_key;
var_dump($theme);
print '<br />';
var_dump($theme_key);
?>
Both the variables contained the identifier for the actual theme (even in the case the administration, and the node editing theme was different from the one normally used). It's not the result I got with a previous Drupal 6 version.
#18
Not reviewed but +1 to the idea
#19
Is there any progress with this feature request?
#20
I think I'm going to go ahead and commit the patch in #14 with a few other bug fixes and then get a new release pushed out. Then I'm going to start working to see if I can actually backport the D7 stuff to this via hook_elements(). It's messy though. :/
#21
This is a good news, Dave; I cannot wait to see the support for third-party modules implemented.
#22
Committed to CVS. Will add documentation in a README.txt on how to add this, but it's pretty easy now since it's a call to one function. Here's how it's done in the XML sitemap module on the admin/settings/xmlsitemap page:
<?php/**
* Implementation of hook_form_FORM_ID_alter().
*
* Add vertical tabs to the XML sitemap settings.
*/
function xmlsitemap_form_xmlsitemap_settings_form_alter(&$form, $form_state) {
if (module_exists('vertical_tabs') && function_exists('vertical_tabs_add_vertical_tabs')) {
vertical_tabs_add_vertical_tabs($form);
}
}
?>
#23
Automatically closed -- issue fixed for 2 weeks with no activity.
#24
Re-opening so I can get this documented.
#25
This appears to break on Safari 4.0.3.
I've put in this small snippit in my custom module:
// Add vertical tabs to profile formif($form_id == 'user_profile_form')
{
vertical_tabs_add_vertical_tabs($form);
}
This works great on FF Mac/PC and IE 7/8 but dies completely in Safari - nothing is rendered at all in the form.
#26
@ptoly: So the code added in this issue is working just fine, but it's a Safari JS issue. Please file a separate issue.
#27
Thanks Dave, I thought it might be as much.
I've posted a new issues to gather information on this at http://drupal.org/node/579104
#28
Notice that the function works at a single level and it does not recursively look into the form. Good news, it still appears to work :)
<?php// The element crc contains all of the fieldsets to render
if (module_exists('vertical_tabs') && function_exists('vertical_tabs_add_vertical_tabs')) {
vertical_tabs_add_vertical_tabs($form['crc']);
}
?>
#29
Re-marking this as fixed in favor of #554172: Please document how to vertical_tabs-ify a module in D6 (and compare to D7 core)
#30
Automatically closed -- issue fixed for 2 weeks with no activity.