Simplify the module and integrate with form_controller to allow customizations

Form_controller is a 5.x module though...

Just needed to keep track of this thread...

Installing the beta6 version a noticed that there is to way configure wich form / fieldset redered as "vertical tab" and all my form becomes "verticaltabized"..
Don't you think that trying to "simplify" the module, it become more complex ? (ie: i have to install an extra dev-module, etc.)

Yeah, I was a little disappointed as well. Question for the maintainer: Would you consider a patch to re-enable the admin interface again if someone submitted one?

In the Apple voice: There's a module for that.... :)

Have to agree with PHPepe and NiklasBr. The prior functionality was simple and straightforward. I can see where this is the right choice for the future, with more complete integration with Forms module. In the short term it's a pain in the ass, especially given the -dev status of form controller and form module. Until those become fully integrated and stable, it would be nice to re-enable the easier interface.

yeah, i have to agree as well... i just spent an hour trying to figure out why my taxonomy terms suddenly became hidden down in the vertical tabs area, and where the settings to control this went. the vertical tabs ui widget is ok and all, but what i liked best about the module was how easy it made customizing/simplifying the node form.

Another thing I've noticed is that the Forms module still has a lot of incompatibilities. For example, Forms disables the Content Profile's module form for CCK types. So with forms active, you can't make changes in how a Content Profile type behaves. This essentially means that the new version of Vertical Tabs is breaking existing sites. That's not a good practice for a non -dev version update.

How to use this with CCK groups? I’ve a group name 'group_view'. Using this for my_form_id does not work.

I'd say this is critical, because existing sites are being broken by this update. This is not a -dev version, so some more stability is expected, I believe.

I add another vote to reverting back to the old functionality until Form is at least in beta.

EDIT: just to be clear, I think the general motivation for this change is good; I just don't think it was a good idea to break the old behavior like this.

I have to say I agree 100% with borfast; while this is obviously a well-intentioned change to aim for a more D7-consistent interface, Vertical Tabs is only one part of the puzzle and, while the other modules aren't ready for production sites, this change being "forced" onto users is only causing problems where none existed before.

It's a great shame, because the module is excellent; unfortunately, I only popped on here to see if this issue had been resolved before I uninstalled the module, as my site can't go on with some fieldsets being vertical-tabbed, some not, and everything being in a disordered mess until the software's available to fix everything :(

Have to agree as well; while it is not a bad thing to have this handled by another module, that other module should be stable and not highly experimental.

Dave, I believe everyone understood that the Forms module is not a requirement - but that's not the point. The point is that the update is forcing some changes that break working sites. It doesn't matter if Forms is a requirement or not; what matters is that websites that were working stopped working.

I think the correct way to handle this would have been to bump up the major version number with a new -dev branch and make the change there.

Now, don't get me wrong, I am very grateful for your work on this module, as I'm sure everyone else is. And we're expressing our opinions here in the form of constructive criticism, because we believe there was a better way to do things. In the end, you're the module maintainer, so the decisions are up to you and if the rest of us don't like it, we can either uninstall your module or just accept the change.

I have to agree with borfast and many others in the following:

• You created a great module and we were very grateful for that. The concept is elegant and classy. This is good work.
• The reasons for the change seem to be good, in terms of the long term view, particularly for Drupal 7 onwards.

But... I also agree with them that there is a problem.

Sadly, I believe this module, to some degree, is now in a kind of limbo. I'm not a Drupal expert, but the way I see it, when it comes to using this module there are six options, and I felt it would be useful to lay them out, either to help you correct me, or to help me clarify the problem. Either way.

1. Leave it as is. Verdict: An inconsistent, much watered-down solution to before. Now I have some form fieldsets in VT and some not in VT, so a couple of folks now think it looks jumbled, maybe worse than with no VT at all. Either way, it's now only a partial fix at best.
2. Install the Form module. Verdict: Highly inadvisable. It is not ready for production sites and a major rewrite is coming, which may change everything. Or may never happen at all.
3. Temporarily install the Form module, then uninstall it. Verdict: Maybe the best approach, but still far from ideal. Although you have said that this is doable, now I would need to reinstall Form every time I have to add a new form, and then uninstall it again. Also every time I add a module that extends the edit form. That's a lot of unnecessary overhead, but even then, what if the rewrite of Form is radically different? Will you then cater for redundant settings? Or will we again do an update and find that nothing works anymore?
4. Add PHP code to the settings file. Verdict: Cumbersome, awkward and not ideal. Aside from the fact that many Drupal sites are created by people who are not coders and will struggle to do this, if at all, I do not believe that any module should require PHP code to be written. Further, you have to hunt down a host of form names and then all the fieldset names... and I still don't know what the fieldset names are for XML sitemap, scheduling options, print/email and other commonly used modules that extend the edit forms (as I said, I'm a coder, but I'm no Drupal expert). Even so, maintenance is going to be a bear. You have to change this chunk of code every time you add a module that extends edit forms and you have to change it every time you add a form/content type. Further, for security reasons, those on teams using version control do not check-in settings files, so this code has to be shared in a whole new way and everyone on the team has to change their own local settings file, and the same for the test and live sites. And this process will be repeated every time the settings file needs to be changed. More steps in an already involved process. More opportunities for errors to creep in. And what happens when the Form module is finally completed? Well this code and any special provisions have to now be removed. It's messy, complicated and prone to error.
5. Revert to the previous "working" VT version. Verdict: Not a good approach. Complications with security patches and new functionality alone make this untenable, not to mention the drush issues.
6. Uninstall the module. Verdict: A very unhappy approach. We lose everything we installed this fantastic module for in the first place, including prepping our users for the eventual Drupal 7 upgrade. We lose a quality module that is so good it will forever be in core from now on.

So we went from a working module that guys like me were blogging about and talking about at DUGs, to one that is not really workable and that many of us may be forced to consider dropping, for reasons of site stability and usability, or because our users say so. This is not pique, this is a hard decision forced on us. As has been suggested, it may be that the changes you made needed to either wait for a production-ready Form module, or to be applied only to the Drupal 7 version.

I do apologize for these negative comments. I sure hated writing them. I'm not trying to get you down or break your motivation. I want this module to go from strength to strength. You've done fantastic work here. I want very much for that to continue. However, this stream did not seem to be going anywhere, so I felt it may be useful, right or wrong, to just list the options and point out the weaknesses that I believe were introduced with the new version. I feel that at best it is not adhering to best practices, but really, to me this issue is a bug, not a feature request.

Again, my thanks for all your hard work and my apologies for my bluntness.

I am so confused. Are we not supposed to use VT on production sites? Form module says not to use Form on production sites.

Is there any chance that the integration with Form can be moved to a 6.x-2.x-dev version, with 6.x-1.0-beta8 (when it comes out) reverting to the UI that was available in beta5? I don't mean to sound like I'm piling on (grantkruger summed up my own feelings far more thoroughly and thoughtfully than I could have), but this change of direction is causing a lot of near-term problems for the sites that depend on it.