- Development - lists.drupal.org

[drupal-devel] [feature] Custom registration fields should appear on admin/user/create
by chx 18 Jul '05

18 Jul '05

Issue status update for http://drupal.org/node/23536 Post a follow up: http://drupal.org/project/comments/add/23536 Project: Drupal Version: cvs Component: user.module Category: feature requests Priority: normal Assigned to: chx Reported by: moshe weitzman Updated by: chx Status: patch Attachment: http://drupal.org/files/issues/user_reg_1.patch (8 KB) after discussions with Dries and Moshe I put the requirement uncheck and removed my description trickery. chx Previous comments: ------------------------------------------------------------------------ Tue, 24 May 2005 19:02:40 +0000 : moshe weitzman When creating a new user as an admin, it is useful and even expected to be able to complete all the profile fields which are available on the usual registration form ... the approach might be to consolidate registration so that both users and admins use a single form. ------------------------------------------------------------------------ Sat, 25 Jun 2005 22:27:41 +0000 : chx Attachment: http://drupal.org/files/issues/user_reg.patch (8.69 KB) At first I thought it'd be better if I'd keep the separate form, but this version results in shorter code and it's not so ugly. However, if you do not like it, I have the version which only adds the $extra to user_admin_create. ------------------------------------------------------------------------ Sun, 26 Jun 2005 18:08:48 +0000 : killes(a)www.drop.org I like this patch. ------------------------------------------------------------------------ Tue, 28 Jun 2005 01:53:01 +0000 : moshe weitzman to me, this version is great as it unifies the registration code. i did a code review and all looks good to me. i applied the patch and noticed that - i added a required checkbox field via profile.module. the check appeared on the reg form without the 'required' marker and the registration was accepted without checking the box. then i tried this for a textfield and it properly showed the 'required' marker but it didn't enforce the 'required' bit either. so then i tried to edit the user and even then we seem not to be enforcing the 'required' bit. this looks like a profile.module bug. if you are up for it, you might want to investigate the above. but truly, enforcing the required bit is not related to this patch. so +1 from me. ------------------------------------------------------------------------ Fri, 01 Jul 2005 06:00:21 +0000 : chx Attachment: http://drupal.org/files/issues/user_reg_0.patch (9.01 KB) It was intentional that the check for required fields are skipped for admins. I deleted that check. ------------------------------------------------------------------------ Wed, 06 Jul 2005 06:28:35 +0000 : Torenware Attachment: http://drupal.org/files/issues/user_reg_4.6.2.patch (8.33 KB) This patch is massively useful (at least for me...) and was exactly what I was looking for. Since I can't use the CVS version, I back-ported it to 4.6.2. It's syntactically valid, and it seems to work, although I have not tested it thoroughly. I'm uploading it in case anyone else wants to try it out, or is willing to test it. I'll be using it in any case. YMMV, of course :-) Rob Thorne Torenware Networks

1 0

[drupal-devel] [feature] add inline functionaliy to uploads
by Bèr Kessels 18 Jul '05

18 Jul '05

Issue status update for http://drupal.org/node/26288 Post a follow up: http://drupal.org/project/comments/add/26288 Project: Drupal Version: cvs Component: upload.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Bèr Kessels Updated by: Bèr Kessels Status: patch Kobus, And all the others looking fofr advanced inline systems: please do not -1 this. It will hep inline module a lot too. allthough not yet in this patch, but can you imagine a perission system for inline module, that comes for free? Or a core system, that makes inline module ten times smaller? it is this path! so, please, if it is not /exactly/ what you are looking for, at least look at the advantages for Joe Average, and even for the possibilties for your favorite inline-module. even imag_assist will gain an anomous usability impcact when usiong this module, for it can then finally use the upload module in full scale. Ber Bèr Kessels Previous comments: ------------------------------------------------------------------------ Sun, 03 Jul 2005 18:03:35 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/upload_inline.patch (19.05 KB) One of the most often asked features is proper inlnie handling of files. Look at the amount of solutions, the popularity of image_assist, and the amount of peolpe dowloading image.module! That alone should be enough proof that Drupal lacks proper inline image support. This patch adds that to core. In fact, it does little more then appending a link of img tag to the body or the teaser. Off course that is configurable per file. Next to the [] list checkbox, this patch adds an [] inline checkbox. Simplicity is the foundation of this patch. I want no stles for inline editing, no fancy html wrappers, no tokens, just $node->body or teaser appended with a small html string. Another small themable funtion is introduced, (hey, you cannot expect me to develop something without adding more power for themers, now, can you? ;) ), that allows people to theme the string that is appended to the body or the teaser. Oh, and also note hat the biggest part of this patch is some cleaning I had to do in order to be able to develop properly. I dont like Ifs inside cases in foreaches inside swiches. in other words: nodeapi now calls functions instead of executing code directly. ------------------------------------------------------------------------ Sun, 03 Jul 2005 18:19:25 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/inline.patch.screenshot.png (26.68 KB) here is how the form now looks ------------------------------------------------------------------------ Sun, 03 Jul 2005 18:19:58 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/inline.patch.screenshot3.png (30.53 KB) and this is an example of inlined images and a .doc file. ------------------------------------------------------------------------ Sun, 03 Jul 2005 20:44:00 +0000 : sepeck changing to patch per request from berkes ------------------------------------------------------------------------ Tue, 05 Jul 2005 07:46:13 +0000 : Kobus This gets a +1 from me in principle, however, the [inline:xx] tag with inline.module gives you greater freedom as to where the inline image must be displayed. If you can add this functionality (I haven't checked the code, I don't know if it is in there) it would be a great addition for Core. This same strategy can be used for inline blocks, I am sure. Regards, Kobus ------------------------------------------------------------------------ Tue, 05 Jul 2005 08:57:50 +0000 : Bèr Kessels there are a couple of reasons why i did not include the [inline] tags. * I aimed for extreme simplicity: a checkbox shows an image inline: its up to the theme where it appears (if one does not like it before/above the body and teaser.). Simplicity was the main goal. * We don't have any tokens in core. And we should not have them. * Tokens are a very bad substitute for a good interface. They give less power then plain HTLM. Are much worst documented then HTML, but in the mean time, they are still as hard to learn as HTML. (Yes, I know people _think_ they are easier, but there _is_ not difference between [ ] and , only that its a different ascii char. So, no. I don't allow any placement of the image. I leave that that for dedicated modules, or the themer to decide. ------------------------------------------------------------------------ Tue, 05 Jul 2005 09:34:06 +0000 : Kobus So you will provide an API to do this? For example, with perhaps minor modifications, the inline.module will be able to display these files? In that case I am happy. If not, then I can't give my support to this patch (as if that matters...). A themer can't do this task as inline images (and blocks for that matter) is too dynamic for theming; it can be placed anywhere in a node where the user pleases. This means for me that there should be a module for this, such as inline module that allows you to define [inline:xx] tags. If your module emits an array of uploaded files (such as upload.module), inline.module can be, with minor changes, adapted to show these files inline. To show you what I mean with the content is too dynamic for a themer to perform this task, look at this screenshot related to inline blocks (inline images can follow the same pattern): http://drupal.org/files/issues/regions---possibility-3.png ------------------------------------------------------------------------ Tue, 05 Jul 2005 11:26:15 +0000 : Bèr Kessels Kobus, We are dealing with different issues here: You want a method to place images, files or so anywhere in the post. That is fine, but certainly NOT addressed in the patch! I made patch that *only* adds marked files to the body. its really nothing more then <?php $node->body = $filestring . $node->body ?> No APIS, no, dynamic tokens, no filters, nothing. However, what I meant with themers, is that there now is a theme_upload_inline available, so you can theme the abovementioned $filestring. On top of that $node->files[FILEID]->inline is TRUE if a file is flagged for inline. So in node.tpl.php, or wherever you want to theme a node, you can print nice images inline, when that flag is set. And about the comment that a themer cant do this: Simply not true. On most sites images are always placed in the same places. REally, even the sites see which use img_assist or inline, use them to place the images on the exact same places in every node. People /think/ they want the power to place images anywhere, but they hardly ever use that power. Just look at all the big news/publishing sites out there (BBC, CNN, BoigBoing, r even freshmeat) images are all placed acc. to the theme. They are not placed in random places by authors. So if you are one of the few that still want that power, there aer mots of power tools like inline module or img_assist. We should offer a good default, one that is simple. ------------------------------------------------------------------------ Tue, 05 Jul 2005 11:41:34 +0000 : Gerhard Killesreiter I fully agree that tags are evil. Kobus: You can always look for tags in $node->body in your theme's node function. ------------------------------------------------------------------------ Tue, 05 Jul 2005 11:50:52 +0000 : stefan nagtegaal Ber, the theme-function in your code looks like: <?php +/** + * Theme function for rendering of inline images + * @param $file a file object. + * @param $image a Boolean, indicating whether an img tag (TRUE) or an anchor tag (FALSE) should be used. + * @ingroup themable + */ +function theme_upload_inline($file, $image) { + if ($image) { + return '<img src="'. check_url(($file->fid ? file_create_url($file->filepath) : url(file_create_filename($file->filename, file_create_path())))) .'" alt="'. check_plain($file->filename) .'" class="upload inline">'; + } + else { + return ''. check_plain($file->filename) .' [1]'; + } + +} ?> After looking at your code it's not clear to me when $image is TRUE or FALSE, can you elaborate on me please? [1] http://drupal.org/'. check_url(($file->fid ? file_create_url($file->filepath) : url(file_create_filename($file->filename, file_create_path())))) .'\" class=\"upload inline ------------------------------------------------------------------------ Tue, 05 Jul 2005 12:06:39 +0000 : Bèr Kessels The function calling the theme function should decide whether its an image. IMO that is far too hardcore code for a themer ;) <?php $image = ereg('^(image/)', $file->filemime); ?> inside _upload_inline() does the trick. I did find one issue, though, with svgs, which are image/svg so maybe we should limit this to really only inline jpg, png, and gif, by extension? But I am no fan of determining files by extension, and IMO getimgsize is too heavy; ------------------------------------------------------------------------ Tue, 05 Jul 2005 12:13:52 +0000 : stefan nagtegaal Can't you make use of PHP's <?php image_type_to_mime_type(); ?> or <?php image_type_to_extension(); ?> ------------------------------------------------------------------------ Tue, 05 Jul 2005 12:45:43 +0000 : Kobus Well, if not in the patch, I need inline functionality one way or another. inline.module works perfectly with the current upload.module to fulfill my needs, and if there is a way where someone can extend your proposed upload.module, that would get my +1, otherwise I will just remain neutral about this issue. inline.module makes use of $node->files and displays that image. If your patch still uses $node->files, then this is a non-issue. In other words, if I can, with inline.module, or with minor modifications to inline.module still show files inline, I am +1 for this. As for the themability question... I still disagree. You say "Simply not true. On most sites images are always placed in the same places." That is ONLY true because they have NO alternatives. Means the content is in the same places, because they have no other places to put them. I have made tens of static sites where the content does not resemble a fixed pattern or structure. For me, free-flow layout is my expression of my creativity. This is why I still even BOTHER with static sites; when Drupal don't do what I want it to do. If Drupal could do inline display of content properly, I'd never even build another static site. It is a great mistake people make (including myself), and that is they design the site before ANY content is available, and this happens a lot in static sites. But in dynamic sites, you have far less control over this, unless you have a VERY clean structure with limited information that can be added, and only a few people posting content. If you can have your content before you start the design, you will have a better fit. I can't see how you can anticipate every possible posting posted on your site if you have a diversity of users. Especially not if you're using a site such as an designer's showcase site where your creativity is shown by your web sites. Possible, but not easy. If I claim that I have "unique, fresh designs" I can certainly NOT give them a "box-like" site with "left and right side bars only". That's why I need inline content, this includes images AND boxes. Gerhard: Your concern about tags is answered as well above, if I am not mistaken. The patch need not provide the tags, but should provide for someone to develop a module that provide the filters or tags. To summarize: I don't need your patch to do the inline images. I just need your patch to be able to allow someone else to develop a module that can display inline files. Kobus ------------------------------------------------------------------------ Mon, 18 Jul 2005 09:56:38 +0000 : Bèr Kessels okay, so for all clarity, let me sumarise: * this patch introduces a chackbox "inline". If checked, the file will show up inline. IT will be appended to the teaser and the body. * this patch does *not* allow one to place images of files in a userdefined place in the body. * this patch does *not* do any resizing nor any thumbnailing. * This patch is meant to be simple, clear and transparant. No tokens, no javascript, no nothing. ------------------------------------------------------------------------ Mon, 18 Jul 2005 11:21:54 +0000 : Kobus Then I can't see how this patch could replace the existing upload.module, which allows you to use inline.module to place images inline. I therefore withdraw my +1 and go -1 on this (not that it matters, I believe). I think you didn't properly read my previous message. I said I don't need your patch to do all this, but I can't live without the functionality currently provided by the upload.module and inline.module combination. I agree that your patch don't need to have that functionality, but if your patch takes away this functionality, in other words, I can't (by hook or by crook) manage what I need to do, my vote is -1. Regards, Kobus

1 0

[drupal-devel] [bug] Logo uploads are broken
by drumm 18 Jul '05

18 Jul '05

Issue status update for http://drupal.org/node/26822 Post a follow up: http://drupal.org/project/comments/add/26822 Project: Drupal Version: cvs Component: theme system Category: bug reports Priority: normal Assigned to: drumm Reported by: drumm Updated by: drumm Status: patch Attachment: http://drupal.org/files/issues/system.module_4.diff (1.95 KB) Custom logo uploading broke. System_settings_save() was doing a drupal_goto() before the code to save the logo got executed. drumm

2 4

[drupal-devel] [bug] Commit #17448 by Dries
by drumm 18 Jul '05

18 Jul '05

Issue status update for http://drupal.org/node/26917 Post a follow up: http://drupal.org/project/comments/add/26917 Project: Drupal Version: cvs Component: blogapi.module Category: bug reports Priority: critical Assigned to: Anonymous Reported by: brdwor Updated by: drumm -Status: active +Status: patch Attachment: http://drupal.org/files/issues/blogapi.module.diff (807 bytes) Here is a fix for what seems to be the last two. drumm Previous comments: ------------------------------------------------------------------------ Sun, 17 Jul 2005 22:12:06 +0000 : brdwor Commit #17448 by Dries Caused: Parse error: parse error, unexpected T_DOUBLE_ARROW in /home/testsite/public_html/modules/blogapi.module on line 236 In page: http://example.com/?q=admin/modules ------------------------------------------------------------------------ Sun, 17 Jul 2005 23:44:55 +0000 : Steven Fixed. Thanks. ------------------------------------------------------------------------ Mon, 18 Jul 2005 16:23:17 +0000 : brdwor Parse error: parse error, unexpected T_DOUBLE_ARROW in /home/stiction/public_html/modules/blogapi.module on line 333 Also, it occurs in other places in this file.

1 0

[drupal-devel] Styling Width of form_textarea and form_textfield
by Jeff Robbins 18 Jul '05

18 Jul '05

We've propably all seen fixed width themes that get "blown out" on the right side by textfields and textareas that have their $size value set rather large. The form elements overlap any right side borders or background elements and it doesn't look very professional. (See attached jpg) One solution is to make a CSS rule that looks something like this: .textarea, .form-text { width: 95%; } But this quickly hits a major usability problem when a user encounters a textfield for, say, a numeric input requiring a value less than 100: form_textfield($title = t('Number Less Than 100'), $name = 'example', $value = '0', $size = 2, $maxlength = 2); Usability-wise, this ought to be a narrow textfield to imply a small entry value. (See 'Number of places after decimal separator" in the attached jpg.) But the CSS rule would make this item 95% of the width of it's parent. So before I post an issue asking for themeable form_textfield and form_textarea. I thought I'd open it up to discussion as to whether there might be a better solution. I see a drupal setting... or better yet a theme setting that would set the maximum textfield/textarea $size value, before it gets a style="width:95%" added to its attributes. Then form_textfield would look something like this: function form_textfield($title, $name, $value, $size, $maxlength, $description = NULL, $attributes = array(), $required = FALSE) { $size = $size ? ' size="'. $size .'"' : ''; // this is the new stuff ****************************************************** if ($size > theme_get_maxfieldsize() && !strstr("width", $attributes['style'])) { $attributes['style'] = "width:" . theme_get_overmaxval(); // <-- percent, ems, pixels or any css value } // also note that the function's $attributes argument // has been set to default to array() rather than NULL // end new stuff ************************************************************** return theme('form_element', $title, '<input type="text" maxlength="'. $maxlength .'" class="'. _form_get_class('form-text', $required, _form_get_error($name)) .'" name="edit['. $name .']" id="edit-'. form_clean_id($name) .'"'. $size .' value="'. check_plain($value) .'"'. drupal_attributes($attributes) .' />', $description, 'edit-'. $name, $required, _form_get_error($name)); } Think I'm headed in the right direction with this? I'd like to hear some other opinions. -Jeff Robbins _ _ ________ (_) (_)__ / __/ __/ _________ ____ ___ robbins(a)jjeff.com / / / / _ \/ /_/ /_ / ___/ __ \/ __ `__ \ www.jjeff.com / / / / __/ __/ __/_/ /__/ /_/ / / / / / / aim: jefforbit __/ /_/ /\___/_/ /_/ (_)___/\____/_/ /_/ /_/ /___/___/

3 2

[drupal-devel] [bug] node created timestamp changes on node edit
by adrinux 18 Jul '05

18 Jul '05

Issue status update for http://drupal.org/node/24002 Post a follow up: http://drupal.org/project/comments/add/24002 Project: Drupal Version: 4.6.0 Component: node.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: adrinux Updated by: adrinux Status: patch I made a version of this patch for CVS HEAD: http://drupal.org/node/26960 adrinux Previous comments: ------------------------------------------------------------------------ 1117558642 : adrinux When an image node is edited it changes position in the gallery, and in image taxonomy listings. This is not the usual 'most recently edited' item floating to the top. The edited image simply shifts to a different place in the gallery with no apparent logic. As far as I can tell this happens because image module sorts the images in a gallery by the node creation timestamp, and for some reason the creation timestamp is being incremented a little on editing the node. (Of course the changed timestamp also changes as expected.) Here's and example. Lets take this gallery http://sphop.perlucida.com/image/tid/62 And change the title from *sphp_2002_061_henk.jpg* to *Seagulls* on this image: http://sphop.perlucida.com/node/322 Prior to the change we have the following (info extracted from the db): nid: 322 title: sphp_2002_061_henk.jpg created: 1117550744 changed: 1117550744 And the image is listed between *sphp_2002_062_henk.jpg* and *sphp_2002_060_henk.jpg* as you'd expect. We change the title and image moves to appear between *sphp_2002_067_henk.jpg* and *sphp_2002_066_henk.jpg* as you can see: http://sphop.perlucida.com/image/tid/62?from=12 The db now gives: nid: 322 title: Seagulls created: 1117550756 changed: 1117558316 So, why does the *created* timestamp change at all, and can I stop that happening? I should say that the images in the gallery were initially imported using import_image.module - but I don't see what this could have to do with that. ------------------------------------------------------------------------ 1120093148 : dtan Attachment: http://drupal.org/files/issues/node.module.created.patch (591 bytes) You'll notice that there is an authored on text box. . .it doesn't provide seconds, so when the timestamp is created, it picks up the current minutes seconds. Thus if you edit a node (any type) and view its created field in the db, and continuously repeat over 60 seconds, you will see the created loop back down. Here is the patch. . .which is actually applied to the *node.module*. ------------------------------------------------------------------------ 1120095771 : clydefrog dtan, your patch contains html. ------------------------------------------------------------------------ 1120102803 : dtan Attachment: http://drupal.org/files/issues/node_module_created.patch (591 bytes) another one :) ------------------------------------------------------------------------ 1120144437 : Jose A Reyero Hey dtan, I'd say very good catch :-) , tested the patch and seems to be ok. Anyway, I think this bugfix needs to be posted to Drupal core. ------------------------------------------------------------------------ 1120159369 : mfb +1 ------------------------------------------------------------------------ 1120203070 : adrinux No time to test this until next week myself, but It's already got two +'s so I'm moving it to core and re-titleing. Thanks to dtan for hunting this one down :) ------------------------------------------------------------------------ 1121698888 : adrinux Had time to test dtan's patch properly and can now say definitively that it does fix this problem. That is, without this patch the node created timestamp changes on a node edit. With this patch applied only the node changed timestamp changes, as you'd expect. So +1 on this getting applied ASAP.

1 0

[drupal-devel] [bug] Node created timestamp changes on node edit
by adrinux 18 Jul '05

18 Jul '05

Issue status update for http://drupal.org/node/26960 Post a follow up: http://drupal.org/project/comments/add/26960 Project: Drupal Version: cvs Component: node system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: adrinux Updated by: adrinux Status: patch Attachment: http://drupal.org/files/issues/node_module_created_0.patch (580 bytes) This is a version of the patch dtan made for Drupal-4.6 see: http://drupal.org/node/24002 where a full description of the problem can be found. In short, when a node is edited the *node created timestamp* is /changed/, clearly only the *node changed timestamp* should change on a node edit. This small patch corrects this behaviour so that a node edit results in only the node changed timestamp changing, and /not/ the node created timestamp (which is kept as the original time of creation). adrinux

1 0

[drupal-devel] [bug] node created timestamp changes on node edit
by adrinux 18 Jul '05

18 Jul '05

Issue status update for http://drupal.org/node/24002 Post a follow up: http://drupal.org/project/comments/add/24002 Project: Drupal Version: 4.6.0 Component: node.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: adrinux Updated by: adrinux Status: patch Had time to test dtan's patch properly and can now say definitively that it does fix this problem. That is, without this patch the node created timestamp changes on a node edit. With this patch applied only the node changed timestamp changes, as you'd expect. So +1 on this getting applied ASAP. adrinux Previous comments: ------------------------------------------------------------------------ 1117558642 : adrinux When an image node is edited it changes position in the gallery, and in image taxonomy listings. This is not the usual 'most recently edited' item floating to the top. The edited image simply shifts to a different place in the gallery with no apparent logic. As far as I can tell this happens because image module sorts the images in a gallery by the node creation timestamp, and for some reason the creation timestamp is being incremented a little on editing the node. (Of course the changed timestamp also changes as expected.) Here's and example. Lets take this gallery http://sphop.perlucida.com/image/tid/62 And change the title from *sphp_2002_061_henk.jpg* to *Seagulls* on this image: http://sphop.perlucida.com/node/322 Prior to the change we have the following (info extracted from the db): nid: 322 title: sphp_2002_061_henk.jpg created: 1117550744 changed: 1117550744 And the image is listed between *sphp_2002_062_henk.jpg* and *sphp_2002_060_henk.jpg* as you'd expect. We change the title and image moves to appear between *sphp_2002_067_henk.jpg* and *sphp_2002_066_henk.jpg* as you can see: http://sphop.perlucida.com/image/tid/62?from=12 The db now gives: nid: 322 title: Seagulls created: 1117550756 changed: 1117558316 So, why does the *created* timestamp change at all, and can I stop that happening? I should say that the images in the gallery were initially imported using import_image.module - but I don't see what this could have to do with that. ------------------------------------------------------------------------ 1120093148 : dtan Attachment: http://drupal.org/files/issues/node.module.created.patch (591 bytes) You'll notice that there is an authored on text box. . .it doesn't provide seconds, so when the timestamp is created, it picks up the current minutes seconds. Thus if you edit a node (any type) and view its created field in the db, and continuously repeat over 60 seconds, you will see the created loop back down. Here is the patch. . .which is actually applied to the *node.module*. ------------------------------------------------------------------------ 1120095771 : clydefrog dtan, your patch contains html. ------------------------------------------------------------------------ 1120102803 : dtan Attachment: http://drupal.org/files/issues/node_module_created.patch (591 bytes) another one :) ------------------------------------------------------------------------ 1120144437 : Jose A Reyero Hey dtan, I'd say very good catch :-) , tested the patch and seems to be ok. Anyway, I think this bugfix needs to be posted to Drupal core. ------------------------------------------------------------------------ 1120159369 : mfb +1 ------------------------------------------------------------------------ 1120203070 : adrinux No time to test this until next week myself, but It's already got two +'s so I'm moving it to core and re-titleing. Thanks to dtan for hunting this one down :)

1 0

[drupal-devel] [bug] Handle full URLs in url() and l()
by adrian 18 Jul '05

18 Jul '05

Issue status update for http://drupal.org/node/10888 Post a follow up: http://drupal.org/project/comments/add/10888 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: Bèr Kessels Reported by: jhriggs Updated by: adrian Status: patch spoke to dries about this patch, and apart from the incomplete patch I uploaded, there are about a dozen instances where in-line html is used were l() would suffice. I will be cleaning them up and submitting a new patch soon. adrian Previous comments: ------------------------------------------------------------------------ 1095346884 : jhriggs Attachment: http://drupal.org/files/issues/full_url.patch (1.97 KB) This little patch allows full URLs to be used for the url() and l() functions, giving modules a single interface for creating links. Currently, modules must use l() for drupal links and raw HTML for external links. This patch changes url() to handle -- basically pass through -- full URLs while still doing the proper handling of internal paths and works with clean URLs enabled or disabled. It also shortens (and hopefully simplifies) the url() code a bit. Some examples of calls that now work: <?php l('a link', 'some/path'); // same as before l('an external link', 'http://drupal.org/'); l('full with query', 'http://google.com/search?q=define:foo'); l('full with separate query', 'http://google.com/search', array(), 'q=define:foo'); // same link as above l('full with fragment', 'http://drupal.org/node/5942#comment-12374'); l('full with separate fragment', 'http://drupal.org/node/5942', array(), NULL, 'comment-12374'); // same link as above ?> ------------------------------------------------------------------------ 1096542570 : moshe weitzman +1. less HTML in code is a good thing for readability, if nothing else. ------------------------------------------------------------------------ 1106597186 : mathias Attachment: http://drupal.org/files/issues/external_urls.patch (838 bytes) Revisiting this issue one year later shows we're almost there. The only thing that's left is the ability to handle external urls when clean_urls is disabled. Once implemented, menu.module can happily accept external urls and not just Drupal paths, making the menu system much more attractive to end users. I'll update the menu.module docs if this patch (or an alternative solution) is accepted. ------------------------------------------------------------------------ 1110753394 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/external_urls_0.patch (909 bytes) Updated from Drupal root directory. ------------------------------------------------------------------------ 1110758717 : gordon +1 This is a good thing for people who can't using clean urls. ------------------------------------------------------------------------ 1112422990 : TDobes This patch seems like a good idea, but does not apply anymore. Also, shouldn't the comments for l() and url() be updated to indicate that the functions will work with both internal and external URL's? ------------------------------------------------------------------------ 1112426713 : asimmonds Attachment: http://drupal.org/files/issues/external_urls_1.patch (897 bytes) The &'s had been changed to & amp; , here's a valid patch ------------------------------------------------------------------------ 1115909827 : adrian This is a new patch against cvs that allows url() to create external links, with the side-effect that menu can now be used to make external links. Also closes http://drupal.org/node/10177 This will be even more important with the primary links menu integration. (This patch already cleans up a special case in phptemplate for that). Killes benchmarked this, and it turns out the difference is negligible. Requests per second: 1.33 [#/sec] (mean) = with patch Requests per second: 1.31 [#/sec] (mean) = without patch. ------------------------------------------------------------------------ 1115909997 : killes(a)www.drop.org I had benchmarked /node as anon user without cache. ------------------------------------------------------------------------ 1116996608 : Steven +1 on the idea of this patch. It allows people to use l() for external links. However, I don't like the implementation. Running that complicated regexp for every url() call is simply wasteful. 95% or more of url() calls have a fixed string as parameter and point to Drupal's own paths. I suggest we create an url_external() wrapper around url() which allows external URLs. Any path which we want to allow external URLs in can use url_external() instead. The places where we use it will not be many anyway. ------------------------------------------------------------------------ 1116997555 : gordon splitting into url() url_external is not a good idea. The main reason for this patch that I see is for putting external urls into the navigation menu using the menu.module, and if all goes to plan, the primary and secondary menus. ------------------------------------------------------------------------ 1117000801 : Steven gordon: I still think this is a bit excessive. Perhaps instead of valid_url() we could use a simpler regexp !^[a-z]://!i or even strpos('://'). ------------------------------------------------------------------------ 1117001736 : gordon I am not says that it is or is not excessive. I was just saying that this is where it is going to be used, so creating url() and url_external() is not really an option ------------------------------------------------------------------------ 1117004273 : Bèr Kessels we /do/ need an external_url() thing. The links bundle (handling weblinks and the likes) willprovide this /and/ need this. People will get all sorts of tools to do /stuff/ with external links, like add permissions, track clicks etc. depending on the modules they have and the settings. All outgoing weblinks, should somehow respect those. Patches for core are coming, though. On top of that, a external_l() finction is simple. And if people want them in primary links they can do the regexping /before/ the function, not /in/ the function. The calling code can decide whether to call l() or external_l(), instead of putting logic in l() that is unneded 95% of the times. But i hereby promise to introduce such a function tbefore the end of this week :) ------------------------------------------------------------------------ 1117005467 : gordon The only thing I do not see in this plan is how with this work with the menu module and the navigation menu. ------------------------------------------------------------------------ 1117015452 : adrian Attachment: http://drupal.org/files/issues/url_external_links.patch (1.75 KB) What happened to the patch i uploaded ? It doesn't use a complex regexp, but uses strpos($url, '://') < 5. ------------------------------------------------------------------------ 1117088372 : Bèr Kessels Allthough this works, is clean AND does what it should do, I still am in favour of a better nitegrated solution. So please do not yet commit this, untill I upload my patch. We can then discuss what solution to take. It will not differ a big lot though. ------------------------------------------------------------------------ 1117096772 : adrian is this the patch where you want to introduce an el() to allow for counting of external links ? That's a different patch altogether. This is primarily about stopping url() from not handling external links when there is no good reason for it to do so. Your el() has a very specific use in the weblinks api, and should probably be included with it. ------------------------------------------------------------------------ 1117124311 : Bèr Kessels Yes, that el() But let me explain why i am anxious for my solution: el(), by default will not do much, in fact it will just be an URL()-clone but one that allows outgoing links. But it has a hook-caller. Again: by default it does nothing much, for there will not be any hooks around in core. It will allow, for example, weblinks, to track clicks, or to look up a permission and allow or disallow users to follow a link. Now, the whole issue, IMO is, that we should *not* provide two ways for handling external URLS, but rather a single one, that is weblink-safe. If we would introduce URL() with outgoing links-capabilities, we can no longer track any outgoing URLs trough them. We will then have two ways for handling outgoing URLs, resulting in inconsistencies, and confused users. (hey, my anonymous users can follow link foo, while i have "follow outgig links" permission disabled for them). (BTW weblink will soon be renamed into links, just for reference) ------------------------------------------------------------------------ 1120129571 : adrian Attachment: http://drupal.org/files/issues/url_external_links_0.patch (824 bytes) I've updated the patch.

1 0

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

18 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: Dries Status: patch Not going to commit this yet. 1. Let's wait for Mathias' feedback on Steven's comment. 2. I suggest using query or query_string, not querystring. 3. It is not clear why this can't be part of drupal_attributes($array)? If there is an important difference, it would be nice to make that clear in the PHPdoc comments. Dries Previous comments: ------------------------------------------------------------------------ 1074874057 : 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. ------------------------------------------------------------------------ 1075546820 : 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. ------------------------------------------------------------------------ 1075555476 : 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 ------------------------------------------------------------------------ 1075568516 : 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 ?> ------------------------------------------------------------------------ 1075569177 : 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). ------------------------------------------------------------------------ 1075647745 : 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. ------------------------------------------------------------------------ 1075988536 : moshe weitzman After feedback from Matias and Kjartan, I now consider this patch to be desireable ------------------------------------------------------------------------ 1092323430 : killes(a)www.drop.org Patch doesn't apply anymore. ------------------------------------------------------------------------ 1097208870 : 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. ------------------------------------------------------------------------ 1097210052 : 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. ------------------------------------------------------------------------ 1097848902 : 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. ------------------------------------------------------------------------ 1103647413 : moshe weitzman this is a nice code consolidation IMO ------------------------------------------------------------------------ 1103712633 : 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? ------------------------------------------------------------------------ 1110745506 : killes(a)www.drop.org Doesn't apply anymore. ------------------------------------------------------------------------ 1121208547 : mathias 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. ------------------------------------------------------------------------ 1121444746 : Steven If we're going to have an array2uri() function, we might as well add urlencode() calls in there... this would centralize a lot of existing urlencode() calls, I think.

1 0