July 2005 - Development - lists.drupal.org

[drupal-devel] [feature] Send copy of Contact submission to sender's email
by Robin Monks 13 Jul '05

13 Jul '05

Issue status update for http://drupal.org/node/26236 Post a follow up: http://drupal.org/project/comments/add/26236 Project: Drupal Version: cvs Component: contact.module Category: feature requests Priority: normal Assigned to: Robin Monks Reported by: mjohnson16 Updated by: Robin Monks Status: patch Attachment: http://drupal.org/files/issues/contact..copy.module.patch (2.65 KB) Here is a second patch, which also provides a copy checkbox in user contact forms. Robin Robin Monks Previous comments: ------------------------------------------------------------------------ July 2, 2005 - 13:53 : mjohnson16 When using the contact form to send a message to another user, it would be nice if a copy of the sent message was sent to the sender's email address. This would allow for an easy way to archive those messages for reference. ------------------------------------------------------------------------ July 3, 2005 - 00:53 : Robin Monks I'll take this one. Robin ------------------------------------------------------------------------ July 5, 2005 - 22:45 : Robin Monks Attachment: http://drupal.org/files/issues/contact.module.patch (1.56 KB) Here is my best shot. This allows users to have a copy of their message sent to themselves. Useful for those who like to keep records of emails. Robin ------------------------------------------------------------------------ July 6, 2005 - 03:53 : Nathan_ +1 for this patch. I tested it against HEAD, and it works perfectly. One thing I would suggest is that the option also apply to the person contact forms as well. I am not sure if this was in the original request, but I think, especially on community sites, users might like to a have a reccord of peer to peer correspondance. Just my 2cents. ------------------------------------------------------------------------ July 6, 2005 - 11:52 : kbahey I did not test the patch, but I support the functionality. +1 for me.

1 0

[drupal-devel] aggregator
by Karoly Negyesi 13 Jul '05

13 Jul '05

Hi! What's the reason aggregator is using a lot of WHERE iid = $iid OR ... instead of WHERE iid IN($iid, ...) ?? Regards NK

3 2

[drupal-devel] Users confused by blogs
by Steve Dondley 13 Jul '05

13 Jul '05

This study came across my RSS feed today: http://www.catalystgroupdesign.com/cofactors/upload/Blog_usability_report.p… It's a usability report about how "mainstream" users find blogs confusing and alienating to their non-geeky senses. I wanted to throw this out to the blog module developers out there. Maybe Drupal can break the mold and make their blogs a little more user friendly.

3 2

[drupal-devel] [bug] Tablesort and $_REQUEST array handling
by mathias 13 Jul '05

13 Jul '05

Issue status update for http://drupal.org/node/5371 Post a follow up: http://drupal.org/project/comments/add/5371 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: mathias Reported by: mathias Updated by: mathias -Status: active +Status: patch Attachment: http://drupal.org/files/issues/tablesort_and_REQUEST_arrays_2.patch (3.19 KB) Updating this patch since I've been bitten by this issue again. The new array2uri() function really shines for tablesorting and/or paging search results after a $_POST request. The only coding change involved for developers is to use $_REQUEST['edit'] and $_REQUEST['op'] instead of $_POST['edit'] and $_POST['op'] within their function callback where this functionality is desired. As an added benefit these pages could also be bookmarked. Dries, I've updated the documentation to hopefully makes things a little easier to understand. I don't think renaming the $array variable to $attributes or calling the function attributes2uri instead of array2uri would make the function and its purpose more transparent. It's not used for HTML attributes like the drupal_attributes function, but rather for form submitted data (e.g., the $edit array) that needs to be tablesorted/paged. Project module and the ecommerce package still currently hack the $_POST vars to circumvent this problem. Not sure if other modules are also doing this. mathias Previous comments: ------------------------------------------------------------------------ January 23, 2004 - 10:07 : mathias Attachment: http://drupal.org/files/issues/tablesort_and_REQUEST_arrays.patch (652 bytes) Tablesort tries its best to rebuild the URI from which it was called. The problem is when $_REQUEST holds arrays such as $edit. Tablesort will process this as: example.com?edit=Array This can be problematic since many module conditions rely on whether or not the $edit array is set. My patch disallows tablesort to append "array $_REQUEST variables" to it's new query string, since it serves no purpose. ------------------------------------------------------------------------ January 31, 2004 - 05:00 : Dries I'd like to hear Moshe's take on this as I'm not sure this is the proper fix. I'd think that the tablesort code knows exactly what fields it should add to the URL. ------------------------------------------------------------------------ January 31, 2004 - 07:24 : moshe weitzman I don't think this is the proper fix either. For example, - browse to the Drupal.org issue search page [1]. - press Search button - On the results page, look at the links in the table header and the pager. The query state gets passed along by tablesort. This patch would break this behavior. Changing Status to 'Active', since this patch shouldn't be applied without modification. [1] http://drupal.org/project/drupal/issues/search ------------------------------------------------------------------------ January 31, 2004 - 11:01 : mathias I'm pretty sure the project system is hacking the request object just like I am before sending it to tablesort: <?php if ($_SERVER['REQUEST_METHOD'] == 'POST' && is_array($_POST['edit'])) { foreach ($_POST['edit'] as $key => $value) { if (!empty($value) && in_array($key, $fields)) { $query->$key = $value; $_POST[$key] = is_array($value) ? implode(',', $value) : $value; } } unset($_POST['edit'], $_POST['op']); } ?> Basically, we're both moving the edit array into separate name / value pairs and then destroying it before handing it off to tablesort. I don't understand what the benefit is of passing an array into a GET query string since the key/value pairs aren't retained. We could set an option in tablesort to ask it to decompose the array into it's key/value pairs for us and pass them back in the query string. For example an edit array such as: <?php $edit['a'] => 1 $edit['b'] => 2 would have a query string of: &edit_a=1&edit_b=2 instead of the currently meaningless: &edit=Array ?> ------------------------------------------------------------------------ January 31, 2004 - 11:12 : Goba You mean: <?php $edit['a'] => 1 $edit['b'] => 2 would have a query string of: &edit[a]=1&edit[b]=2 instead of the currently meaningless: &edit=Array ?> This reuses the wonderful array handling provided by PHP (as long as nested arrays are handled properly). ------------------------------------------------------------------------ February 1, 2004 - 09:02 : Kjartan Indeed project module hacks the request data. I don't really like this as a general fix as it is a hack, but for now it is the best way. I dont think the original patch will break this as it just ignors arrays(). Project module loops through the array and converts them to normal array string elements; $_POST['edit']['status'] = value becomes $_POST['status'] = value, then I think I unset the edit array to clean up the urls. ------------------------------------------------------------------------ February 5, 2004 - 07:42 : moshe weitzman After feedback from Matias and Kjartan, I now consider this patch to be desireable ------------------------------------------------------------------------ August 12, 2004 - 09:10 : killes(a)www.drop.org Patch doesn't apply anymore. ------------------------------------------------------------------------ October 7, 2004 - 22:14 : mathias Attachment: http://drupal.org/files/issues/tablesort_and_REQUEST_arrays_0.patch (2.55 KB) This patch resolves the hacks project module and the ecommerce package use to rebuild the $_REQUEST arrays when implementing paged resultsets and/or tablesorting. I know some other developers have ran into this bug as well usually after form submissions. Tablesort will now fully handle multi-dimensional $_REQUEST arrays and convert them to a valid querystring and preserve user-submitted data. ------------------------------------------------------------------------ October 7, 2004 - 22:34 : moshe weitzman very nicely done ... bonus points for converting pager to use the new array2uri() function ... tablesort's poor handling of arrays frustrated me in a recent client project. this will simplify almost all cases where a form post leads to a sortable "results" table, such as in project.module. ------------------------------------------------------------------------ October 15, 2004 - 08:01 : mathias Attachment: http://drupal.org/files/issues/tablesort_and_REQUEST_arrays_1.patch (2.99 KB) Moved the new array2uri function to live with its array2* counterparts in common.inc and cleaned up the function documentation a wee bit. ------------------------------------------------------------------------ December 21, 2004 - 10:43 : moshe weitzman this is a nice code consolidation IMO ------------------------------------------------------------------------ December 22, 2004 - 04:50 : Dries This patch adds more code than it removes. That aside, it would be nice if the function's PHPdoc comments were extended. Looking at the patch, it is easy to see how/when this function is being used, but reading the PHPdoc comments it is not. I'd add a simple example and some context information. Also, it is unclear what $current_key is used for without inspecting the function's code. For readability, maybe rename $array to $attributes? If that makes sense, maybe rename 'array2uri' to 'attributes2uri'? Which makes me wonder: how does this stack with the existing drupal_attributes() function? Do we really need the recursive array handling? ------------------------------------------------------------------------ March 13, 2005 - 14:25 : killes(a)www.drop.org Doesn't apply anymore.

1 0

[drupal-devel] [task] New XML-RPC library
by chx 12 Jul '05

12 Jul '05

Issue status update for http://drupal.org/node/26391 Post a follow up: http://drupal.org/project/comments/add/26391 Project: Drupal Version: cvs Component: base system Category: tasks Priority: critical Assigned to: chx Reported by: chx Updated by: chx Status: patch Attachment: http://drupal.org/files/issues/xmlrpc_4.patch (89.47 KB) Bootstrap broke xmlrpc hopeless. And that library was a pain to work with. This one, though is much more transparent. Only date and base64 objects require special handling, everything else is totally transparent. I put a module in my sandbox which makes Drupal validate against validate.xmlrpc.com and is a nice example on how to use the new library. chx

1 3

[drupal-devel] Describing the WebDAV module
by Fabiano Sant'Ana 12 Jul '05

12 Jul '05

What is my Idea? We will have a global array ($_webdav) created by webdav hook_menu, each dav module(for example, DAV_upload.module) will create a item in $_webdav['hooks'] with informations about how to call the hook, what is the base collection name, etc. In hook_menu webdav.module will parse the User Request and put it on $_webdav, then it will call the hook_dav function to handle the response. Here an example... In webdav.module... function webdav_menu($may_cache) { global $_webdav; if(!isset($_webdav)) $_webdav = array(); $items = array(); $items[] = array('path' => 'webdav', 'title' => t('WebDAV Interface'), 'callback' => 'webdav_interface', 'access' => user_access('access nodes')); //administer nodes return $items; } In webdav.upload.module (I think that I need a better name)... ;) function dav_upload_menu($may_cache) { global $_webdav; $_webdav['hooks'][] = array('collection' => 'upload', 'handler' => 'dav_upload_handler'); } Sorry if have any error in code I write just to elucidate, and sorry for not reply the other e-mails, but I'm not at home. cheers, Fabiano Sant'Ana

2 1

[drupal-devel] May I help with the server problems?
by NSK 11 Jul '05

11 Jul '05

Hey I know you have some servers problems. I currently cannot assist with money but I would like to know whether I can help by donating some of my webspace to you. I maintain wikinerds.org on a VPS with 6GB of HD space and about 80GB of maximum monthly traffic. I currently only use about 600-800MB of HD space and 1-10GB of bandwidth per month, so I think I can allow the Drupal community to host something on my VPS, since I don't really use all the resources I have rented. It can be on a temporary basis, until you can get a dedicated server, or permanent depending on how much diskspace/bandwidth you need. If I can assist, email me at nsk(a)wikinerds.org See also http://portal.wikinerds.org/freehosting -- NSK http://portal.wikinerds.org

1 0

[drupal-devel] Out of Office AutoReply: [bug] apache and drupal both compressing pages
by Boerland Bert 07 Jul '05

07 Jul '05

dank voor je mail, vanwege familie omstandigheden ben ik niet in de gelegenheid om je mail te lezen en te verwerken. vanaf volgende week zl ik weer contact met je op kunnen nemen -- groets, bert boerland

1 0

Re: [drupal-devel] New themeable function for buttons?
by Kobus Myburgh 07 Jul '05

07 Jul '05

> I don't have any experience browsing web sites as if I were visually > impaired; how do people use buttons in those cases? Surely a normal HTML > button can't be a useability obstacle for that user group? Well, a whole website is an obstacle for a blind person who can't use a mouse to click here or there. Hotkeys or tab order is the only way I can see around this issue, but this is off-topic, so won't discuss it here. > In the end, it is the consistency that is the most important to me. Amen to that. Also the fact that the cancel doesn't stand out much compared to the Delete and users can then accidentally delete content they don't want to delete. I agree, it's unlikely and you could feel "if you're that daft, you have no reason to use this site" but fact remains that a user-centered person won't say something like that (at least not openly... ;)) Kobus

1 0

Re: [drupal-devel] New themeable function for buttons?
by Kobus Myburgh 07 Jul '05

07 Jul '05

> I think the confirm link next to the button is ugly too and I think > making the delete button a link would be a big step backwards in user > friendliness. I agree with this, even though I can't find any "proof" that the link method is wrong. I personally like the button approach better too... Regards, Kobus

6 8