[Friday 21 February 2014] [18:05:56] top of the list - field_attach_form_*() [Friday 21 February 2014] [18:06:51] should be almost ready - just a question of what we do with a couple uber-specific hooks triggered by the old functions [Friday 21 February 2014] [18:07:04] for which I'm not even sure of the use cases :-) [Friday 21 February 2014] [18:07:16] summarized in last comment in there [Friday 21 February 2014] [18:07:56] so it's kind of "needs feedback" [Friday 21 February 2014] [18:09:25] yched: finding a use case for "cross widget" manipulation is really hard [Friday 21 February 2014] [18:09:58] yched: like, do X if some field uses widget Y [Friday 21 February 2014] [18:10:24] yched: I'd say drop both of those hooks [Friday 21 February 2014] [18:11:02] amateescu: yeah, I guess - I looked at field_dependency contrib module, and even though it *says* it implements the hooks, it actually doesnt :-) [Friday 21 February 2014] [18:11:09] ahh well, one second [Friday 21 February 2014] [18:11:15] in taxonomy access control [Friday 21 February 2014] [18:11:33] I had to act on anything that used core taxonomy widgets on fields [Friday 21 February 2014] [18:11:43] yched, amateescu the altering should be happening on entity form altering instead I guess [Friday 21 February 2014] [18:11:45] let me double-check--been three years [Friday 21 February 2014] [18:11:52] xjm: that's hook_field_widget_form_alter() [Friday 21 February 2014] [18:11:56] hook_field_widget_form_alter() would do the job for that [Friday 21 February 2014] [18:12:00] amateescu: well right, I added that one [Friday 21 February 2014] [18:12:09] but I also did a bunch of stuff in the field attch API [Friday 21 February 2014] [18:12:10] fago: yeah [Friday 21 February 2014] [18:12:24] if we want weird edgecase usecases :P [Friday 21 February 2014] [18:12:51] well, if we really find such rare use cases, a hook is easy enough to add in the future [Friday 21 February 2014] [18:13:07] fago: the problem is entity_form_alter() only runs on full fledged forms, not for Inline Entity Form [Friday 21 February 2014] [18:13:12] same old :-) [Friday 21 February 2014] [18:13:25] well, ok, we can drop them for now [Friday 21 February 2014] [18:13:32] and see later :-) [Friday 21 February 2014] [18:13:40] yched, so https://drupal.org/node/1728816 would be the issue we need to fix [Friday 21 February 2014] [18:13:41] https://drupal.org/node/1728816 => Ensure multiple entity forms can be embedded into one form [#1728816] => 13 comments, 5 IRC mentions [Friday 21 February 2014] [18:13:55] hook_field_attach_validate() was all I implemented other than the widget form alters, looks like [Friday 21 February 2014] [18:14:42] amateescu: that's a good point [Friday 21 February 2014] [18:14:47] fago: yeah - https://drupal.org/node/1728816 - that one is only a "beta target", not a blocker atm [Friday 21 February 2014] [18:14:48] https://drupal.org/node/1728816 => Ensure multiple entity forms can be embedded into one form [#1728816] => 13 comments, 6 IRC mentions [Friday 21 February 2014] [18:14:55] amateescu: so maybe it makes sense to scope it to a followup [Friday 21 February 2014] [18:14:57] fago: yched: yeah, we could bring back the hook in that issue if we really want to, but the widget specific hook should also work for IEF [Friday 21 February 2014] [18:15:17] because it provides a widget after all [Friday 21 February 2014] [18:15:23] that also happens to be an entity form :) [Friday 21 February 2014] [18:16:47] hook_field_attach_extract_form_values() : "alter the $entity after widgets values have been extracted into it" - honestly, dunno what's the use case :-) [Friday 21 February 2014] [18:17:34] ok, no biggie, we can always add hooks later if need be [Friday 21 February 2014] [18:17:38] yeah, it seems like anything you'd do with that, you could also do several other ways [Friday 21 February 2014] [18:18:27] I think the bigger issue is 1728816, as fago points