Closed (fixed)
Project:
Vertical Tabs
Version:
6.x-1.x-dev
Component:
Documentation
Priority:
Normal
Category:
Feature request
Assigned:
Reporter:
Created:
23 Jun 2009 at 18:11 UTC
Updated:
20 Nov 2009 at 20:50 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
wretched sinner - saved by grace commentedThis request came from a request in the XML Site Map module queue: #499374: Provide summary for Vertical Tabs
Comment #2
dave reidAlso 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).
Comment #3
avpadernoI changed the title to reflect the new request added.
Comment #4
dave reidHere'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.
Comment #5
avpadernoWhy 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.
Comment #6
dave reidAfter 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:
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.
Comment #7
dave reidComment #8
dave reidSide 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().Comment #9
dave reidSimple patch that adds a vertical_tabs_add_vertical_tabs() function so that other modules can re-use the vertical tabs creation code.
Comment #10
Tobias Maier commentedlinks to xmlsitemap.module - I think this can't be right...
Comment #11
Tobias Maier commentedComment #12
dave reidThanks for seeing that! Here's a revised patch with documentation and a fix for an E_ALL error if
$form[$key]['#weight']was undefined.Comment #13
dave reidOn 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.Comment #14
dave reidThe 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.
Comment #15
avpadernoI 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().Comment #16
dave reidThis could should and would not be called from hook_footer() at all. It should be used in form building functions or form_alter hooks.
Comment #17
avpadernoI 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:
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.
Comment #18
dmitrig01 commentedNot reviewed but +1 to the idea
Comment #19
avpadernoIs there any progress with this feature request?
Comment #20
dave reidI 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. :/
Comment #21
avpadernoThis is a good news, Dave; I cannot wait to see the support for third-party modules implemented.
Comment #22
dave reidCommitted 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:
Comment #24
dave reidRe-opening so I can get this documented.
Comment #25
ptoly commentedThis appears to break on Safari 4.0.3.
I've put in this small snippit in my custom module:
This works great on FF Mac/PC and IE 7/8 but dies completely in Safari - nothing is rendered at all in the form.
Comment #26
dave reid@ptoly: So the code added in this issue is working just fine, but it's a Safari JS issue. Please file a separate issue.
Comment #27
ptoly commentedThanks 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
Comment #28
alan d. commentedNotice that the function works at a single level and it does not recursively look into the form. Good news, it still appears to work :)
Comment #29
dave reidRe-marking this as fixed in favor of #554172: Please document how to vertical_tabs-ify a module in D6 (and compare to D7 core)