- Development - lists.drupal.org

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

14 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: ec Status: patch 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. ec Previous comments: ------------------------------------------------------------------------ September 16, 2004 - 14: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 - 14:47 : ccourtne Dag nabit. Replace $source = realpath($source); with $source = realpath(dirname($source)); Craig ------------------------------------------------------------------------ September 16, 2004 - 14: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 - 02:34 : ccourtne Attachment: http://drupal.org/files/issues/checklocation.patch (666 bytes) Here is the patch. ------------------------------------------------------------------------ February 23, 2005 - 01: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 - 18:32 : killes(a)www.drop.org Still applies. ------------------------------------------------------------------------ April 18, 2005 - 12:10 : ec Is this patch still to be use with actual Drupal 4.6.0 ? Thanks. eric ------------------------------------------------------------------------ May 7, 2005 - 11: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 - 11:36 : Wes Cowley Meant to add, that was a 4.6.0 Linux installaion that this patch cleared up. ------------------------------------------------------------------------ May 14, 2005 - 08: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

1 0

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

14 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: larryjhs Status: patch 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 larryjhs Previous comments: ------------------------------------------------------------------------ September 16, 2004 - 13: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 - 13:47 : ccourtne Dag nabit. Replace $source = realpath($source); with $source = realpath(dirname($source)); Craig ------------------------------------------------------------------------ September 16, 2004 - 13: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 - 01:34 : ccourtne Attachment: http://drupal.org/files/issues/checklocation.patch (666 bytes) Here is the patch. ------------------------------------------------------------------------ February 23, 2005 - 00: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 - 17:32 : killes(a)www.drop.org Still applies. ------------------------------------------------------------------------ April 18, 2005 - 11:10 : ec Is this patch still to be use with actual Drupal 4.6.0 ? Thanks. eric ------------------------------------------------------------------------ May 7, 2005 - 10: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 - 10:36 : Wes Cowley Meant to add, that was a 4.6.0 Linux installaion that this patch cleared up.

1 0

[drupal-devel] install system phase 3: wizard api
by Adrian Rossouw 14 May '05

14 May '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey guys. I just had a thought regarding phase 3 of the install system (if you don't know what I am talking about, you should probably read this: http://drupal.org/node/22472) A wizard, as I have created it .. is essentially a very simple workflow tool. We want to integrate a workflow engine of some sort into Drupal for 4.7 do we not anyway? Perhaps it would be more constructive for us to focus our energies on that, and let the install wizard be driven by a Drupal wide workflow engine? - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCgWTLgegMqdGlkasRAktoAKC75UDcuOJJ14n9aZd9+6ziPdEg5wCglWXd ESsREO0pECSnxZ9mdTVjIvg= =Kdvk -----END PGP SIGNATURE-----

4 3

[drupal-devel] [bug] Grammar correction
by Cvbge 14 May '05

14 May '05

Issue status update for http://drupal.org/node/22804 Project: Drupal Version: 4.6.0 Component: comment.module Category: bug reports Priority: minor Assigned to: Anonymous Reported by: Cvbge Updated by: Cvbge Status: patch Attachment: http://drupal.org/files/issues/comment_module-grammar_fix.diff (2.19 KB) Below is a list of the latest comments posted your site. "posted /to/ your" is missing. Cvbge

2 4

Re: [drupal-devel] CiviCRM, Civicgroups, OG, Profile- Playing together
by David Geilhufe 13 May '05

13 May '05

>From our perspective (David, Lobo and Dave-CiviCRM team), and of CivicSpace, we would like to see as deep and wide integration of CiviCRM into CivicSpace/Drupal as possible. For those that are unfamiliar with CiviCRM, it provides a CRM repository tailored to the needs of non-profits, but relevant to other applications as well. It stores contacts, relationships, groups, and actions. It's API could be used to store CRM data for a volunteer management module, for example, or data on attendees for an events module. In our discussions with CivicSpace, the intention is that CiviCRM will become part of the CivicSpace release in 0.8.2. I'll let the CivicSpace guys define exactly what this means in roadmap terms. This suggests some immediate priorities: (1) Developers/people need to work with CiviCRM code and sandbox. (2) We need further discussion and ideally some consensus regarding interfaces and division of functionality between CiviCRM and the Drupal core modules which currently handle info about people. (3) Module developers should begin the porting/integration process. ************************************ CiviCRM Code and Repository http://sandbox.openngo.org/crm/ ************************************ Please visit the sandbox. Right now, you can download the code and get it fired up locally per the installation instructions (link at the sandbox site). Today, feel free to contribute workflow suggestions or other high level anlysis. Latter this week, we will be accepting bug reports on the 0.1 release. Our development team is still in the end stages of a feature freeze, so we are actively testing and fixing, but your contributions are INVALUABLE! ************************************ Drupal Core ************************************ Folks out in Drupal land- CiviCRM isn't just useful for CivicSpace applications. You might want to look at it to store sophistocated CRM data. But as Jason has said, there needs to be more discussion on how CiviCRM will interface with Drupal core modules like User and Profile. Our current plan is to implement user hooks which will keep CiviCRM contact data synchronized with Drupal 'users'. However, the best approach(es) for playing with Profile are less obvious. Do we duplicate and/or sync Profile data? This implies a tool for mapping Profile to CiviCRM fields since Profile doesn't have a 'known' data model. Or does it make sense for CiviCRM to "take over" the Profile functionality if it's installed? (We tend toword the latter approach to keep the model cleaner and provide the opportunity for deeper integration to a shared data model). We would love to get this discussion and decisions going anywhere it might be appropriate (drupal-dev, cs-dev, crm-dev). ************************************ Module Developers & Porting ************************************ The 0.1 API and feature set is fairly stable and it is a great time for module developers to start figuring out how to port their modules to using CiviCRM. It is critical to us to support module developers in the porting process. People should feel free to ask for API support on the CiviCRM development email list http://lists.objectledge.net/mailman/listinfo/crm-dev Module developers should also feel free to ask for (and contribute) API and data model changes. One of the big goals for CiviCRM is to help you build better, more powerful applications. The more people that begin the process now, the sooner CiviCRM can be deeply and widely integrated with CivicSpace/ Drupal. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ David Geilhufe CEO Social Source Foundation david -AT- socialsourcefoundation -DOT- org http://www.socialsourcefoundation.org/ Add me to your address book... <https://www.plaxo.com/add_me?u=34359748358&v0=19951&k0=-658465201> Connect with me on Linkedin... <http://www.linkedin.com/> >On 5/8/05, jasonwhat <jasonwhat(a)gmail.com> wrote: > >http://drupal.org/node/21940#comment-38421 In this >post I talk about some of the various modules out >there that let users create data about themselves, >data on other users, and relationships. What seems >clear to me is there is development going on in CS and >Drupal and Civicgroups of several similar user >managemnt and organanization tools. > >I brought this issue up here >http://civicspacelabs.org/home/node/12285 and realize >that maybe the CivicCRM is the to omnipotent api that >will unify all several modules. If I'm correct, the >CivicCRM won't just have it's own data fields, like >the current contact module in CS, but will share with >modules like profile once they are updated to work >with it. > >If CivicCRM seems like the place to unify all this >then I think there needs to be a more visible way to >get these module maintainers and developers involved >now. I do believe there is a mailing list for this, >but I mean a more visible acceptance from developers >that the CivicCRM is what they should be looking >towards, and coding towards as much as that is >possible. > >I might be stating the obvious here, but my fear is >that modules like "contact directory" >http://drupal.org/node/15863 will continue to be >developed duplicating the fothcoming CivicCRM. Or >maybe the module is great and will ultimately be an >important aspect of the CRM, but if so it would nice >to have that conversation started now, rather than >later. With all the posts about extending profile, or >searching profiles, referrals and invites, and organic >grouping, it would be nice for these developers to >join in the CivicCRM discussion and development, >rather than starting their own. > >I see that CivicCRM was discussed at FOSDEM, but I >don't know if a more general "user management" >discussion has taken place or not. I'm not sure if it >needs to, but just throwing these thoughts out to the >wolves.

5 5

[drupal-devel] [bug] Missing placeholder
by drumm 13 May '05

13 May '05

Issue status update for http://drupal.org/node/22806 Project: Drupal Version: 4.6.0 Component: upload.module Category: bug reports Priority: normal Assigned to: drumm Reported by: drumm Updated by: drumm Status: patch Attachment: http://drupal.org/files/issues/upload.module_2.diff (1.31 KB) Just a simple em -> placeholder fix. drumm

1 0

[drupal-devel] [task] db_affected_rows code cleanup
by mathias 13 May '05

13 May '05

Issue status update for http://drupal.org/node/22786 Project: Drupal Version: cvs Component: search.module Category: tasks Priority: normal Assigned to: Anonymous Reported by: mathias Updated by: mathias Status: patch Attachment: http://drupal.org/files/issues/db_affected_rows.patch (1.04 KB) Now that db_affected_rows() returns the number of rows matched instead of only changed [1] we can get rid of the hacks that worked around this. It looks like search module and locale.inc are the only places that need cleaning. Here's the patch for search module. [1] http://cvs.drupal.org/viewcvs/drupal/drupal/includes/database.mysql.inc?r1=… mathias

1 0

Re: [drupal-devel] CiviCRM, Civicgroups, OG, Profile- Playing together
by David Geilhufe 13 May '05

13 May '05

All- We're new into the community, so we'd like some advice on how to participate most effectively. So feel free to hollar if there is a better way to engage you all. We have some real, working code in the sandbox (http://sandbox.openngo.com/crm/) so I think we've at least hit the gold-standard ;) One way that we can proceed is to continue down the path with Neil and the CS guys and put together a specific proposal for how CiviCRM will interact with drupal (patching porofile, etc.) and get comments on that specific proposal. At the same time, folks using drupal for virtually any use where keeping track of the relationships between users is important will likely want to look at our stuff and use it in ways we have yet to imagine. Looking forward to continuing the conversation, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ David Geilhufe CEO Social Source Foundation david -AT- socialsourcefoundation -DOT- org http://www.socialsourcefoundation.org/ Add me to your address book... <https://www.plaxo.com/add_me?u=34359748358&v0=19951&k0=-658465201> Connect with me on Linkedin... <http://www.linkedin.com/> Message: 7 Date: Fri, 13 May 2005 09:11:27 +0200 From: Dries Buytaert <dries(a)buytaert.net> Subject: Re: [drupal-devel] CiviCRM, Civicgroups, OG, Profile- Playing together To: drupal-devel(a)drupal.org Message-ID: <be561445dcc574f8ad8d022e7a3c47ad(a)buytaert.net> Content-Type: text/plain; charset=US-ASCII; format=flowed On 12 May 2005, at 16:43, David Geilhufe wrote: > Or does it make sense for CiviCRM to "take over" > the Profile functionality if it's installed? (We > tend toword the latter approach to keep the model > cleaner and provide the opportunity for deeper > integration to a shared data model). > > We would love to get this discussion and decisions > going anywhere it might be appropriate (drupal-dev, > cs-dev, crm-dev). I'm afraid none of us Drupal developers are familiar with CiviCRM. It is hard to make recommendations without having looked at CiviCRM ... The fact that user profiles don't have a "data model" is an interesting point. How did the FOAF module solve this? I'd think a data model is required to syndicate information between sites. Either way, we're not opposed to patches that make the profile module more extensible/powerful. -- Dries Buytaert :: http://www.buytaert.net/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ David Geilhufe CEO Social Source Foundation david -AT- socialsourcefoundation -DOT- org http://www.socialsourcefoundation.org/ Add me to your address book... <https://www.plaxo.com/add_me?u=34359748358&v0=19951&k0=-658465201> Connect with me on Linkedin... <http://www.linkedin.com/>

1 0

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

13 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: hatseflats Status: patch 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. hatseflats 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.

1 0

[drupal-devel] [bug] upload.module bug preventing file download
by ejort 13 May '05

13 May '05

Issue status update for http://drupal.org/node/22723 Project: Drupal Version: 4.6.0 Component: upload.module Category: bug reports Priority: critical Assigned to: Anonymous Reported by: ejort Updated by: ejort Status: patch Attachment: http://drupal.org/files/issues/upload.module.from_FROM.patch (910 bytes) Hi, I've just released a new site which has nodes only accessible by authenticated users. These nodes also have attached files via upload.module. I struck a problem where users were unable to download these files due to a bug in upload.module, instead they received 'page not found', with the following error output: "user error: Unknown table 'na' in where clause query: SELECT DISTINCT(f.nid), f.* from cms_files f WHERE (na.grant_view = 1 AND CONCAT(na.realm, na.gid) IN ('all0','term_access2','term_access6')) AND filepath = 'files/20050307_minutes.doc' in /srv/www/htdocs/docs_renegades/www/includes/database.mysql.inc on line 66. " The problem was that the node_db_rewrite_sql() WHERE statement was being inserted, but not the corresponding JOIN statement (where 'na' is declared as an alias of {node_access}). Looking through the code it seems this is because the regex in the db_rewrite_sql() function is looking for 'FROM' (all caps), whereas the upload.module query sent to db_rewrite_sql has 'from' (lower case). Changing from -> FROM fixes the problem. This patch should apply to 4.6.0 and cvs, though I didn't look to see if the cvs version of db_rewrite_sql() still looks for an uppercase FROM. Cheers, Eric ejort

2 1