Apologies for not having a patch that actually fixes this issue, but I'm rather new to the 4.7 forms API and this bug is definitely caused by some weirdness I don't quite follow.
I've got a 4.7 test site with the latest CVS copies of core and project installed. i created a single taxonomy term for the categories of projects, and created a single test project with issue tracking enabled.
whenever i try to create a new issue (either as a site admin, or as an anonymous user), i'm getting a stray '1' showing up in the "Input format" box, and none of the radio buttons are selected by default. at first, it was pretty hard to figure out where this '1' was coming from, but i tracked it down to the following:
function project_form_alter(...) {
...
$form['issue_details']['format']['format'][variable_get('filter_default_format', 1)]['#value'] = 1;
if i comment out that line, the 1 goes away. however, in that case, there's still no radio selected for the input format. :( i tried a few modifications to this line, but nothing i did managed to get any of the radio buttons selected by default. cvs annotate shows this line came from:
1.139 (thehunmo 08-Nov-05)
cvs log shows:
----------------------------
revision 1.139
date: 2005-11-08 18:23:01 +0000; author: thehunmonkgroup; state: Exp; lines: +22 -20;
changes to hook form alter to coincide w/ pending core changes
a few observations:
- according to http://drupaldocs.org/api/head/file/contributions/docs/developer/topics/..., the 'radios' form type wants an entitied called "#default_value" not "#value".
- from dumping out the contents of $form['issue_details']['format'], it seems that the array is structued like:
$form['issue_details']['format'] [1] [stuff for format filter #1...] [2] [stuff for format filter #2...] ...everything appears to be setup properly for rendering a set of radio buttons where the first is set:
-- format[1] -- #type: radio #title: Filtered HTML #default_value: 1 #return_value: 1 #parents: Array #description: * Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> * Lines and paragraphs break automatically. -- format[2] -- #type: radio #title: PHP code #default_value: 1 #return_value: 2 #parents: Array #description: * You may post PHP code. You should include <?php ?> tags. -- format[3] -- #type: radio #title: Full HTML #default_value: 1 #return_value: 3 #parents: Array #description: * Lines and paragraphs break automatically.
i don't claim to understand hook form_alter() or the forms API itself well enough to get to the bottom of this, but i know what's there is broken. ;) i'm just going to create this issue and email chad about it, so perhaps he can fix this for us.
thanks,
-derek
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | project_issue_form_submit.patch | 1.05 KB | dww |
Comments
Comment #1
pfaocleCan reproduce this one.
Comment #2
dwwthanks. i was about to follow-up to make sure i wasn't the only one seeing this. i did try with both safari and firefox and saw the same thing...
Comment #3
pfaocleFor a start, I think $form['issue_details']['format']['format'] should be $form['issue_details']['format']. Still checking this one out. I think its down to some confusion between $value, $default_value and $return_value...
Have some debug info. Before (unpatched, apart from the above mentioned removal of an extra ['format'])::
After form_alter:
Comment #4
hunmonk commentedthat spurious line of code is part of an evil hack to fool the forms API into not validating the second page of the issue submission wizard, IIRC. the last i checked, you really can't do multi-part node forms w/o this issue cropping up. the api tries to validate the second page of the form upon initial display, so you have to inject some values to bypass it. i'm guessing the structure of the filter form changed. looking into it now...
Comment #5
hunmonk commentedyep, that was it. just had to revisit the exact path to set the default value for the filter format. i hope in the future the forms api will handle multipart node forms w/o having to resort to such 'creative' solutions... ;)
fix committed to HEAD version of the module.
Comment #6
pfaocleI'm afraid this hasn't fixed anything here. The only change seems to be now the 'description' field is marked with an error (as a required field - the #validated flag is no longer TRUE). The default input format still hasn't been selected.
Comment #7
pfaocleHmm - works on a clean install of Drupal HEAD and latest project, tho. The default filter format on my test site (with an existing, populated db) isn't one of the three 'core' formats however - I have a 4th one for 'Markdown', which isn't being selected.
Comment #8
hunmonk commentedwhoop. nice catch :)
we can't set the value to 1, we have to set it to the value of the default format!
fixed in HEAD.
Comment #9
pfaocleNice one. Should the description box still be getting validated on clicking 'next'? Or is this now required to set the default filter format?
Comment #10
dwwstill broken in two ways:
the attached patch fixes both. i'll apply to HEAD.
-derek
Comment #11
dwwcommited to HEAD (revision 1.151)
Comment #12
hunmonk commentedgood catch. also, the description field had some funky form code in it that was supposed to make it conditionally required, but it wasn't working--after checking w/ killes i changed it to make that field always required, and committed to HEAD.
Comment #13
(not verified) commented