- Development - lists.drupal.org

[drupal-devel] [bug] Forum module's use of if in Postgresql
by patrickslee 25 May '05

25 May '05

Issue status update for http://drupal.org/node/23499 Project: Drupal Version: 4.6.0 Component: forum.module Category: bug reports Priority: normal Assigned to: patrickslee Reported by: cchamilt Updated by: patrickslee Status: patch So my patch will work, and we can make it easier by replacing the IF function to: IF(l.last_comment_uid 0 AND l.last_comment_uid NULL, cu.name, l.last_comment_name) BTW there is another place in forum.module use IF like this. patrickslee Previous comments: ------------------------------------------------------------------------ May 24, 2005 - 16:32 : cchamilt Postgresql function "if" is defined to return a boolean value, yet forum requests an integer - last_comment_uid. user error: query: SELECT n.nid, l.last_comment_timestamp, IF(l.last_comment_uid, cu.name, l.last_comment_name) as last_comment_name, l.last_comment_uid FROM node n, node_comment_statistics l /*! USE INDEX (node_comment_timestamp) */, users cu, term_node r WHERE n.nid = r.nid AND r.tid = 1 AND n.status = 1 AND n.type = 'forum' AND l.last_comment_uid = cu.uid AND n.nid = l.nid ORDER BY l.last_comment_timestamp DESC LIMIT 1 OFFSET 0 in /var/www/hosts/www.ambigc.com/htdocs/includes/database.pgsql.inc on line 62. warning: pg_query() [function.pg-query]: Query failed: ERROR: function if(integer, character varying, character varying) does not exist HINT: No function matches the given name and argument types. You may need to add explicit type casts. in /var/www/hosts/www.ambigc.com/htdocs/includes/database.pgsql.inc on line 45. ------------------------------------------------------------------------ May 25, 2005 - 10:07 : patrickslee Attachment: http://drupal.org/files/issues/forum.module_3.patch (2.69 KB) I have also encountered this bug and made a possible patch by replacing IF statements to CASE. A patch file is attached. ------------------------------------------------------------------------ May 25, 2005 - 10:28 : adrian There is an IF function defined in the database.pgsql function. On what page is this happening, as what might be happening is that the type isn't being picked up correctly. It's defined as IF(anyelement, anyelement, text) returns anyelement. IIRC. What I have seen happen is that it wants the text field to return integer, or vice versa. ------------------------------------------------------------------------ May 25, 2005 - 10:32 : patrickslee I found the definition in database.pgsql. It is like this: CREATE FUNCTION "if"(boolean, anyelement, anyelement) RETURNS anyelement AS ' SELECT CASE WHEN $1 THEN $2 ELSE $3 END; ' LANGUAGE 'sql'; So it is actually wanting boolean.

1 0

[drupal-devel] [bug] Forum module's use of if in Postgresql
by patrickslee 25 May '05

25 May '05

Issue status update for http://drupal.org/node/23499 Project: Drupal Version: 4.6.0 Component: forum.module Category: bug reports Priority: normal Assigned to: patrickslee Reported by: cchamilt Updated by: patrickslee Status: patch I found the definition in database.pgsql. It is like this: CREATE FUNCTION "if"(boolean, anyelement, anyelement) RETURNS anyelement AS ' SELECT CASE WHEN $1 THEN $2 ELSE $3 END; ' LANGUAGE 'sql'; So it is actually wanting boolean. patrickslee Previous comments: ------------------------------------------------------------------------ May 24, 2005 - 16:32 : cchamilt Postgresql function "if" is defined to return a boolean value, yet forum requests an integer - last_comment_uid. user error: query: SELECT n.nid, l.last_comment_timestamp, IF(l.last_comment_uid, cu.name, l.last_comment_name) as last_comment_name, l.last_comment_uid FROM node n, node_comment_statistics l /*! USE INDEX (node_comment_timestamp) */, users cu, term_node r WHERE n.nid = r.nid AND r.tid = 1 AND n.status = 1 AND n.type = 'forum' AND l.last_comment_uid = cu.uid AND n.nid = l.nid ORDER BY l.last_comment_timestamp DESC LIMIT 1 OFFSET 0 in /var/www/hosts/www.ambigc.com/htdocs/includes/database.pgsql.inc on line 62. warning: pg_query() [function.pg-query]: Query failed: ERROR: function if(integer, character varying, character varying) does not exist HINT: No function matches the given name and argument types. You may need to add explicit type casts. in /var/www/hosts/www.ambigc.com/htdocs/includes/database.pgsql.inc on line 45. ------------------------------------------------------------------------ May 25, 2005 - 10:07 : patrickslee Attachment: http://drupal.org/files/issues/forum.module_3.patch (2.69 KB) I have also encountered this bug and made a possible patch by replacing IF statements to CASE. A patch file is attached. ------------------------------------------------------------------------ May 25, 2005 - 10:28 : adrian There is an IF function defined in the database.pgsql function. On what page is this happening, as what might be happening is that the type isn't being picked up correctly. It's defined as IF(anyelement, anyelement, text) returns anyelement. IIRC. What I have seen happen is that it wants the text field to return integer, or vice versa.

1 0

[drupal-devel] [bug] Forum module's use of if in Postgresql
by adrian 25 May '05

25 May '05

Issue status update for http://drupal.org/node/23499 Project: Drupal Version: 4.6.0 Component: forum.module Category: bug reports Priority: normal Assigned to: patrickslee Reported by: cchamilt Updated by: adrian Status: patch There is an IF function defined in the database.pgsql function. On what page is this happening, as what might be happening is that the type isn't being picked up correctly. It's defined as IF(anyelement, anyelement, text) returns anyelement. IIRC. What I have seen happen is that it wants the text field to return integer, or vice versa. adrian Previous comments: ------------------------------------------------------------------------ May 24, 2005 - 06:32 : cchamilt Postgresql function "if" is defined to return a boolean value, yet forum requests an integer - last_comment_uid. user error: query: SELECT n.nid, l.last_comment_timestamp, IF(l.last_comment_uid, cu.name, l.last_comment_name) as last_comment_name, l.last_comment_uid FROM node n, node_comment_statistics l /*! USE INDEX (node_comment_timestamp) */, users cu, term_node r WHERE n.nid = r.nid AND r.tid = 1 AND n.status = 1 AND n.type = 'forum' AND l.last_comment_uid = cu.uid AND n.nid = l.nid ORDER BY l.last_comment_timestamp DESC LIMIT 1 OFFSET 0 in /var/www/hosts/www.ambigc.com/htdocs/includes/database.pgsql.inc on line 62. warning: pg_query() [function.pg-query]: Query failed: ERROR: function if(integer, character varying, character varying) does not exist HINT: No function matches the given name and argument types. You may need to add explicit type casts. in /var/www/hosts/www.ambigc.com/htdocs/includes/database.pgsql.inc on line 45. ------------------------------------------------------------------------ May 25, 2005 - 00:07 : patrickslee Attachment: http://drupal.org/files/issues/forum.module_3.patch (2.69 KB) I have also encountered this bug and made a possible patch by replacing IF statements to CASE. A patch file is attached.

1 0

[drupal-devel] [bug] Forum module's use of if in Postgresql
by patrickslee 25 May '05

25 May '05

Issue status update for http://drupal.org/node/23499 Project: Drupal Version: 4.6.0 Component: forum.module Category: bug reports Priority: normal -Assigned to: Anonymous +Assigned to: patrickslee Reported by: cchamilt Updated by: patrickslee -Status: active +Status: patch Attachment: http://drupal.org/files/issues/forum.module_3.patch (2.69 KB) I have also encountered this bug and made a possible patch by replacing IF statements to CASE. A patch file is attached. patrickslee Previous comments: ------------------------------------------------------------------------ May 24, 2005 - 16:32 : cchamilt Postgresql function "if" is defined to return a boolean value, yet forum requests an integer - last_comment_uid. user error: query: SELECT n.nid, l.last_comment_timestamp, IF(l.last_comment_uid, cu.name, l.last_comment_name) as last_comment_name, l.last_comment_uid FROM node n, node_comment_statistics l /*! USE INDEX (node_comment_timestamp) */, users cu, term_node r WHERE n.nid = r.nid AND r.tid = 1 AND n.status = 1 AND n.type = 'forum' AND l.last_comment_uid = cu.uid AND n.nid = l.nid ORDER BY l.last_comment_timestamp DESC LIMIT 1 OFFSET 0 in /var/www/hosts/www.ambigc.com/htdocs/includes/database.pgsql.inc on line 62. warning: pg_query() [function.pg-query]: Query failed: ERROR: function if(integer, character varying, character varying) does not exist HINT: No function matches the given name and argument types. You may need to add explicit type casts. in /var/www/hosts/www.ambigc.com/htdocs/includes/database.pgsql.inc on line 45.

1 0

[drupal-devel] [bug] form() should respect block level elements.
by Robin Monks 24 May '05

24 May '05

Issue status update for http://drupal.org/node/23387 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: Robin Monks Reported by: Robin Monks Updated by: Robin Monks Status: patch Attachment: http://drupal.org/files/issues/empty div form item fix.patch (682 bytes) This patch uses a blank div to allow block level ellements (like input> to go inside the form element per xhtml 1.0 specs. This patch works and validates, and is required for validation. Robin Robin Monks

3 6

[drupal-devel] [bug] non-standard form fields
by Dries 24 May '05

24 May '05

Issue status update for http://drupal.org/node/23531 Project: Drupal Version: cvs Component: user.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: Alex Reisner Updated by: Dries Status: patch IMO, the usability of the forms degrades with this patch. It makes them look weird-ish. Dries Previous comments: ------------------------------------------------------------------------ May 24, 2005 - 19:40 : Alex Reisner User.module manually creates several form fields (on lines 1091 and 1664) rather than calling the form_ functions in common.inc. The fields on line 1664 are lacking a class attribute and all are missing id attributes, making their appearances difficult to control. It strikes me as better if the form_ functions were used, but I don't know enough about user.module to know if this is possible. At least the class and id info should be added manually. Relevant code: *Line 1091* $group .= form_item(t('Password'), '<input type="password" class="form-password" name="edit[pass1]" size="12" maxlength="24" /> <input type="password" class="form-password" name="edit[pass2]" size="12" maxlength="24" />', t('Enter your new password twice if you want to change your current password, or leave it blank if you are happy with your current password.'), NULL, TRUE); *Line 1664* $rows[] = array('<input type="text" size="32" maxlength="64" name="edit[name]" />', '<input type="submit" name="op" value="'. t('Add role') .'" />'); ------------------------------------------------------------------------ May 24, 2005 - 20:12 : Robin Monks Attachment: http://drupal.org/files/issues/hard.coded.form.fields.patch (2.19 KB) This patch should take care of that. I was unable to get someone to review it, so it may have a rough spot. Robin

1 0

[drupal-devel] [bug] Autocomplete HTTP errors don't stop throbber
by Thox 24 May '05

24 May '05

Issue status update for http://drupal.org/node/23506 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: Thox Updated by: Thox Status: patch Attachment: http://drupal.org/files/issues/autocomplete.js.patch (1.14 KB) When using an autocomplete field, the throbber icon does not dissapear after HTTP errors (e.g. 404 if the autocomplete url is not found). Attached patch fixes this and also makes it work in one of my modules where the same autocomplete javascript object (ACDB) is shared by many controls (they're all recipe ingredient fields, so they share the same cache). Thox

4 6

[drupal-devel] [bug] Make form_textarea() XHTML ready
by Robin Monks 24 May '05

24 May '05

Issue status update for http://drupal.org/node/23530 Project: Drupal Version: 4.6.0 Component: base system Category: bug reports Priority: normal Assigned to: Robin Monks Reported by: Robin Monks Updated by: Robin Monks Status: patch Attachment: http://drupal.org/files/issues/xhtml_form__textarea.patch (1.53 KB) This patch uses CSS formatting to format textboxes (as per XHTML standards) and removes the wrap artifact (which was no longer needed as of NS2.0 and IE4.0). This patch uses "em" to format by character, this is backwards compatible with previous calls (give or take a few pixels). Robin Robin Monks

2 2

[drupal-devel] [bug] non-standard form fields
by Robin Monks 24 May '05

24 May '05

Issue status update for http://drupal.org/node/23531 Project: Drupal Version: cvs Component: user.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: Alex Reisner Updated by: Robin Monks -Status: active +Status: patch Attachment: http://drupal.org/files/issues/hard.coded.form.fields.patch (2.19 KB) This patch should take care of that. I was unable to get someone to review it, so it may have a rough spot. Robin Robin Monks Previous comments: ------------------------------------------------------------------------ May 24, 2005 - 17:40 : Alex Reisner User.module manually creates several form fields (on lines 1091 and 1664) rather than calling the form_ functions in common.inc. The fields on line 1664 are lacking a class attribute and all are missing id attributes, making their appearances difficult to control. It strikes me as better if the form_ functions were used, but I don't know enough about user.module to know if this is possible. At least the class and id info should be added manually. Relevant code: *Line 1091* $group .= form_item(t('Password'), '<input type="password" class="form-password" name="edit[pass1]" size="12" maxlength="24" /> <input type="password" class="form-password" name="edit[pass2]" size="12" maxlength="24" />', t('Enter your new password twice if you want to change your current password, or leave it blank if you are happy with your current password.'), NULL, TRUE); *Line 1664* $rows[] = array('<input type="text" size="32" maxlength="64" name="edit[name]" />', '<input type="submit" name="op" value="'. t('Add role') .'" />');

1 0

[drupal-devel] Loved the newsletter!
by Gordon Heydon 24 May '05

24 May '05

Hi everyone, it's... I got the first newsletter today and I just loved it, it was really good. I am not just saying this, because I am in the first article. But it was very interesting and it was just great. I will be eagerly waiting for issue 2 next week ;-) The only thing that I was wondering is that is there a web version of the newsletter. Sometimes I find it a bit easer to read than email text versions. Also it is always easier when you want to do back to past issues. Keep up the great work. Gordon.

3 2