Vertical Tabs no longer works on the front end?

gone for me too

Me as well. I have had to download and turn on the form module to turn on the tabs. Not a good solution though.

Read http://drupal.org/handbook/modules/vertical-tabs

@blueblade Vertical tabs are not possible when 'viewing' nodes (front-end). Only when using the node edit form (node/x/edit, backend).

Can you clarify what you mean by 'admin pages' and 'user pages'? That's very vague.

Ok, I'll try again. I know what backend and frontend mean. What *specific pages* on your site are you referring to? node/[nid]/edit/?

Yes, the options have been removed from the content type edit pages where you normally selected which fieldsets where included in vertical tabs or not. The beta7 module (which you probably should have tested first before using on production, since it's still in beta) made changes that brought the module in line with out Drupal 7's vertical tabs work. In order to customize which fieldsets are included or not, you need to either adjust some configuration in your site's settings.php (like the instructions in http://drupal.org/handbook/modules/vertical-tabs) or use the experimental Form module. This has been answered in several other issues as well, so please be sure to search for people that have had the same question/problem.

blueblade, we are multiple people that have reverted to beta5 as that is the last working version for people with production sites. See the other similar issues for VT for the discussion about this.

I was referring to issue #644790: Simplify the module and integrate with form_controller to allow customizations and issue #653898: Vertical tabs not showing after updating to Beta 6?.

reply to #11
ok, but why make things which where simple complicated?

A D7 compatible version is ok. but please show the checkboxes for D6 again.

yes, please add those back for D6...

Apparently it would make sense to have another VT module that "Just works" for D6. Developing D7 is ok as long as you don't break people's sites on every update. That's what branches are for.

I agree with crea (#18)

I allow myself to change the status to "needs review" as it seems to have an impact on many other users and we should re-think the current solution.

The last release that was 'working' properly (still had settings on the node type settings pages and didn't integrate with Form/Form Controller) was 6.x-1.0-beta5, which is still available to download. No one is forcing anyone to have to use the latest version. In fact its actually OK to stick with a version that works for you as long as there's not a security update. You can even use the Update advanced settings module to 'disable' update notifications for a specific project.

There's no reason for two branches. If people want the beta5 version, just keep using it. Even if I did create two branches I woudn't want to support the old version. I want to continue with trying to improve and make the current code even better.

Thank you for your feedback and links.
I understan your point and would like to use the opporunity to thank you for all your efforts on the module! :)

David, I am not suggesting that you support the b5 branch, in fact I have suggested to support it but you ignored that request. Will you consider it again?

Fork could help, but it would require maintainer that knows JS.

@Dave Raid:

The last release that was 'working' properly (still had settings on the node type settings pages and didn't integrate with Form/Form Controller) was 6.x-1.0-beta5, which is still available to download.

You are simply pissing off users with such attitude and losing their trust, because they need some secret knowledge that for them newer version of VT is not better but may break their site.

No one is forcing anyone to have to use the latest version. In fact its actually OK to stick with a version that works for you as long as there's not a security update.

You are very very wrong with this. It may be true for experienced users and developers, but wrong for casual users, who are majority. It is general Drupal policy that newer versions are better. That's why update notification is in core. Users are supposed to upgrade. So you are inventing your own release policy that is against Drupal core.

For non-backward-compatible changes and experiments it's commonly accepted practice to create new branches. It's very sad that experienced developer like you doesn't use this. Sure, opensource is developer-centric, but still doesn't imply lack of responsibility for your users.

I would suggest to stay in 1.x with beta5, and create 2.x branch. You wouldn't need to continue developing 1.x, but users that would need to use 2.x goodies atleast would do it meaningly, with knowlegde what was changed and what needs to be done. This would make major difference with what we have now.

I total agree with crea. The current state of this module is really missunderstooding, and this issue could be active until new new version will be added, or the new things will me moved to another branch (2.x).

It does seem that we are all wasting our time here and elsewhere, like http://drupal.org/node/644790. I do not believe that the developer is hearing us. He essentially surprised us all with a Drupal 7 module dropped on to Drupal 6, even though Drupal 6 could not adequately handle the changes, except via options that are, most charitably stated, not best practices. The norm is to have a different branch of each module for each Drupal version, and we had a Drupal 6 version for a while, alongside an implied (in core) Drupal 7 module, but now we have two Drupal 7 versions. It is no surprise that the results have been somewhat unworkable.

Sadly, I have gone from recommending this module to having to defend to people why I ever recommended this module to them in the first place. Some I know now use this as an example of some of the failings of Drupal and open source, as if I really needed another thing to be up against.

This module will be great in Drupal 7, but that really does not help most of us right now, as most of us are on Drupal 6, and clearly there is almost no chance of things changing. Our reasonable comments have been as thoroughly ignored and dismissed as I have ever witnessed. A routine update results in a lot of lost work for a lot of users (think clients), but instead of being marked a bug, it is marked a support request, as if it had been written as it is now all along. It is ironic that this happens amidst the drive to make Drupal more stable and professional. Sadly, I think the best thing we can do is learn from this about what not to do, then save our time and our breath and move on.

After a while to think about this I've come to a decision to meet half-way. I'll re-add the simpler interface but as an option that can be switched on so it can add a warning about it may not work properly. That way we don't have to roll-back and we can move forward and keep everyone happy. I'll get this implemented tomorrow.

BTW saying I surprised this on you is completely untrue. It was clearly stated (and put in bold) in the beta5 release notes as a major, significant change. Also I had an open issue about converting to using the Form module instead of using the custom code. Of course no one sees those kinds of issues until they have a problem with it after it's been done, so not much I could have done.

I've officially added support for the options on the node type form back in CVS:
http://drupal.org/cvs?commit=323840

I'll be doing some testing and final cleanups and most likely create a 1.0 release today.

For everyone that was affected by this, I do apologize. I thought I was moving the module forward and I didn't respond well to the sudden backlash when there was no virtually no input on a major change. Please understand it was never my intention to piss anyone off. Creating two branches when the module was in beta is just kinda silly, so hopefully this is an acceptable half-way resolution.

The new release 6.x-1.0-rc1 is now available.

Thank you for your efforts!

This made me so happy. Thanks very much. I'm delighted to be wrong on this being a closed issue and owe you an apology on that count. This does not feel like a compromise though. I mean, between this change and recent changes, it's better than before. Changing content types is so much better with VT in play. The new "Include new fieldsets in vertical tabs by default." is a gem and I like the minimum setting too. The results look really good right away and all I'm doing is tweaking taxonomy options, for the most part. This module really improves the back-end user interfaces. I'm sooooo glad to have this great version of it. Great work. This is again a must-have module.

I'm sorry if my prior comments were harsh, I was not trying to be. I really just wanted to communicate the issues and to reach you, beyond the outpouring you mentioned. I do tend to religiously read release notes before doing an update, but I guess I missed that one, or more likely did not quite grep the possibilities.

Regardless, I greatly appreciate all you have done and I thank you very much for meeting us halfway... well, all the way really. I've been playing around and so far it looks really good. I have nothing at all to complain about and I'm happy as a dog off his leash in a field. The only thing I might suggest is an "Exclude Vocabularies" option just below the "Include new fieldsets in vertical tabs by default." option, as taxonomy can really overwhelm the VT tab, and I noticed that several people mentioned vocabularies. But it's all good.

I may do some documentation about this, in which case I'll let you know. Let me know if you have any specific needs. Now I'm off to message several Drupalers and tell them to download the new version.

Excellent stuff. Thanks again.

@grantkruger No hard feelings at all. The module's much better with both easy and advanced ways to control fieldsets.

@blueblade: Yes, Vertical Tabs are back for node/add/xxxxx (where xxxxx is the content type). First you need to go to /admin/settings/vertical-tabs and check "Expose vertical tabs selection on the edit content type forms." While you are there you may as well check "Include new fieldsets in vertical tabs by default." as that will get you most of the way on many nodes. Thereafter you can again set which items you want to be within the Vertical Tabs block from /admin/content/node-type/xxxxx pages. My personal preference is to keep Vocabularies (Taxonomy) out of VT as it can overwhelm VT really quickly on blogs and the like.

Dave, thank you so much for doing this.

As others, I was also very critical of the breaking change but, like grantkruger, there was no intention of being harsh but this is the internet and all we have to express ourselves (for now, at least) are written words, which don't carry the rest of our expressions and thus, sometimes we may seem to be reacting in a way that is not what we intended.

I'm glad to see everything turned out OK and we're all still friends in this great Drupal community.

Thanks again!

Raul

@Dave Reid. My respect man, you got a clobbering for what I thought was a reasonable development decision. You handled the situation with a lot of class.

I agree with sime.

@Dave Reid - thanks for this awesome module! I really appreciate the addition of the option for fine-grained control of vertical tabs on a per content type basis. It really helps us a lot.