- Development - lists.drupal.org

[drupal-devel] [bug] have db_prefix_tables() handle 'default' key not being set
by Dries 08 Apr '05

08 Apr '05

Issue status update for http://drupal.org/node/19609 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: danielc Updated by: Dries Status: patch I was checking settings.php to read up on how to use $db_prefix but noticed that only the 'simple' case was documented. The fact that $db_prefix can be an array isn't explained anywhere (not in the phpdoc of db_prefix_tables() and not in settings.php). Where did that go? I wanted to check what the documentation had to say on the availability of a 'default' entry ... Dries Previous comments: ------------------------------------------------------------------------ March 28, 2005 - 23:24 : danielc Attachment: http://drupal.org/files/issues/database.diff (720 bytes) The db_prefix_tables() function in includes/database.inc generates notices if $db_prefix['default'] is not set. This patch fixes that problem. This has a side benefit of making $db_prefix easier to use. ------------------------------------------------------------------------ March 29, 2005 - 00:06 : moshe weitzman nice ... this has been a bit a pimple for a while. ------------------------------------------------------------------------ March 29, 2005 - 17:40 : danielc Attachment: http://drupal.org/files/issues/database2.diff (1.17 KB) I've come up with a new version of the patch that optimizes the speed of the whole function. ------------------------------------------------------------------------ March 29, 2005 - 17:56 : danielc Change Version from "4.5.2" to "cvs". ------------------------------------------------------------------------ March 29, 2005 - 18:01 : danielc Pardon me, I'm testing if this goes the drupal-dev list now that the version is "cvs." ------------------------------------------------------------------------ April 3, 2005 - 14:45 : Dries Any idea of how much faster the second patch is? I don't think it makes a real difference in which case I'd favor the first patch. ------------------------------------------------------------------------ April 3, 2005 - 20:40 : danielc The speed increase is 5%. ------------------------------------------------------------------------ April 3, 2005 - 20:52 : Dries 5% compared to what? What did you measure? ------------------------------------------------------------------------ April 4, 2005 - 06:56 : danielc I tested the db_prefix_tables() function in two configurations. With my first patch applied and with my second patch applied. The second patch is 5% faster than the first. This improvement is the same for both the string and array formats of $db_url. ------------------------------------------------------------------------ April 8, 2005 - 02:43 : danielc Can this please be applied to 4-6 and HEAD?

1 0

[drupal-devel] [bug] conf_init should strip out port numbers in bootstrap.inc
by Dries 08 Apr '05

08 Apr '05

Issue status update for http://drupal.org/node/19934 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: chx Reported by: bwooster47 Updated by: Dries Status: patch Won't commit. Removing the port seems like a bad idea (I could have two drupal sites at two different ports but otherwise identical URLs) and adding regex' all over the map isn't advised. If ":" is an invalid character, then there might be more such characters. I suggest we replace them with '.' and that we document this behavior much like we do with $db_url. Dries Previous comments: ------------------------------------------------------------------------ April 4, 2005 - 01:07 : bwooster47 The latest Drupal from CVS (4.6.0) offers multisite configuration files, but currently the conf_init function in includes/bootstrap.inc will also include the :portnum URL specification in the directory name, which does not seem right (and the colon character may cause problems on Mac/Windows). Snippet from bootstrap.inc: * Example for a fictitious site installed at * http://www.drupal.org/mysite/test/ the 'settings.php' is * searched in the following directories: ..... If the site is: http://www.drupal.org:8080/mysite/test/ the same list of directories should be searched as listed in the example in the file, and the :8080 should not be added to the directory name (I think...) I don't know enough PHP to submit a patch, but this is probably easy for those who know this stuff :-) ------------------------------------------------------------------------ April 8, 2005 - 09:08 : chx Attachment: http://drupal.org/files/issues/conf_init_ports.patch (768 bytes) Here you are.

1 0

[drupal-devel] [bug] Private downloads aren't working
by stefan nagtegaal 08 Apr '05

08 Apr '05

Issue status update for http://drupal.org/node/12267 Project: Drupal Version: cvs Component: file system Category: bug reports Priority: critical Assigned to: Anonymous Reported by: stefan nagtegaal Updated by: stefan nagtegaal -Status: active +Status: patch This is still an issue in 4.6 RC and can still be reproduced by follwing exactly what I propose above.. While this is a longstanding bug, and with drupal 4.6 I'll changed status to patch.. Maybe some other people ould have a look at this? stefan nagtegaal Previous comments: ------------------------------------------------------------------------ October 29, 2004 - 11:37 : stefan nagtegaal The private downloads are not working properly.. How to reproduce: Goto 'http://www.your-site.com/admin/settings' and set the 'Download method' to 'Private - files are transferred by Drupal'. Now, you make a new item (blog/story/page/poll, whatever) and upload an image. You should use this image inside your post, by doing an '' inside your post, where $path is the url which is given in the 'Attachments' form-group on the submission page. (Something like 'system/files?file=$yourfile.ext') Then click 'Preview' and do not submit the node! Now, have a look what we see.. We see that the image inside the post isn't displayed properly. The image is broken. If we ask the properties of the image it points to the right location ('system/files?file=$yourfile.ext'), but isn't displayed. If we take a look at the properties of the table under the node (attached files table with 'Attachement', and 'List') we see that the attachment is pointing to something like 'http://www.frontaal-online.com/$file-system-path/$yourfile.ext' instead of the private download url.. I'm not sure how to fix this, but I think it's a bug inside function file_create_url() which could be found inside file.inc. ------------------------------------------------------------------------ October 29, 2004 - 11:51 : stefan nagtegaal Attachment: http://drupal.org/files/issues/upload-and-body.png (19.87 KB) Screenshot after upload en filling in the body.form ------------------------------------------------------------------------ October 29, 2004 - 11:52 : stefan nagtegaal Attachment: http://drupal.org/files/issues/node-preview-and-image-properties.png (78.18 KB) Now we are previewing the node with a broken image in it.. See the properties of the image, which points to another location as the 'metallic.png' hyperlink inside the 'Attachment'-table under the node preview. ------------------------------------------------------------------------ October 29, 2004 - 11:54 : stefan nagtegaal Attachment: http://drupal.org/files/issues/properties-of-metallic-link-in-attachments-t… (53.52 KB) The properties of the 'metallic.png'-link inside the table under the node preview differs from where the source points us to.. The url inside the table works, (which is the same as in public_dowloads), but the url inside the body isn't... ------------------------------------------------------------------------ October 29, 2004 - 12:47 : stefan nagtegaal This bug is also appearing inside drupal 4.5... ------------------------------------------------------------------------ January 28, 2005 - 18:04 : walkah Attachment: http://drupal.org/files/issues/upload-private-files.patch (1.88 KB) here's a small patch to fix. basically the custom url rewriting (for when files haven't been yet saved to their final location) wasn't taking into account FILE_DOWNLOADS_PRIVATE. this fixes that (oh, and it also fixes an sql error in upload_download as well). ------------------------------------------------------------------------ January 28, 2005 - 18:07 : walkah Attachment: http://drupal.org/files/issues/upload-4-5.patch (1.36 KB) here's a version for 4.5 as well ... (where the SQL wasn't broken). ------------------------------------------------------------------------ February 5, 2005 - 09:34 : Steven Isn't that SQL 'error' there to make query rewriting work? ------------------------------------------------------------------------ February 5, 2005 - 09:36 : Steven By the way, I still think we should alter the autop filter so it uses & rather than making this one use a numbered entity. 'amp' is the most common notation out there, and it's shorter too. ------------------------------------------------------------------------ March 13, 2005 - 20:14 : killes(a)www.drop.org Doesn't apply anymore. Is this still an issue? ------------------------------------------------------------------------ April 7, 2005 - 03:56 : moshe weitzman this one is marked critical. Walkah, Stefan - please comment on whether this is still a bug. ------------------------------------------------------------------------ April 8, 2005 - 02:13 : Shane Birley This might point some people in the correct direction. It isn't completely the same issue, but related, I would think and might need to be fixed prior. http://drupal.org/node/17364

1 0

[drupal-devel] [bug] update.inc is a bit broken
by chx 08 Apr '05

08 Apr '05

Issue status update for http://drupal.org/node/20172 Project: Drupal Version: cvs Component: database system Category: bug reports Priority: normal Assigned to: chx Reported by: chx Updated by: chx Status: patch Attachment: http://drupal.org/files/issues/update_3.patch (1.13 KB) I do not know why but update_sql() is not the last function anymore. Let's move it... chx

2 1

[drupal-devel] [bug] Container lost when editing a forum
by chx 08 Apr '05

08 Apr '05

Issue status update for http://drupal.org/node/19615 Project: Drupal Version: cvs Component: forum.module Category: bug reports -Priority: normal +Priority: critical -Assigned to: Anonymous +Assigned to: chx Reported by: Anonymous Updated by: chx -Status: active +Status: patch Attachment: http://drupal.org/files/issues/forum_edit.patch (1.04 KB) It seems that we are handing an array of taxonomy objects as parent instead of an integer as we should. This happens on all editing not just right after creation. chx Previous comments: ------------------------------------------------------------------------ March 28, 2005 - 23:20 : Anonymous To reproduce: 1. Create a forum container 2. Create a forum as a child of that container 3. Edit the forum created in 2. You will see that the Parent dropdown has been set back to .

1 0

[drupal-devel] [bug] form_checkboxes saves "no selection" as string
by chx 08 Apr '05

08 Apr '05

Issue status update for http://drupal.org/node/18663 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: critical Assigned to: chx Reported by: killes(a)www.drop.org Updated by: chx Status: patch Attachment: http://drupal.org/files/issues/form_checkboxes_2.patch (1.9 KB) killes did not like the previous version. chx Previous comments: ------------------------------------------------------------------------ March 10, 2005 - 02:51 : killes(a)www.drop.org If you select nothing from a set of checkboxes an empty string is save to the variables table. This is a problem if the calling code assumes, it would get an array. We should make it save an empty array. The problem is the form_hidden field that we add. even if we replace form_hidden($name, 0) by form_hidden($name, array()) it isn't going to work, because the empty array is eaten by htmlspecialchars. redLED found this bug and he does not like it: 02:53 < redLED> i just like things saying 'CRITICAL' in red 02:53 < redLED> it gives this warm impending doom feeling 02:53 < redLED> and is generally associated with nuclear reactors in people's subconsciousness Suggestions welcome. ------------------------------------------------------------------------ March 12, 2005 - 19:47 : Steven There is no way to fix it in form_checkboxes() itself afaik, because even without htmlspecialchars, it would still come out as "Array". You can only create arrays indirectly through form submissions, by naming your values "foo[]". But you can not create empty arrays this way. So it is really up to the module which uses form_checkboxes() to handle this. A simple is_array() should do the trick. ------------------------------------------------------------------------ March 28, 2005 - 17:27 : chx Attachment: http://drupal.org/files/issues/checkboxes.patch (1.71 KB) system_settings_save can not really cope with this situation. This makes a problem with empty node options. And the fact that we have a check everywhere we use form_checkboxes is error prone, too. Here is a patch. If this accepted I'll comb the core for dead code. For eg. the first three lines of taxonomy_save_vocabulary and so. ------------------------------------------------------------------------ March 28, 2005 - 17:32 : chx Attachment: http://drupal.org/files/issues/checkboxes_0.patch (1.71 KB) Oh NO! One strayed space! I fixed it before steven beheads me.... ------------------------------------------------------------------------ March 28, 2005 - 18:36 : chx Attachment: http://drupal.org/files/issues/checkboxes_1.patch (1.64 KB) Among other changes, I have moved the hidden field form_checkboxes[] out of $edit. I have included HTML code, yes, but this is a very special thing, so it does not merit changing form_input just 'cos of this. And you won't need to theme a hidden field...

1 0

[drupal-devel] [bug] conf_init should strip out port numbers in bootstrap.inc
by chx 08 Apr '05

08 Apr '05

Issue status update for http://drupal.org/node/19934 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal -Assigned to: Anonymous +Assigned to: chx Reported by: bwooster47 Updated by: chx -Status: active +Status: patch Attachment: http://drupal.org/files/issues/conf_init_ports.patch (768 bytes) Here you are. chx Previous comments: ------------------------------------------------------------------------ April 4, 2005 - 00:07 : bwooster47 The latest Drupal from CVS (4.6.0) offers multisite configuration files, but currently the conf_init function in includes/bootstrap.inc will also include the :portnum URL specification in the directory name, which does not seem right (and the colon character may cause problems on Mac/Windows). Snippet from bootstrap.inc: * Example for a fictitious site installed at * http://www.drupal.org/mysite/test/ the 'settings.php' is * searched in the following directories: ..... If the site is: http://www.drupal.org:8080/mysite/test/ the same list of directories should be searched as listed in the example in the file, and the :8080 should not be added to the directory name (I think...) I don't know enough PHP to submit a patch, but this is probably easy for those who know this stuff :-)

1 0

[drupal-devel] [bug] have db_prefix_tables() handle 'default' key not being set
by danielc 08 Apr '05

08 Apr '05

Issue status update for http://drupal.org/node/19609 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: danielc Updated by: danielc Status: patch Can this please be applied to 4-6 and HEAD? danielc Previous comments: ------------------------------------------------------------------------ March 28, 2005 - 16:24 : danielc Attachment: http://drupal.org/files/issues/database.diff (720 bytes) The db_prefix_tables() function in includes/database.inc generates notices if $db_prefix['default'] is not set. This patch fixes that problem. This has a side benefit of making $db_prefix easier to use. ------------------------------------------------------------------------ March 28, 2005 - 17:06 : moshe weitzman nice ... this has been a bit a pimple for a while. ------------------------------------------------------------------------ March 29, 2005 - 10:40 : danielc Attachment: http://drupal.org/files/issues/database2.diff (1.17 KB) I've come up with a new version of the patch that optimizes the speed of the whole function. ------------------------------------------------------------------------ March 29, 2005 - 10:56 : danielc Change Version from "4.5.2" to "cvs". ------------------------------------------------------------------------ March 29, 2005 - 11:01 : danielc Pardon me, I'm testing if this goes the drupal-dev list now that the version is "cvs." ------------------------------------------------------------------------ April 3, 2005 - 07:45 : Dries Any idea of how much faster the second patch is? I don't think it makes a real difference in which case I'd favor the first patch. ------------------------------------------------------------------------ April 3, 2005 - 13:40 : danielc The speed increase is 5%. ------------------------------------------------------------------------ April 3, 2005 - 13:52 : Dries 5% compared to what? What did you measure? ------------------------------------------------------------------------ April 3, 2005 - 23:56 : danielc I tested the db_prefix_tables() function in two configurations. With my first patch applied and with my second patch applied. The second patch is 5% faster than the first. This improvement is the same for both the string and array formats of $db_url.

1 0

[drupal-devel] [bug] undefined index: port in database.pgsql.inc on line 27
by danielc 08 Apr '05

08 Apr '05

Issue status update for http://drupal.org/node/19868 Project: Drupal Version: cvs Component: database system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: danielc Updated by: danielc Status: patch Attachment: http://drupal.org/files/issues/database.pgsql.inc.port.diff (757 bytes) The port number for PostgreSQL $db_url's doesn't need to be set. If it's not, then $url['port'] isn't either. This situation generates the following notice: Notice: Undefined index: port in x:\drupal\includes\database.pgsql.inc on line 27 This patch fixes the situation by wrapping the operator in !empty(). danielc

1 1

[drupal-devel] [bug] User info should not be visible without permission
by killes 07 Apr '05

07 Apr '05

Issue status update for http://drupal.org/node/4166 Project: Drupal -Version: cvs +Version: cvs Component: user system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: mic Updated by: killes(a)www.drop.org -Status: active +Status: patch It's a patch (which still applies and wants into core). killes(a)www.drop.org Previous comments: ------------------------------------------------------------------------ November 17, 2003 - 06:23 : mic When anonymous visitors do not have "Access userlist" permission, they can still view all the public info in user profiles. Drupal sites that are created for a group of friends or for an organization want to protect their e-mail addresses, telephone numbers and so on, while making these accessible to fellow members. This could be a critical feature request, but since I think it's an error, I'm sending you this as bug. (I don't have CVS, so I'm hoping someone else will make the simple correction needed to the user module) ------------------------------------------------------------------------ February 3, 2004 - 05:41 : daBrado Attachment: http://drupal.org/files/issues/user-module-add-view-permission.patch (1.54 KB) I made a patch that fixed this by adding a new permission, "access users". This is everything this patch does: Add new permission, "access users" If a user does not have the "access users" permission, s/he cannot read another user's profile at all, and instead gets an "access denied" page. I hope I did this in the proper way. ------------------------------------------------------------------------ April 21, 2004 - 20:25 : Dries I think we should not introduce a new permission but merge with the existing 'access user list' permission (or rename it to 'access users'). Marking this "won't fix" until the patch has been udpated. ------------------------------------------------------------------------ May 28, 2004 - 02:26 : daBrado Attachment: http://drupal.org/files/issues/user-module-add-view-permission_0.patch (1.88 KB) Another patch, this time renaming the permission "access user list" to "access users", and adding a check in the user viewing function to only allow users with this permission to view the user information. ------------------------------------------------------------------------ July 5, 2004 - 15:31 : Anonymous Attachment: http://drupal.org/files/issues/user-module-add-view-permission_1.patch (1.86 KB) Here is a patch again, now for CVS. Does the same thing as above. It is a very simple patch. If it seems proper, I hope that can be included before it goes stale. ------------------------------------------------------------------------ July 9, 2004 - 02:08 : daBrado Attachment: http://drupal.org/files/issues/user-module-add-view-permission_2.patch (1.33 KB) The previous patch was accepted, but then for some reason reversed as part of another CVS commit. So, here is a new patch that brings back the "access users" permission. It controls whether or not a user may view other users info. ------------------------------------------------------------------------ September 22, 2004 - 16:53 : Bèr Kessels Attachment: http://drupal.org/files/issues/access_users_perm.patch (6.46 KB) A new and revised patch. It adds an "access users" permission ------------------------------------------------------------------------ September 22, 2004 - 18:02 : killes(a)www.drop.org I'd like to see this patch applied to cvs before the 4.5 release. Now that we can protect our nodes from unauthorized access it just makes sense to protect our user data as well. In the future I'd like to see scheme where the user (as in end-user) is able to selet which of his data gets published. ------------------------------------------------------------------------ September 23, 2004 - 01:52 : rkendall I would like this too ------------------------------------------------------------------------ October 14, 2004 - 23:46 : drumm Can the name be changed to 'view user profiles'? ------------------------------------------------------------------------ October 18, 2004 - 09:19 : Bèr Kessels It can, but I used "access" for consistancy. we have "access newsfeeds", "access comments", "access etc". This patch is critical for corporate sites btw. A corporate site that has its customers information lying on the streets (so to say) is not-done. Ber ------------------------------------------------------------------------ November 27, 2004 - 13:49 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/user-access.patch (5.96 KB) Updated for CVS. I assumed that "admin users" implies "access users" in user_admin. ------------------------------------------------------------------------ March 1, 2005 - 17:30 : killes(a)www.drop.org Does not apply anymore, Ber can you have a look at it? ------------------------------------------------------------------------ March 7, 2005 - 09:19 : Bèr Kessels Attachment: http://drupal.org/files/issues/user_access_0.patch (9.74 KB) New patch. Should apply to HEAD.

1 0