Closed (fixed)
Project:
Drupal core
Version:
7.x-dev
Component:
forms system
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
23 Aug 2007 at 02:32 UTC
Updated:
16 Jun 2008 at 23:12 UTC
I do not know if the issue is known and/or being fixed in D6, but I would like to report it anyways.
Right now drupal_execute often fails when the invoked forms do not get needed includes. This happens when modules place includes into arbitrary places, not invoked through drupal_execute. This problem reared its ugly head on thorough exercise of CCK import/export. I posted a hack, but perhaps this could be addressed in D6 at the API level...
Here is the background/hack: http://drupal.org/node/128038#comment-293161
Comments
Comment #1
RobRoy commentedI'm thinking this is won't fix and should be filed against the specific form to add an include_once '...'; on the form callback.
Comment #2
dkruglyak commentedAt the very least this should be documented. Developers calling drupal_execute should know how to sanity-check the forms they use. Module developers should have guidelines for writing forms that run well in drupal_execute.
Maybe this could even warrant a "drupal_execute compatibiliy test suite" for forms... Perhaps in devel.module ???
Comment #3
RobRoy commentedOkay, I'd say the next step is filing a specific bug with any modules that need this, i.e. Views / CCK / node.module and point out the forms that need an include_once in the form declaration.
Comment #4
dkruglyak commentedI do not think this is about the node system. Any module that might use forms (not only node forms) has potential exposure and we cannot file this for every module. Filing this under Documentation for now.
Comment #5
fagoThis won't work!
Including files is done by the menu system before invoking the callback. However, if the form callback is already in the include file this doesn't help. Unfortunately I think that this is a common situation, when people are creating include files for forms, e.g. admin only forms.
So we need to find a better way how to deal with this issue.
Comment #6
eaton commentedThere are only two real solutions to this problem. One is a form registry not unlike the current theme registry, in which every form id is mapped to a set of functions and those functions can be mapped to specific files. The other is a general hook registry like the one that Crell is experimenting with. both are way outside the scope of D6.
drupal_execute() is a useful function for automating forms, but anyone using it needs to have a good handle on what files nee to be included and what prerequisites the forms they want to manipulate have. FAPI isn't smart enough at this point to handle all the setup in that way, and wasn't designed to be...
Comment #7
Crell commentedThis was discussed when the page split was being hashed out, and the decision at the time was "drupal_execute() is a funky weird edge case, so if you're going to use it, call include_once() yourself as needed." For Drupal 6, that is the solution.
For Drupal 7, yes, a more general solution is good. We'll get back to it in Drupal 7.
Comment #8
Susurrus commentedCan this issue be solved easily now that the Registry has landed?
Comment #9
damien tournoud commentedThat problem *is* solved by the registry:
drupal_retrieve_form()now correctly callsdrupal_function_exists()to fetch the form function.Now, it's up to module writers to correctly call
drupal_function_exists()from their form functions when they need additional includes.Fell free to close that issue.
Comment #10
Susurrus commentedAs said in #9.
Comment #11
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.