- Development - lists.drupal.org

Re: [drupal-devel] [contributions(DRUPAL-4-6):pablobm] contributions/modules/ldap_integration
by Stefan Nagtegaal 21 May '05

21 May '05

Why do I get this message 15 times??? Op 21-mei-2005, om 16:57 heeft drupal-cvs(a)drupal.org het volgende geschreven: > User: pablobm Branch: DRUPAL-4-6 Date: Sat, 21 May 2005 > 14:57:47 +0000 > > Log message: > > - Added DRUPAL-4-6. > > -- > [ Drupal cvs list | http://list.drupal.org/ ]

1 0

[drupal-devel] New CVS accounts
by Dries Buytaert 21 May '05

21 May '05

Hello world, I approved a bunch of new CVS accounts. This brings the grand total of CVS accounts to 294. There are a fair number of inactive accounts which I'll disable shortly. Please welcome our new contributors, and assist them as necessary. -- Dries Buytaert :: http://www.buytaert.net/

1 0

[drupal-devel] Translation coordinator
by Dries Buytaert 21 May '05

21 May '05

I'd like to propose having a "Drupal translation coordinator". I have two candidates in mind: Gerhard (killes) and Gabor (goba). Both Gerhard and Gabor have a track record guiding new translators, and Gabor is mostly responsible for the current locale module. I think both have what it takes. -- Dries Buytaert :: http://www.buytaert.net/

3 2

[drupal-devel] [bug] theme_image doesn't accept html attributes
by Dries 21 May '05

21 May '05

Issue status update for http://drupal.org/node/21397 Project: Drupal Version: cvs Component: theme system Category: bug reports Priority: critical Assigned to: Anonymous Reported by: jjeff Updated by: Dries Status: patch Do you still get that error? If it is specific to the image.module, we might have to move this bug report. Dries Previous comments: ------------------------------------------------------------------------ April 27, 2005 - 04:45 : jjeff Here's the theme_image function from theme.inc <?php function theme_image($path, $alt = '', $title = '', $attr = '', $getsize = true) { if (!$getsize || (file_exists($path) && (list($width, $height, $type, $attr) = @getimagesize($path)))) { return "<img src=\"$path\" $attr alt=\"$alt\" title=\"$title\" />"; } } ?> Any arguments sent to the function for $attr get clobbered by the getimagesize() call. And $getsize defaults to true, so in a call to: <?php theme_image('files/images/foo', 'alt_text', 'title_text', 'align="left"') ?> the 'align="left"' never makes it to the page. The two attribute values really should be able to coexist, allowing for both getsize attributes and additional 'argumented' attributes as well. I recommend changing the $attr in the second line to $imgattr, then adding $imgattr to the tag returned in the third. -Jeff ------------------------------------------------------------------------ May 2, 2005 - 17:44 : jjeff Attachment: http://drupal.org/files/issues/theme_image-attr_fix.patch (1.51 KB) Okay, here's a patch to fix the theme_image attribute problem. I've also added a handler so that attributes can either be a string (as they were in the past - although it wasn't working) or an associative array. I've marked this issue as critical because the current version of theme_image() does not accept attributes at all. -Jeff ------------------------------------------------------------------------ May 2, 2005 - 17:47 : jjeff Attachment: http://drupal.org/files/issues/theme_image-attr_fix_0.patch (1.51 KB) Whoops... Found a mistake in my code... Here's the correction. -Jeff ------------------------------------------------------------------------ May 2, 2005 - 18:04 : jjeff Attachment: http://drupal.org/files/issues/theme_image-attr_fix_1.patch (1.51 KB) It's amazing how many mistakes one person can make in two lines of code. New patch... this one works! -jeff ------------------------------------------------------------------------ May 2, 2005 - 18:16 : Steven Attributes should be consistently passed as an array, and rendered with drupal_attributes(). This is to ensure data is escaped correctly. ------------------------------------------------------------------------ May 5, 2005 - 17:09 : jjeff Attachment: http://drupal.org/files/issues/theme_image-attr_fix_2.patch (1.34 KB) Now the $attr argument requires an array. And the $attr argument gets sent through drupal_attributes(). Simple and easy, really. -Jeff ------------------------------------------------------------------------ May 6, 2005 - 11:02 : Dries Tidied up the code a little, and committed it to HEAD and DRUPAL-4-6. Thanks. ------------------------------------------------------------------------ May 8, 2005 - 18:26 : jjeff Attachment: http://drupal.org/files/issues/theme-img_attr_fix.patch (1 KB) Oops... the new fix sets the default value for $attributes to NULL. It should at least be array(), now that $attributes is an array. This patch fixes the default value and adds some other error checking that should help this error that people may be seeing when they load a page with images: Invalid argument supplied for foreach() in /Users/jeff/Sites/drupal/includes/common.inc on line 1536 -Jeff ------------------------------------------------------------------------ May 8, 2005 - 23:10 : Dries AFAIK, we always use $attributes = NULL without special error-checking (see form_ functions in common.inc, for example). Does this fix a bug? If so, how can we reproduce it? I'd love to test it. ------------------------------------------------------------------------ May 13, 2005 - 14:47 : hatseflats I also get this error: Invalid argument supplied for foreach() in /includes/common.inc on line 1536 When using image.module CVS and drupal CVS. When viewing an image no tag is outputted.

1 0

[drupal-devel] [bug] file_check_location is not working on Windows 2000
by Dries 21 May '05

21 May '05

Issue status update for http://drupal.org/node/10885 Project: Drupal Version: cvs Component: file system Category: bug reports Priority: critical Assigned to: Anonymous Reported by: ccourtne Updated by: Dries Status: patch This patch no longer applies against HEAD or DRUPAL-4-6. Could someone try reproducing this problemwith the latest version in either branch, and provide an updated patch. (I think the problem still needs fixing but I'm not sure and can't reproduce the problem.) Dries Previous comments: ------------------------------------------------------------------------ September 16, 2004 - 15:46 : ccourtne Currently file_check_location is always returning false when passed a file as the $source path. If a directory is passed in $soruce file_check_location works. I've tracked this down to realpath returning an empty string when passed a relative path which points to a file. This probably goes unnoticed if you are using the file.api's to construct relative paths to the druapl file directory since check_location failing just causes the durpal file directory to get added which is what you wanted in the first place. Replacing this line $source = realpath(dirname($source)); with this $source = realpath(dirname($source)); fixes it on my windows box using PHP 4.3.8. I don't have things set up to do patches on my windows boxes here at work yet. I'll submit a formal patch tonight. ------------------------------------------------------------------------ September 16, 2004 - 15:47 : ccourtne Dag nabit. Replace $source = realpath($source); with $source = realpath(dirname($source)); Craig ------------------------------------------------------------------------ September 16, 2004 - 15:56 : Anonymous Attachment: http://drupal.org/files/issues/file-inc-file_check_location.patch (639 bytes) The sooner there are patches, the better it is... I tested this approach on my server and it works. Steef ------------------------------------------------------------------------ September 17, 2004 - 03:34 : ccourtne Attachment: http://drupal.org/files/issues/checklocation.patch (666 bytes) Here is the patch. ------------------------------------------------------------------------ February 23, 2005 - 02:30 : dan90(a)drupal.org This also fixed my file upload problems with some nonstandard paths under Linux/apache, php 4.3.4 drupal 4.5.2. maybe we should remove mention of windows 2000? ------------------------------------------------------------------------ March 1, 2005 - 19:32 : killes(a)www.drop.org Still applies. ------------------------------------------------------------------------ April 18, 2005 - 13:10 : ec Is this patch still to be use with actual Drupal 4.6.0 ? Thanks. eric ------------------------------------------------------------------------ May 7, 2005 - 12:35 : Wes Cowley I hand applied the patch to my Linux based installation and it solved the problem I was having with filemanager/attachment. I assume it would fix the same problem I had with upload.module since the symptoms were identical. ------------------------------------------------------------------------ May 7, 2005 - 12:36 : Wes Cowley Meant to add, that was a 4.6.0 Linux installaion that this patch cleared up. ------------------------------------------------------------------------ May 14, 2005 - 09:59 : larryjhs Thanks, still, I'm a bit of a php newbie -- where do I put the patch -- into which bit of script? If it's not too obvious, tell me and I won't try! But if it's obvious, please give me the location L ------------------------------------------------------------------------ May 14, 2005 - 10:19 : ec This patch seem still to apply to 4.6 (I'm using it on my linux box too and it solve my problem with upload.module) it apply on "file.inc" that you will find in includes directory on top of your drupal root. Put the patch in the same directory as file.inc go in this directory too and apply the patch like this "patch -p0 < the_patch_to_apply" where patch is the command on *nix box. If you're not confortable you can either edit the file.inc by hand and make the change yourself, in the patch file, line beginning with "-" is the one to remove, line beginning with "+" is the one to add, other lines are the context so you're sure to find the right line. Hope this help. Regards. ------------------------------------------------------------------------ May 14, 2005 - 10:23 : ec BTW, IMHO this patch should be committed ASAP as it's solve the problem with upload.module that can't handle private directory outside drupal root. Tested on my sites ans work (for now ;-) like a charm. Regards. ------------------------------------------------------------------------ May 15, 2005 - 13:51 : Dries Don't we use file_create_path for that (it appends the 'files'-bit)? ------------------------------------------------------------------------ May 15, 2005 - 22:19 : ec On my linux box, I make an other test with the latest stock release of file.inc. I setup files directectory, with "private" check, outside drupal root and drupal complains The directory does not exist (I know this directory exists and is working because I'm using it !). It only works with the patch below. Sorry, I'm not confortable enought to answer your question Dries, but sure this patch is the only I found to have a real private directory working. Regards, eric. PS : I don't why but got an error each time I want to upload a file here ??? so here is the text against the latest release of file.inc i.e 1.39.2.2 --- ./file.inc 2005-05-15 21:52:40.758531811 +0200 +++ ./file_mod_ec.inc 2005-05-15 22:03:41.869608738 +0200 @@ -169,7 +169,7 @@ * @return 0 for invalid path or the real path of the source. */ function file_check_location($source, $directory = 0) { - $source = realpath($source); + $source = realpath(dirname($source)); $directory = realpath($directory); if ($directory && strpos($source, $directory) !== 0) { return 0; >/code> ------------------------------------------------------------------------ May 21, 2005 - 07:00 : Rick Cogley The patch fixed uploads for me as well on 4.6.0.

1 0

[drupal-devel] Admin access to user tabs
by Dan Robinson 21 May '05

21 May '05

Hey, I've got the following code in my module - if ($may_cache) { $access_user = user_access('edit own forum mail settings'); $items[] = array('path' => "user/$user->uid/forummail", 'title' => t("my forum mail settings"),'callback' => forummail_page, 'callback arguments' => $user->uid,'access' => $access_user, 'type' => MENU_LOCAL_TASK); } When I got to user/<number> when I'm logged in (as whomever) I see the tab "my forum mail settings" - everything works fine. However I want to have "admin" users be able to edit the "my forum mail settings" of other users. So when logged in as admin then I want t see this tab for "dan" - currently it won't show up. As always - help/hints appreciated. Dan

1 0

[drupal-devel] [feature] List of bloggers
by Andrzej7 21 May '05

21 May '05

Issue status update for http://drupal.org/node/17030 Project: Drupal Version: cvs Component: blog.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Bèr Kessels Updated by: Andrzej7 Status: patch I was a little afraid (poor PHP) to install the patch (March...), but I have made a block. And it's very nice. One question only. All the bloggers are shown, but the Admin (user No 1) is on the list and he has no blogs. What's that? Andrzej7 Previous comments: ------------------------------------------------------------------------ February 8, 2005 - 23:27 : Bèr Kessels Attachment: http://drupal.org/files/issues/blog_bloggers_list.patch (1.66 KB) Small patch to show a list of bloggers. We all should know that blog.module is not meant for personal blogging, but that set aside, we do not have a way to show all bloggers, on a site as a list. This patch ads a few lines that will allow you to show that overview of blogging users. It ads a menu item, disabled by default that shows such a list. ------------------------------------------------------------------------ February 8, 2005 - 23:31 : Bèr Kessels Attachment: http://drupal.org/files/issues/blog_bloggers_list.png (4.02 KB) Here is a small screeny that shows what this is about. ------------------------------------------------------------------------ February 8, 2005 - 23:34 : Bèr Kessels Attachment: http://drupal.org/files/issues/list_bloggers_2.png (2.25 KB) hmm. error in my png file. Here is a correct one. ------------------------------------------------------------------------ February 19, 2005 - 20:13 : Emiliano Hi Bèr Kessels! Thanks for the patch! It's really useful! :-) I just noticed what I think is a little mistake in this line: $items[] = l($row->name, 'blog/'.$row->uid)." ".theme('xml_icon', url('blog/'.$row->uid.'/feed'), TRUE); Which I believe should end like: $items[] = l($row->name, 'blog/'.$row->uid)." ".theme('xml_icon', url*('blog/feed/'.$row->uid)*, TRUE); Ah, and BTW, "db_rewrite_sql" didn't work for me... I just cut it off... ;-) Cheers, Emiliano. ------------------------------------------------------------------------ March 17, 2005 - 22:17 : Bèr Kessels Attachment: http://drupal.org/files/issues/blog_bloggers_list_2.patch (1.81 KB) and here is the actual patch. (i think i really need some script that tells me i did not attach a patch ;) ) ------------------------------------------------------------------------ March 17, 2005 - 22:19 : Bèr Kessels Attachment: http://drupal.org/files/issues/blog_bloggers_list_2_0.patch (1.71 KB) sigh. something tells me i should stop working.... a silly "F" sneaked into the previous patch. ------------------------------------------------------------------------ March 24, 2005 - 20:25 : Anonymous I applied the patch, reuploaded the blog.module and then deactivated and reactivated it. I cannot see a difference. How do I access the blog users page? Drupal 4.6rc thanks for the help. ------------------------------------------------------------------------ March 24, 2005 - 20:53 : Bèr Kessels look in the menu admin. ------------------------------------------------------------------------ May 18, 2005 - 13:38 : Bèr Kessels Nearly two months since the patch. If there is no need for this I will mark it won't fix. ------------------------------------------------------------------------ May 18, 2005 - 13:52 : tostinni I made a custom block for this, but it still need a little improvment (add "read more" for example). So I don't know if it's usefull but if anyone care : <?php $result = db_query("SELECT u.uid, u.name, COUNT(0) AS num FROM {node} n LEFT JOIN {users} u ON u.uid = n.uid WHERE n.type = 'blog' GROUP BY u.uid, u.name ORDER BY u.name ASC"); while ($blog = db_fetch_object($result)) { $output .= '<li />'.l($blog->name. ' ('.$blog->num.')', 'blog/'.$blog->uid); } return '<ul>'.$output.'</ul>'; ?> ------------------------------------------------------------------------ May 18, 2005 - 16:06 : Chris Johnson I think this is a useful feature. I've coded custom blocks in the past to provide it on my sites.

1 0

[drupal-devel] [bug] file_check_location is not working on Windows 2000
by Rick Cogley 21 May '05

21 May '05

Issue status update for http://drupal.org/node/10885 Project: Drupal Version: cvs Component: file system Category: bug reports Priority: critical Assigned to: Anonymous Reported by: ccourtne Updated by: Rick Cogley Status: patch The patch fixed uploads for me as well on 4.6.0. Rick Cogley Previous comments: ------------------------------------------------------------------------ September 16, 2004 - 22:46 : ccourtne Currently file_check_location is always returning false when passed a file as the $source path. If a directory is passed in $soruce file_check_location works. I've tracked this down to realpath returning an empty string when passed a relative path which points to a file. This probably goes unnoticed if you are using the file.api's to construct relative paths to the druapl file directory since check_location failing just causes the durpal file directory to get added which is what you wanted in the first place. Replacing this line $source = realpath(dirname($source)); with this $source = realpath(dirname($source)); fixes it on my windows box using PHP 4.3.8. I don't have things set up to do patches on my windows boxes here at work yet. I'll submit a formal patch tonight. ------------------------------------------------------------------------ September 16, 2004 - 22:47 : ccourtne Dag nabit. Replace $source = realpath($source); with $source = realpath(dirname($source)); Craig ------------------------------------------------------------------------ September 16, 2004 - 22:56 : Anonymous Attachment: http://drupal.org/files/issues/file-inc-file_check_location.patch (639 bytes) The sooner there are patches, the better it is... I tested this approach on my server and it works. Steef ------------------------------------------------------------------------ September 17, 2004 - 10:34 : ccourtne Attachment: http://drupal.org/files/issues/checklocation.patch (666 bytes) Here is the patch. ------------------------------------------------------------------------ February 23, 2005 - 09:30 : dan90(a)drupal.org This also fixed my file upload problems with some nonstandard paths under Linux/apache, php 4.3.4 drupal 4.5.2. maybe we should remove mention of windows 2000? ------------------------------------------------------------------------ March 2, 2005 - 02:32 : killes(a)www.drop.org Still applies. ------------------------------------------------------------------------ April 18, 2005 - 20:10 : ec Is this patch still to be use with actual Drupal 4.6.0 ? Thanks. eric ------------------------------------------------------------------------ May 7, 2005 - 19:35 : Wes Cowley I hand applied the patch to my Linux based installation and it solved the problem I was having with filemanager/attachment. I assume it would fix the same problem I had with upload.module since the symptoms were identical. ------------------------------------------------------------------------ May 7, 2005 - 19:36 : Wes Cowley Meant to add, that was a 4.6.0 Linux installaion that this patch cleared up. ------------------------------------------------------------------------ May 14, 2005 - 16:59 : larryjhs Thanks, still, I'm a bit of a php newbie -- where do I put the patch -- into which bit of script? If it's not too obvious, tell me and I won't try! But if it's obvious, please give me the location L ------------------------------------------------------------------------ May 14, 2005 - 17:19 : ec This patch seem still to apply to 4.6 (I'm using it on my linux box too and it solve my problem with upload.module) it apply on "file.inc" that you will find in includes directory on top of your drupal root. Put the patch in the same directory as file.inc go in this directory too and apply the patch like this "patch -p0 < the_patch_to_apply" where patch is the command on *nix box. If you're not confortable you can either edit the file.inc by hand and make the change yourself, in the patch file, line beginning with "-" is the one to remove, line beginning with "+" is the one to add, other lines are the context so you're sure to find the right line. Hope this help. Regards. ------------------------------------------------------------------------ May 14, 2005 - 17:23 : ec BTW, IMHO this patch should be committed ASAP as it's solve the problem with upload.module that can't handle private directory outside drupal root. Tested on my sites ans work (for now ;-) like a charm. Regards. ------------------------------------------------------------------------ May 15, 2005 - 20:51 : Dries Don't we use file_create_path for that (it appends the 'files'-bit)? ------------------------------------------------------------------------ May 16, 2005 - 05:19 : ec On my linux box, I make an other test with the latest stock release of file.inc. I setup files directectory, with "private" check, outside drupal root and drupal complains The directory does not exist (I know this directory exists and is working because I'm using it !). It only works with the patch below. Sorry, I'm not confortable enought to answer your question Dries, but sure this patch is the only I found to have a real private directory working. Regards, eric. PS : I don't why but got an error each time I want to upload a file here ??? so here is the text against the latest release of file.inc i.e 1.39.2.2 --- ./file.inc 2005-05-15 21:52:40.758531811 +0200 +++ ./file_mod_ec.inc 2005-05-15 22:03:41.869608738 +0200 @@ -169,7 +169,7 @@ * @return 0 for invalid path or the real path of the source. */ function file_check_location($source, $directory = 0) { - $source = realpath($source); + $source = realpath(dirname($source)); $directory = realpath($directory); if ($directory && strpos($source, $directory) !== 0) { return 0; >/code>

1 0

[drupal-devel] [bug] Comment previews need a preview class
by factoryjoe 20 May '05

20 May '05

Issue status update for http://drupal.org/node/23285 Project: Drupal Version: 4.6.0 Component: comment.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: factoryjoe Updated by: factoryjoe Status: patch Tested and works as expected. +1. Awesome! factoryjoe Previous comments: ------------------------------------------------------------------------ May 20, 2005 - 16:55 : factoryjoe References: http://drupal.org/node/18792, http://drupal.org/node/18845 In Drupal 4.6, we got node previews -- with a nice wrapping div with a preview class. Unfortunately, comments didn't get the same treatment. Therefore, we need to consider the workflow issues of previewing *anything* since it's clear that from a theming and UI perspective, a comment preview really isn't any different from a node preview, no matter what the backend architecture looks like. Sorry I don't have code for this, but I would very much appreciate a solution. ------------------------------------------------------------------------ May 20, 2005 - 17:01 : Steven Attachment: http://drupal.org/files/issues/comment.preview.patch (1.5 KB) Untested patch.

1 0

[drupal-devel] [bug] Comment previews need a preview class
by Steven 20 May '05

20 May '05

Issue status update for http://drupal.org/node/23285 Project: Drupal Version: 4.6.0 Component: comment.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: factoryjoe Updated by: Steven -Status: active +Status: patch Attachment: http://drupal.org/files/issues/comment.preview.patch (1.5 KB) Untested patch. Steven Previous comments: ------------------------------------------------------------------------ May 20, 2005 - 18:55 : factoryjoe References: http://drupal.org/node/18792, http://drupal.org/node/18845 In Drupal 4.6, we got node previews -- with a nice wrapping div with a preview class. Unfortunately, comments didn't get the same treatment. Therefore, we need to consider the workflow issues of previewing *anything* since it's clear that from a theming and UI perspective, a comment preview really isn't any different from a node preview, no matter what the backend architecture looks like. Sorry I don't have code for this, but I would very much appreciate a solution.

1 0