I've been discussing the CCK For Drupal 6 progress with KarenS and yched, and they've run into a wall. The #process functions, which many of the advanced CCK widgets must use, need access to the entire form and not JUST the individual element for some of the data they wrangle.

This patch just ensures that #process functions get a copy of the entire $form -- no API changes necessary, it just makes it available for the functions that need it.

CommentFileSizeAuthor
elements.patch2.15 KBeaton
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

eaton’s picture

Just poking this issue. It's not likely to get much attention this early in the beta cycle outside the folks porting CCK, given the edginess of the edge case, but it is pretty important.

Stefan Nagtegaal’s picture

Code looks good, but how should one test this?

Stefan

eaton’s picture

Code looks good, but how should one test this?

Realistically, the way to test it is to poke at elements like checkboxes and radio buttons that use complex #process functions and make sure they work. (The node edit form, with node administration permissions, is an excellent test case.) Then, feedback from KarenS and yched about whether the change is sufficient for CCK's needs.

KarenS’s picture

Sorry to be slow getting to this, but thanks for the patch Jeff. Yes, this would work for CCK. I also want to point out that it is not just for CCK that this is needed. In D5 you could pass custom parameters to #process that would contain, for instance, the node object. In D6 you can no longer pass custom parameters and all you have to work with is whatever is in the $element itself. That means that without this patch you are missing important info, like the contents of #node or #user from the $form array. So this patch is indeed critical.

The only reason no one has noticed it yet is probably because CCK is the only contrib module that has started trying to port complex FAPI capability from D5 to work in D6.

I'm not where I can do any testing right now, but will try to do so this weekend. I can't see any way it could break anything though, since it just adds an argument that wasn't there before.

chx’s picture

Status: Needs review » Reviewed & tested by the community

This is nice and dandy and as it passes on a new parameter, can't really break anything.

A followup needs to examine whether #after_build needs this or not. I suspect not because after_build is getting deprecated anyways.

Another followup patch needs to clean up the process call itself, the array_merge and the cufa is totally unnecessary, just $function with the arguments. In the past we had a possible variable number of arguments that's how we got to this point.

Gábor Hojtsy’s picture

Status: Reviewed & tested by the community » Fixed

All right, committed, thanks.

Anonymous’s picture

Status: Fixed » Closed (fixed)