Jump to:
| Project: | Drupal For Firebug |
| Version: | 6.x-1.2 |
| Component: | Miscellaneous |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (duplicate) |
Issue Summary
This could be a feature request, support request, and bug report all in one.
Environment:
- XAMPP 1.7.0 stock install (Apache 2.2.11, MySQL 5.1.30, PHP 5.2.8, Zend Optimizer 3.3.3)
- Firebug 1.3.3, FirePHP 0.2.4, DrupalForFirebug extension 0.0.5
- Drupal 6.9 with Drupal for Firebug 6.x-1.2
I've used the Profile module to augment the standard User implementation. I am now trying to use this handy Firebug enhancement to investigate the $form and $form_state arrays in order to due some specialized validatation on the user_register and user_profile_form forms.
A nice feature would be to include $form_state along with $form in the Firebug Drupal Forms tab. $form_state is what you want to be investigating when validating a form.
In order to view $form_state, I have added firep($form_state, '$form_state') to the validate function declared in my hook_form_alter implementation. The hook and validation are working fine, the Forms tab is displaying $form, and whenever I throw a form_set_error() in the validation function, $form_state is correctly displayed in the General tab. I can also use firep() successfully in the form_alter hook, but I can't get firep() to send any message to the general log during validation unless I invoke form_set_error(). I need to examine $form_state during validation in all cases.
I've tried just sending 'foo'. I've tried using drupal_set_message() directly without the error flag. No joy. The theme prints $closure in page.tpl.php, so that's not an issue (tested Garland as well).
Any ideas? I have yet to investigate the Firebug integration via the Devel module to see whether that might be useful.
Comments
#1
I really like your idea about adding $form_state to the normal information that is being passed back, since that ends up being really important for general debugging. I also think a little bit of focus on the handling of forms could go a long way to fixing this issue.
Generally, I suspect what is going on is that DFF is losing information as it passes through validation and redirect functions. The general messages are set in a general variable which may be getting reset. My guess is if you used firep($form_state) in your submit handler it would work fine.
I am not sure the best approach here, but I think it may fall under a larger issue of handling more complex Drupal page workflows where pages/forms get routed around.
#2
This is a duplicate (in some ways ) of #301248: Saving State Through Page Reloads (like form submissions). Looking into making a solution for both.