- Development - lists.drupal.org

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

12 Sep '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 (code needs review) Attachment: http://drupal.org/files/issues/upload_inline_2_4.patch (14.13 KB) No, please review /this/ patch. 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 ------------------------------------------------------------------------ Mon, 18 Jul 2005 19:58:34 +0000 : Bèr Kessels 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 ------------------------------------------------------------------------ Sat, 23 Jul 2005 18:59:10 +0000 : Bèr Kessels Sohodjo jim: " I hope it matters. A big -1 on enforcing over-simplification at the expense of important and existing functionality. If automatic, uncontrollable placement of images becomes the standard, it will mean fewer not more image-rich Drupal sites as site owners/developers get complaints about "Why can't I control my images!" I _strongly_ encourage Ber to provide a "have it both ways" solution. Why not have an admin configuration setting for "allow inline tags" with default off. Change it to on and you get an additional upload checkbox for 'inline at tag' to accommodate the current functionality of the inline module while simultaneously allowing for default placement. " NOOO. people; please; look at the PATCH. Again: and hopefully last time: Simplicity. This patch does NOT replace ANYTHING inline module or img_assist wants to do. This patch hands better data to such modules. It hands a variable over to these modules, $node->file[FID]->inline, which tells these sorts of modules if people wnat that file to appear inline. AND it CAN (by default will) render a file in the most simple way inline. So really, if you want to -1 this patch, fine. But do not -1 it, because it does too little IYO. It still allows MUCH more than what you can do no, without that patch! And any solution, for core, that allows advanced handling of inline images will either require an enourmous amount of work, or it will simply no get in. So, unless you come up with a good core-worthy patch, this is still a big leap forward from what we have now. ------------------------------------------------------------------------ Sat, 23 Jul 2005 19:01:51 +0000 : Bèr Kessels :$ this is an attempt to fix the borken HML in the previous follow up. ------------------------------------------------------------------------ Sun, 24 Jul 2005 04:07:34 +0000 : TDobes Please don't combine unrelated changes together in the same patch. Moving stuff in/out of the _nodeapi hook has absolutely nothing to do with the patch and makes it much harder to read through the patch and see what it's actually doing. I'd appreciate it if you could separate the changes made here which are really relevant and move the other changes into another issue. Also: You change form_group_collapsible(t('File attachments') to form_group_collapsible(t('File Attachments'). A quick glance at some other core code seems to indicate that we've standardized on capitalizing only the first word in multi-word group titles. As for the functionality itself, I don't think this belongs in upload.module. It would be useful to have the functionality in core, but as a separate module which can be switched on and off. (upload_inline.module or something like that) If a site were set up using an inlining system from contrib and the functionality you're proposing could not be switched off, it would be extremely confusing to users that there are two different ways of inlining images. A minor comment: I'm not so sure whether the results of this patch, when inlining non-image attachments, will be the one users expect. A non-web-savvy person may expect his/her Word document (for instance) to appear inline with the node when they click "inline" -- just like their images do. I'd suggest that we limit inlining to images only. I'm not as adamant about this as the other issues, so I could be convinced otherwise if others disagree. ------------------------------------------------------------------------ Sun, 24 Jul 2005 07:58:19 +0000 : Bèr Kessels Thank you for your thoughts Tdobbes. As for the "moving things in and out of nodeapi" This was necessary, because otherwise the patch would have made the code even more unreadable. I agree with you on this point, but I simply had to clean it up a little, in order to be able to work in it. As it stands now, it is simply not possible to make this a separate module. We cannot hook into the files table. In a next stage, I might work out some hook for that table. But first things first. Can Dries or Steven please comment on his. I want to know If i should bother spending this enormous amount of time on commenting and debating this issue. If the chances are small this is accepted, Ill just drop it This ridiculous long thread reminds me again why I try to avoid making patches for core. ------------------------------------------------------------------------ Mon, 25 Jul 2005 05:49:37 +0000 : Steven Overall I like the concept, but I think it at least needs some default styling to make the image appear okay, like floating it. Right now it appears inline between whatever was there... very ugly. Sure you can say "leave it up to the themer" but if the goal is to provide a simple default, we can't expect people to dive into theming if they are going to use this feature instead of img_assist or whatever. Also, I wonder about the classes "upload" and "image". Is there a reason to use two classes? Isn't "image" a bit too generic? Oh and there is a missing XHTML / for the img tag. ------------------------------------------------------------------------ Mon, 25 Jul 2005 12:42:26 +0000 : Bèr Kessels I will fix the broken Xhttml. I chose "image" because it is exactly the same as the .image class used by image.module. But I will see to it, to add more functionality. I agree that it is not up to the themer for some good defaults, thus I will add a line of CSS to drupal.css (*shiver* ;) ) upload, IMO does not communicate well enough what the Image is doing. Not sure yet how I ill fix this, but I will see to it to come up with a better CSS/theme solution. Thanks! ------------------------------------------------------------------------ Tue, 26 Jul 2005 14:18:23 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/upload_inline_0.patch (12.24 KB) Suggestions by Steven are now included. I very simple float is added to the inline images in drupal.css. XHTML fixed. And I cleaned up some old crufty comments, as suggested by Dries. ------------------------------------------------------------------------ Tue, 26 Jul 2005 17:05:45 +0000 : fax8 What is proposed here is a good idea. But I think that this is done in not good way. I think that upload.module should be only a layer between file system and modules. So modify upload module to add a specific feature like your inline for me is not good. but I like the idea to add checkboxes for enable interaction modules between modules and upload.module. Maybe we could design an of api wich let modules tell upload.module that they can interact with it. I make an example: I'm a developer of video.module. Now to add a video file to video.module one need to put the file into drupal folders using ftp and then insert the path to the file during node creation. One of the features our users are asking a lot is the possibility to directly upload a video file to dupal. So I should write a lot of code, settings, security buggy code.. that for me isn't useful. What about if only calling an upload.module api I should enable a new checkbox on upload form called "use as video file" which let me use the file as a video file on my module??? What do you think about it???? ------------------------------------------------------------------------ Tue, 26 Jul 2005 20:00:03 +0000 : Bèr Kessels fax: upload /is/ such a layer. Just look at how image module does it. You need not write any additional 'buggy' code, you can use all teh upload functionality. The upload interface (the table and list), however, is tightly integrated, so that drupal offers an out-of-the-box file system. Nox, my patch simply adds an "out of the box" inline functionality. Small and simple. For any more advanced file features you should use or write a module that, in turn, uses the uplaod.module. ------------------------------------------------------------------------ Wed, 27 Jul 2005 11:22:40 +0000 : stefan nagtegaal After discussing with Ber, I think this patch has some great potential though the simplicity of it.. For the people who don't completely agree what this patch does: - It adds an extra checkbox for each attachment. If the 'Inline' checkbox is checked, images are displayed inline in your post and other attachments (like .pdf, .ppt, or whatever) were transformed into links. The potential of this patch is in the fact that this makes it much, much easier to have another contrib module which makes it possible to let you choose at the node submission how you would like your node to be displayed, incl. the selected inline attachments to be displayed (using _nodeapi()). So, a big +1 from me on this.. ------------------------------------------------------------------------ Wed, 27 Jul 2005 11:27:52 +0000 : Kobus > - It adds an extra checkbox for each attachment. If the 'Inline' > checkbox is checked, images are displayed inline in your post and other > attachments (like .pdf, .ppt, or whatever) were transformed into links. Does this mean it is done automatically or do I have control over this? I don't want the images to be inline if I can't control where I put it. Let me just clarify my position on this short-and-sweet-like: If it breaks the existing functionality that upload.module + inline.module provides without opening the door for a replacement, then I am -1, otherwise +1. :-) Kobus ------------------------------------------------------------------------ Wed, 27 Jul 2005 11:51:50 +0000 : Bèr Kessels Kobus: Again: it does not break anything! It opens up enormous potential for modules such as inline/module. Because inline module now has access to a variable $node->files[fid]->inline. in other words: modules such as inline.module can now find out what images a user wants to see inline! ------------------------------------------------------------------------ Wed, 27 Jul 2005 11:59:53 +0000 : Kobus Ber: Great, then I +1 it. From our previous talks about this, it seemed as if this functionality was being taken away. ------------------------------------------------------------------------ Wed, 27 Jul 2005 16:18:21 +0000 : Sohodojo Jim Agreed, +1. The most on-going and especially most recent discussion has clarified that we can have our simple cake and contrib mod cake as well. Does this mean that inline module will work as is, or will a post-patch update be required? --Sohodojo Jim-- ------------------------------------------------------------------------ Wed, 27 Jul 2005 17:33:47 +0000 : Bèr Kessels inline module will continue working. but in order for it to use this inline variable (and become even better) it needs to be patched. ------------------------------------------------------------------------ Thu, 28 Jul 2005 18:12:09 +0000 : moshe weitzman I read through the code and it looks good to me, though it is hard to know whats new given all the code thats moved around. this is definately needed functionality. If you were still up for enhancements, I'd like to see the 'inline' box get checked by default when uploading an image. when the attachment is not an image, the box should be disabled and unchecked. ------------------------------------------------------------------------ Thu, 28 Jul 2005 18:32:40 +0000 : Bèr Kessels disabling the box for non-images would break the link function (i.e add a link in the text. But, on second thought: that is fine, since it defeats the list checkbox. I will add that. As well as making it checked by default. ------------------------------------------------------------------------ Thu, 28 Jul 2005 19:54:14 +0000 : Junyor @Bèr: Why not simplify this patch to only add the hooks to a contrib module would need to add this functionality? You said that your patch would allow inline.module to work much more easily. But then there is a lot of extra stuff there that inline.module won't need. This functionality can't replace inline.module, so anything that it doesn't use just gets in the way. I'm afraid that users will think this is the best Drupal can provide without looking for a contrib module. I'd prefer we spent our time and effort adding the whole functionality of inline.module or making it easy to add and position inline content in nodes to core rather than adding some functionality to upload.module that doesn't cut it for most users. So, either strip this patch of everything but the functionality that inline.module (and similar modules) can use or allow me to position images in my text through this patch. Otherwise, -1. If this is the first step in a plan to add the functionality I want to core, I'd like to hear your full plan. ------------------------------------------------------------------------ Thu, 28 Jul 2005 21:19:37 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/upload_inline_1.patch (19.71 KB) to all: everyone has Big Plans[tm] and even worse: everyone has Bigger Plans for my patch, for inline module. Why not code it? Hooks? fine! module integration, even better. Sorry if I sound a bit grumpy here. But so far I have spent nearly three times as much hours debbating the patch, then I spent creating it. Hooks sound great. but are not the intention of this patch. I want to add a *default* way, that works. But that does not break other modules, nd in fact tries to help them. But I am not inventing some advanced image handling system here. Here is an updated patch with renewed updates.inc (got lost in the previous patch) Moshes suggestion about disabling non-images-checkboxes is also implemented. I like it a lot more now. I did not, however, implement Moshes idea about defaulting to "checked". for a few reasons: * It looks a bit silly if you have more then one image inline, And defaulting all uploads to inline will inline any uploaded image. * When uploading large images they will default to inline, thus pushing your sites layout to oblivian * None of the other options default to TRUE, so for consistancy I prefer to default it to not inline. ------------------------------------------------------------------------ Thu, 28 Jul 2005 21:24:26 +0000 : Bèr Kessels oh, bytheway: you can test adn play with this patch here: http://fixme.remixreading.org/?q=add_content note that it is a sandbox, so your account will get lost, and pages might not work :) ------------------------------------------------------------------------ Fri, 29 Jul 2005 03:47:35 +0000 : ejort +1 from me for this feature. It's frustrating that core doesn't include some basic image display functionality, and this will cover a large percentage of users needs without introducing complexity. People wanting arbitrary image placement still have inline.module etc., so it's nothing but an improvement on the current situation. ------------------------------------------------------------------------ Fri, 29 Jul 2005 06:38:46 +0000 : Steven Bèr: one thing is not clear to me... you are right that other modules can access the inline value. But upload.module will always add the image to the body. So, how can other modules use the inline checkbox/option meaningfully? ------------------------------------------------------------------------ Tue, 02 Aug 2005 18:33:30 +0000 : Bèr Kessels Steven: what I mean, is that they have access to a variable that tells them a user wants something inline. Nothing more. Its up to these modules to use that meaningfully. ------------------------------------------------------------------------ Thu, 01 Sep 2005 15:26:36 +0000 : Bèr Kessels The patch still applies. Dries, please let me know if I must bother trying to get this in before 4.7? ------------------------------------------------------------------------ Thu, 01 Sep 2005 15:30:09 +0000 : m3avrck Ber, check this latest commit: http://drupal.org/node/28483 ... I think your patch no longer applies since this JS based does do inline functionality. ------------------------------------------------------------------------ Thu, 01 Sep 2005 19:46:35 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/upload_inline_2.patch (20.02 KB) updated patch works with revisions and JS upload. ------------------------------------------------------------------------ Thu, 01 Sep 2005 20:32:11 +0000 : m3avrck got an extra 'favico' in the patch file there. ------------------------------------------------------------------------ Thu, 01 Sep 2005 22:47:24 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/upload_inline_2_0.patch (19.22 KB) favicon removed. ------------------------------------------------------------------------ Thu, 01 Sep 2005 23:06:11 +0000 : killes(a)www.drop.org I think I'd like to have this feature in core. The patch is quite big, though. ;-/ Also I noticed that the pgsql part is bogus. ------------------------------------------------------------------------ Thu, 01 Sep 2005 23:27:42 +0000 : Bèr Kessels how would the pgsql look then? I am a complete pgSQL nitwit :) ------------------------------------------------------------------------ Fri, 02 Sep 2005 15:18:47 +0000 : telex4 Just a quick +1 from a user who is hoping that this gets into core for 4.7. We're using the inline functionality on our Remix Reading test site at the moment, and it's very handy for our theme where the user uploads any number of files and may want one or two images to be previewed in the node. ------------------------------------------------------------------------ Fri, 02 Sep 2005 17:26:49 +0000 : m3avrck Patch needs to be rerolled. Latest 2_0 version does indeed fix JS-based uploads commit, however it is missing all of the database changes and updates from the last _1 patch. Also, upload_count_size() is undefined, should be using upload_space_used() [2] instead. Also, beginning of upload.module patch adds the default maxsize setting which was previously taken out becuase it wasnt working properly. This patch [3] corrects that and is a seperate issue :) [2] http://drupaldocs.org/api/head/function/upload_space_used [3] http://drupal.org/node/30025 ------------------------------------------------------------------------ Fri, 02 Sep 2005 18:31:12 +0000 : Steven Bèr: I'm afraid you missed my point. It is pretty useless for other modules to be able to read the inline value, when upload.module always adds the image to the node body. Suppose I want to make a module which adds more advanced inline positioning, perhaps with a marker tag. I cannot avoid _upload_inline($node) being called, so I have to somehow remove that (themed!) image tag again. This makes the "other modules can use it" argument pretty silly IMO. ------------------------------------------------------------------------ Fri, 02 Sep 2005 18:48:32 +0000 : Dries It would make sense for Ber to provide one or two examples of how this could be used. ------------------------------------------------------------------------ Fri, 02 Sep 2005 21:02:39 +0000 : Bèr Kessels @Steven: no I did not miss your point. on nodeapi view this is appended to the $node->body, regardless. You are correct. But nothing witholds you from using that variable *before* the view is invoked. ou can then choose to unset the variable, or leave it. I first had yet another hook, that would be called on nodeapi view, by the upload, on a per-file base; but then I found that all this was very OTT, since it ca all be achieved with the existing nodeapi. I reverted to the nodeapi. @Dries; examples, sure. 1) Look for the result at http://fixme.remixreading.org/node/595, the small image at the right is rendered with this variable. 5and I must add that users that tested this behaviour were VERY positive!) In phptemplate, the node, we do: <?php foreach ($node->files as $file): ?> <?php if ($file->inline): ?> <div id="preview"> <img src="files/<?php print $file->filename ?>" alt="preview" title="preview of <?php print $node->title ?>" /> </div> <?php endif; ?> <?php endforeach; ?> Because we have ourtheme_upload_inline() to return NULL, this looks like you see online. Together with some CSS you get a very nice result. 2) For most weblogs, or newssites, you need not do anything, for the $node->body has the image already appended *if* the inline checkbox is checked. Esp since these types of sites need a unified look, they do not (or should not) need to alter the place and aligning of each image. 3) For the power users there are node-layout tools available such as tinyMCE, wikisyntax or even inline.module. Since that last one is the simplest I use that as example. <?php function inline_nodeapi(&$node, $op, $arg) { if(is_array($node->files) && $op == 'view') { //on view we replace the tokens with the img tags $node->teaser = _inline_substitute_tags($node, 'teaser'); $node->body = _inline_substitute_tags($node, 'body'); } elseif(is_array($node->files) && $op == 'validate') { $node = _inline_remove_tags($node); //remove the tags that are not flagged as inline } elseif(is_array($node->files) && $op == 'load') { _inline_remove_flags($node) //remove all $node->files[XX]->inline variables, so that upload does not render them. } elseif(is_array($node->files) && $op == 'from pre') { $node = _inline_add_tags($node); //add [inline:X] tokens to 'body', so editor can use them. $node = _inline_remove_tags($node); //remove [inline] tokens that call files that are (no longer) marked for inline use. } } //.... function _inline_add_tags(&$node, $field) { foreach ($node->files as $file) { if ($file->inline && !_inline_check_for_tag($file->filename)) { //look if the tag is not already in body, and if the file is marked for inline usage. $node->body = _inline_add_single_tag($file) . $node->body; //Actually add the token to the beginning of the body $node->teaser = _inline_add_single_tag($file) . $node->teaser; // same for teaser } } } ?> //note. preview is broken no Idea how this post looks ;) ------------------------------------------------------------------------ Sat, 03 Sep 2005 04:37:23 +0000 : TDobes Bèr: The idea of clearing $node->inline never occurred to me... but won't that only work some of the time? It depends on the order in which modules' _nodeapi hooks get called. I believe they get called alphebetically (there's an asort in module_list), so a module whose name starts with v, w, x, y, or z will not be able to prevent upload.module from displaying its inline image. While I do feel this functionality is useful, I think a better way of implementing it would be to allow other modules to add columns to the upload table. Then a module could invoke this upload hook to add a field for "display inline" and invoke _nodeapi to actually place the image. This would provide for future expansion of the upload module in addition to solving the immediate goal. ------------------------------------------------------------------------ Sat, 03 Sep 2005 06:37:17 +0000 : Bèr Kessels in short my battle plan was: * introduce inline stuff * introduce hook for altering the file table Why i did not go for #2 at once? because IMO you can do two things wit a file: show it, or download it. Anything else should be done in a file admin UI. And furthermore: yes modules are ran in alphabetic order, but, nodeapi(load) is ALWAYS ran before nodeapi(view). So you can always make sure on nodeapi(view) the variable is unset. ------------------------------------------------------------------------ Sat, 03 Sep 2005 12:22:00 +0000 : moshe weitzman I think that Ber's suggestion to unset the variable is a great, simple workaround. I don't see any more outstanding objections to the patch. Yes, it can be improved later, but it is useful already. ------------------------------------------------------------------------ Sat, 03 Sep 2005 13:08:05 +0000 : Bèr Kessels the patch is still in brokenish state. I am trying to free some time this weekend (sunday evening) to fix it and synch with HEAd again. not h revisions and JS upload broke this patch. Its a lot of work to reroll, due to that amount of changes (nearly a complete rewrite, I am afraid) ------------------------------------------------------------------------ Mon, 12 Sep 2005 17:48:47 +0000 : Bèr Kessels please review. This a complete rewrite, * I ignored all the huge fucntions and just left tath for another ime to clean up (never). It does make the patch easier to read and smaller, though * I left the 'upload preview' bug for what it is: it belons in a differnt issue, and would clutter this inline feature patch a lot. For the rest see above. * Themes could be updated to do nice stuff to the inline patch. I did not do that, for that goes far beyond what this patch tries to do

1 0

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

12 Sep '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 (code needs work) +Status: patch (code needs review) please review. This a complete rewrite, * I ignored all the huge fucntions and just left tath for another ime to clean up (never). It does make the patch easier to read and smaller, though * I left the 'upload preview' bug for what it is: it belons in a differnt issue, and would clutter this inline feature patch a lot. For the rest see above. * Themes could be updated to do nice stuff to the inline patch. I did not do that, for that goes far beyond what this patch tries to do 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 ------------------------------------------------------------------------ Mon, 18 Jul 2005 19:58:34 +0000 : Bèr Kessels 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 ------------------------------------------------------------------------ Sat, 23 Jul 2005 18:59:10 +0000 : Bèr Kessels Sohodjo jim: " I hope it matters. A big -1 on enforcing over-simplification at the expense of important and existing functionality. If automatic, uncontrollable placement of images becomes the standard, it will mean fewer not more image-rich Drupal sites as site owners/developers get complaints about "Why can't I control my images!" I _strongly_ encourage Ber to provide a "have it both ways" solution. Why not have an admin configuration setting for "allow inline tags" with default off. Change it to on and you get an additional upload checkbox for 'inline at tag' to accommodate the current functionality of the inline module while simultaneously allowing for default placement. " NOOO. people; please; look at the PATCH. Again: and hopefully last time: Simplicity. This patch does NOT replace ANYTHING inline module or img_assist wants to do. This patch hands better data to such modules. It hands a variable over to these modules, $node->file[FID]->inline, which tells these sorts of modules if people wnat that file to appear inline. AND it CAN (by default will) render a file in the most simple way inline. So really, if you want to -1 this patch, fine. But do not -1 it, because it does too little IYO. It still allows MUCH more than what you can do no, without that patch! And any solution, for core, that allows advanced handling of inline images will either require an enourmous amount of work, or it will simply no get in. So, unless you come up with a good core-worthy patch, this is still a big leap forward from what we have now. ------------------------------------------------------------------------ Sat, 23 Jul 2005 19:01:51 +0000 : Bèr Kessels :$ this is an attempt to fix the borken HML in the previous follow up. ------------------------------------------------------------------------ Sun, 24 Jul 2005 04:07:34 +0000 : TDobes Please don't combine unrelated changes together in the same patch. Moving stuff in/out of the _nodeapi hook has absolutely nothing to do with the patch and makes it much harder to read through the patch and see what it's actually doing. I'd appreciate it if you could separate the changes made here which are really relevant and move the other changes into another issue. Also: You change form_group_collapsible(t('File attachments') to form_group_collapsible(t('File Attachments'). A quick glance at some other core code seems to indicate that we've standardized on capitalizing only the first word in multi-word group titles. As for the functionality itself, I don't think this belongs in upload.module. It would be useful to have the functionality in core, but as a separate module which can be switched on and off. (upload_inline.module or something like that) If a site were set up using an inlining system from contrib and the functionality you're proposing could not be switched off, it would be extremely confusing to users that there are two different ways of inlining images. A minor comment: I'm not so sure whether the results of this patch, when inlining non-image attachments, will be the one users expect. A non-web-savvy person may expect his/her Word document (for instance) to appear inline with the node when they click "inline" -- just like their images do. I'd suggest that we limit inlining to images only. I'm not as adamant about this as the other issues, so I could be convinced otherwise if others disagree. ------------------------------------------------------------------------ Sun, 24 Jul 2005 07:58:19 +0000 : Bèr Kessels Thank you for your thoughts Tdobbes. As for the "moving things in and out of nodeapi" This was necessary, because otherwise the patch would have made the code even more unreadable. I agree with you on this point, but I simply had to clean it up a little, in order to be able to work in it. As it stands now, it is simply not possible to make this a separate module. We cannot hook into the files table. In a next stage, I might work out some hook for that table. But first things first. Can Dries or Steven please comment on his. I want to know If i should bother spending this enormous amount of time on commenting and debating this issue. If the chances are small this is accepted, Ill just drop it This ridiculous long thread reminds me again why I try to avoid making patches for core. ------------------------------------------------------------------------ Mon, 25 Jul 2005 05:49:37 +0000 : Steven Overall I like the concept, but I think it at least needs some default styling to make the image appear okay, like floating it. Right now it appears inline between whatever was there... very ugly. Sure you can say "leave it up to the themer" but if the goal is to provide a simple default, we can't expect people to dive into theming if they are going to use this feature instead of img_assist or whatever. Also, I wonder about the classes "upload" and "image". Is there a reason to use two classes? Isn't "image" a bit too generic? Oh and there is a missing XHTML / for the img tag. ------------------------------------------------------------------------ Mon, 25 Jul 2005 12:42:26 +0000 : Bèr Kessels I will fix the broken Xhttml. I chose "image" because it is exactly the same as the .image class used by image.module. But I will see to it, to add more functionality. I agree that it is not up to the themer for some good defaults, thus I will add a line of CSS to drupal.css (*shiver* ;) ) upload, IMO does not communicate well enough what the Image is doing. Not sure yet how I ill fix this, but I will see to it to come up with a better CSS/theme solution. Thanks! ------------------------------------------------------------------------ Tue, 26 Jul 2005 14:18:23 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/upload_inline_0.patch (12.24 KB) Suggestions by Steven are now included. I very simple float is added to the inline images in drupal.css. XHTML fixed. And I cleaned up some old crufty comments, as suggested by Dries. ------------------------------------------------------------------------ Tue, 26 Jul 2005 17:05:45 +0000 : fax8 What is proposed here is a good idea. But I think that this is done in not good way. I think that upload.module should be only a layer between file system and modules. So modify upload module to add a specific feature like your inline for me is not good. but I like the idea to add checkboxes for enable interaction modules between modules and upload.module. Maybe we could design an of api wich let modules tell upload.module that they can interact with it. I make an example: I'm a developer of video.module. Now to add a video file to video.module one need to put the file into drupal folders using ftp and then insert the path to the file during node creation. One of the features our users are asking a lot is the possibility to directly upload a video file to dupal. So I should write a lot of code, settings, security buggy code.. that for me isn't useful. What about if only calling an upload.module api I should enable a new checkbox on upload form called "use as video file" which let me use the file as a video file on my module??? What do you think about it???? ------------------------------------------------------------------------ Tue, 26 Jul 2005 20:00:03 +0000 : Bèr Kessels fax: upload /is/ such a layer. Just look at how image module does it. You need not write any additional 'buggy' code, you can use all teh upload functionality. The upload interface (the table and list), however, is tightly integrated, so that drupal offers an out-of-the-box file system. Nox, my patch simply adds an "out of the box" inline functionality. Small and simple. For any more advanced file features you should use or write a module that, in turn, uses the uplaod.module. ------------------------------------------------------------------------ Wed, 27 Jul 2005 11:22:40 +0000 : stefan nagtegaal After discussing with Ber, I think this patch has some great potential though the simplicity of it.. For the people who don't completely agree what this patch does: - It adds an extra checkbox for each attachment. If the 'Inline' checkbox is checked, images are displayed inline in your post and other attachments (like .pdf, .ppt, or whatever) were transformed into links. The potential of this patch is in the fact that this makes it much, much easier to have another contrib module which makes it possible to let you choose at the node submission how you would like your node to be displayed, incl. the selected inline attachments to be displayed (using _nodeapi()). So, a big +1 from me on this.. ------------------------------------------------------------------------ Wed, 27 Jul 2005 11:27:52 +0000 : Kobus > - It adds an extra checkbox for each attachment. If the 'Inline' > checkbox is checked, images are displayed inline in your post and other > attachments (like .pdf, .ppt, or whatever) were transformed into links. Does this mean it is done automatically or do I have control over this? I don't want the images to be inline if I can't control where I put it. Let me just clarify my position on this short-and-sweet-like: If it breaks the existing functionality that upload.module + inline.module provides without opening the door for a replacement, then I am -1, otherwise +1. :-) Kobus ------------------------------------------------------------------------ Wed, 27 Jul 2005 11:51:50 +0000 : Bèr Kessels Kobus: Again: it does not break anything! It opens up enormous potential for modules such as inline/module. Because inline module now has access to a variable $node->files[fid]->inline. in other words: modules such as inline.module can now find out what images a user wants to see inline! ------------------------------------------------------------------------ Wed, 27 Jul 2005 11:59:53 +0000 : Kobus Ber: Great, then I +1 it. From our previous talks about this, it seemed as if this functionality was being taken away. ------------------------------------------------------------------------ Wed, 27 Jul 2005 16:18:21 +0000 : Sohodojo Jim Agreed, +1. The most on-going and especially most recent discussion has clarified that we can have our simple cake and contrib mod cake as well. Does this mean that inline module will work as is, or will a post-patch update be required? --Sohodojo Jim-- ------------------------------------------------------------------------ Wed, 27 Jul 2005 17:33:47 +0000 : Bèr Kessels inline module will continue working. but in order for it to use this inline variable (and become even better) it needs to be patched. ------------------------------------------------------------------------ Thu, 28 Jul 2005 18:12:09 +0000 : moshe weitzman I read through the code and it looks good to me, though it is hard to know whats new given all the code thats moved around. this is definately needed functionality. If you were still up for enhancements, I'd like to see the 'inline' box get checked by default when uploading an image. when the attachment is not an image, the box should be disabled and unchecked. ------------------------------------------------------------------------ Thu, 28 Jul 2005 18:32:40 +0000 : Bèr Kessels disabling the box for non-images would break the link function (i.e add a link in the text. But, on second thought: that is fine, since it defeats the list checkbox. I will add that. As well as making it checked by default. ------------------------------------------------------------------------ Thu, 28 Jul 2005 19:54:14 +0000 : Junyor @Bèr: Why not simplify this patch to only add the hooks to a contrib module would need to add this functionality? You said that your patch would allow inline.module to work much more easily. But then there is a lot of extra stuff there that inline.module won't need. This functionality can't replace inline.module, so anything that it doesn't use just gets in the way. I'm afraid that users will think this is the best Drupal can provide without looking for a contrib module. I'd prefer we spent our time and effort adding the whole functionality of inline.module or making it easy to add and position inline content in nodes to core rather than adding some functionality to upload.module that doesn't cut it for most users. So, either strip this patch of everything but the functionality that inline.module (and similar modules) can use or allow me to position images in my text through this patch. Otherwise, -1. If this is the first step in a plan to add the functionality I want to core, I'd like to hear your full plan. ------------------------------------------------------------------------ Thu, 28 Jul 2005 21:19:37 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/upload_inline_1.patch (19.71 KB) to all: everyone has Big Plans[tm] and even worse: everyone has Bigger Plans for my patch, for inline module. Why not code it? Hooks? fine! module integration, even better. Sorry if I sound a bit grumpy here. But so far I have spent nearly three times as much hours debbating the patch, then I spent creating it. Hooks sound great. but are not the intention of this patch. I want to add a *default* way, that works. But that does not break other modules, nd in fact tries to help them. But I am not inventing some advanced image handling system here. Here is an updated patch with renewed updates.inc (got lost in the previous patch) Moshes suggestion about disabling non-images-checkboxes is also implemented. I like it a lot more now. I did not, however, implement Moshes idea about defaulting to "checked". for a few reasons: * It looks a bit silly if you have more then one image inline, And defaulting all uploads to inline will inline any uploaded image. * When uploading large images they will default to inline, thus pushing your sites layout to oblivian * None of the other options default to TRUE, so for consistancy I prefer to default it to not inline. ------------------------------------------------------------------------ Thu, 28 Jul 2005 21:24:26 +0000 : Bèr Kessels oh, bytheway: you can test adn play with this patch here: http://fixme.remixreading.org/?q=add_content note that it is a sandbox, so your account will get lost, and pages might not work :) ------------------------------------------------------------------------ Fri, 29 Jul 2005 03:47:35 +0000 : ejort +1 from me for this feature. It's frustrating that core doesn't include some basic image display functionality, and this will cover a large percentage of users needs without introducing complexity. People wanting arbitrary image placement still have inline.module etc., so it's nothing but an improvement on the current situation. ------------------------------------------------------------------------ Fri, 29 Jul 2005 06:38:46 +0000 : Steven Bèr: one thing is not clear to me... you are right that other modules can access the inline value. But upload.module will always add the image to the body. So, how can other modules use the inline checkbox/option meaningfully? ------------------------------------------------------------------------ Tue, 02 Aug 2005 18:33:30 +0000 : Bèr Kessels Steven: what I mean, is that they have access to a variable that tells them a user wants something inline. Nothing more. Its up to these modules to use that meaningfully. ------------------------------------------------------------------------ Thu, 01 Sep 2005 15:26:36 +0000 : Bèr Kessels The patch still applies. Dries, please let me know if I must bother trying to get this in before 4.7? ------------------------------------------------------------------------ Thu, 01 Sep 2005 15:30:09 +0000 : m3avrck Ber, check this latest commit: http://drupal.org/node/28483 ... I think your patch no longer applies since this JS based does do inline functionality. ------------------------------------------------------------------------ Thu, 01 Sep 2005 19:46:35 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/upload_inline_2.patch (20.02 KB) updated patch works with revisions and JS upload. ------------------------------------------------------------------------ Thu, 01 Sep 2005 20:32:11 +0000 : m3avrck got an extra 'favico' in the patch file there. ------------------------------------------------------------------------ Thu, 01 Sep 2005 22:47:24 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/upload_inline_2_0.patch (19.22 KB) favicon removed. ------------------------------------------------------------------------ Thu, 01 Sep 2005 23:06:11 +0000 : killes(a)www.drop.org I think I'd like to have this feature in core. The patch is quite big, though. ;-/ Also I noticed that the pgsql part is bogus. ------------------------------------------------------------------------ Thu, 01 Sep 2005 23:27:42 +0000 : Bèr Kessels how would the pgsql look then? I am a complete pgSQL nitwit :) ------------------------------------------------------------------------ Fri, 02 Sep 2005 15:18:47 +0000 : telex4 Just a quick +1 from a user who is hoping that this gets into core for 4.7. We're using the inline functionality on our Remix Reading test site at the moment, and it's very handy for our theme where the user uploads any number of files and may want one or two images to be previewed in the node. ------------------------------------------------------------------------ Fri, 02 Sep 2005 17:26:49 +0000 : m3avrck Patch needs to be rerolled. Latest 2_0 version does indeed fix JS-based uploads commit, however it is missing all of the database changes and updates from the last _1 patch. Also, upload_count_size() is undefined, should be using upload_space_used() [2] instead. Also, beginning of upload.module patch adds the default maxsize setting which was previously taken out becuase it wasnt working properly. This patch [3] corrects that and is a seperate issue :) [2] http://drupaldocs.org/api/head/function/upload_space_used [3] http://drupal.org/node/30025 ------------------------------------------------------------------------ Fri, 02 Sep 2005 18:31:12 +0000 : Steven Bèr: I'm afraid you missed my point. It is pretty useless for other modules to be able to read the inline value, when upload.module always adds the image to the node body. Suppose I want to make a module which adds more advanced inline positioning, perhaps with a marker tag. I cannot avoid _upload_inline($node) being called, so I have to somehow remove that (themed!) image tag again. This makes the "other modules can use it" argument pretty silly IMO. ------------------------------------------------------------------------ Fri, 02 Sep 2005 18:48:32 +0000 : Dries It would make sense for Ber to provide one or two examples of how this could be used. ------------------------------------------------------------------------ Fri, 02 Sep 2005 21:02:39 +0000 : Bèr Kessels @Steven: no I did not miss your point. on nodeapi view this is appended to the $node->body, regardless. You are correct. But nothing witholds you from using that variable *before* the view is invoked. ou can then choose to unset the variable, or leave it. I first had yet another hook, that would be called on nodeapi view, by the upload, on a per-file base; but then I found that all this was very OTT, since it ca all be achieved with the existing nodeapi. I reverted to the nodeapi. @Dries; examples, sure. 1) Look for the result at http://fixme.remixreading.org/node/595, the small image at the right is rendered with this variable. 5and I must add that users that tested this behaviour were VERY positive!) In phptemplate, the node, we do: <?php foreach ($node->files as $file): ?> <?php if ($file->inline): ?> <div id="preview"> <img src="files/<?php print $file->filename ?>" alt="preview" title="preview of <?php print $node->title ?>" /> </div> <?php endif; ?> <?php endforeach; ?> Because we have ourtheme_upload_inline() to return NULL, this looks like you see online. Together with some CSS you get a very nice result. 2) For most weblogs, or newssites, you need not do anything, for the $node->body has the image already appended *if* the inline checkbox is checked. Esp since these types of sites need a unified look, they do not (or should not) need to alter the place and aligning of each image. 3) For the power users there are node-layout tools available such as tinyMCE, wikisyntax or even inline.module. Since that last one is the simplest I use that as example. <?php function inline_nodeapi(&$node, $op, $arg) { if(is_array($node->files) && $op == 'view') { //on view we replace the tokens with the img tags $node->teaser = _inline_substitute_tags($node, 'teaser'); $node->body = _inline_substitute_tags($node, 'body'); } elseif(is_array($node->files) && $op == 'validate') { $node = _inline_remove_tags($node); //remove the tags that are not flagged as inline } elseif(is_array($node->files) && $op == 'load') { _inline_remove_flags($node) //remove all $node->files[XX]->inline variables, so that upload does not render them. } elseif(is_array($node->files) && $op == 'from pre') { $node = _inline_add_tags($node); //add [inline:X] tokens to 'body', so editor can use them. $node = _inline_remove_tags($node); //remove [inline] tokens that call files that are (no longer) marked for inline use. } } //.... function _inline_add_tags(&$node, $field) { foreach ($node->files as $file) { if ($file->inline && !_inline_check_for_tag($file->filename)) { //look if the tag is not already in body, and if the file is marked for inline usage. $node->body = _inline_add_single_tag($file) . $node->body; //Actually add the token to the beginning of the body $node->teaser = _inline_add_single_tag($file) . $node->teaser; // same for teaser } } } ?> //note. preview is broken no Idea how this post looks ;) ------------------------------------------------------------------------ Sat, 03 Sep 2005 04:37:23 +0000 : TDobes Bèr: The idea of clearing $node->inline never occurred to me... but won't that only work some of the time? It depends on the order in which modules' _nodeapi hooks get called. I believe they get called alphebetically (there's an asort in module_list), so a module whose name starts with v, w, x, y, or z will not be able to prevent upload.module from displaying its inline image. While I do feel this functionality is useful, I think a better way of implementing it would be to allow other modules to add columns to the upload table. Then a module could invoke this upload hook to add a field for "display inline" and invoke _nodeapi to actually place the image. This would provide for future expansion of the upload module in addition to solving the immediate goal. ------------------------------------------------------------------------ Sat, 03 Sep 2005 06:37:17 +0000 : Bèr Kessels in short my battle plan was: * introduce inline stuff * introduce hook for altering the file table Why i did not go for #2 at once? because IMO you can do two things wit a file: show it, or download it. Anything else should be done in a file admin UI. And furthermore: yes modules are ran in alphabetic order, but, nodeapi(load) is ALWAYS ran before nodeapi(view). So you can always make sure on nodeapi(view) the variable is unset. ------------------------------------------------------------------------ Sat, 03 Sep 2005 12:22:00 +0000 : moshe weitzman I think that Ber's suggestion to unset the variable is a great, simple workaround. I don't see any more outstanding objections to the patch. Yes, it can be improved later, but it is useful already. ------------------------------------------------------------------------ Sat, 03 Sep 2005 13:08:05 +0000 : Bèr Kessels the patch is still in brokenish state. I am trying to free some time this weekend (sunday evening) to fix it and synch with HEAd again. not h revisions and JS upload broke this patch. Its a lot of work to reroll, due to that amount of changes (nearly a complete rewrite, I am afraid)

1 0

[drupal-devel] [bug] theme_image() doesn't actually output width and height of image
by m3avrck 12 Sep '05

12 Sep '05

Issue status update for http://drupal.org/node/30935 Post a follow up: http://drupal.org/project/comments/add/30935 Project: Drupal Version: cvs Component: theme system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: m3avrck Updated by: m3avrck Status: patch (ready to be committed) Well the actual code in theme_image() returned this: return '<img src="'. check_url($path) .'" alt="'. check_plain($alt) .'" title="'. check_plain($title) .'" '. $image_attributes . $attributes .'/>'; There is *no* mention of the $width and $height variables that are assigned above, not used at all. I checked images in the themes directory and none had this information, unless I was missing something obvious, I see no way that is being generated... nothing in the above img src about it. m3avrck Previous comments: ------------------------------------------------------------------------ Sun, 11 Sep 2005 16:22:28 +0000 : m3avrck Function theme_image() doesn't actually return a width and height for an image like it claims to do. ------------------------------------------------------------------------ Sun, 11 Sep 2005 19:30:35 +0000 : m3avrck Attachment: http://drupal.org/files/issues/drupal_11.patch (2.74 KB) Ok patched attached, which fixes this issue. Also, included a patch for system.module which sets the screen shots to 'TRUE' so image dimensions will also be outputted there as well (which they should be!). ------------------------------------------------------------------------ Sun, 11 Sep 2005 19:33:41 +0000 : m3avrck Attachment: http://drupal.org/files/issues/drupal_12.patch (2.75 KB) Fixed a tab issue. ------------------------------------------------------------------------ Sun, 11 Sep 2005 19:35:46 +0000 : m3avrck Attachment: http://drupal.org/files/issues/drupal_13.patch (2.75 KB) Fixed a spacing issue. ------------------------------------------------------------------------ Mon, 12 Sep 2005 14:18:32 +0000 : Souvent22 Used the patch, and did a quick test. Worked well for me. +1. ------------------------------------------------------------------------ Mon, 12 Sep 2005 16:21:16 +0000 : Robrecht Jacques I don't see why this patch is needed, "theme_image" returns a img tag with the width and height set if $getsize = TRUE. Eg: $node->body = theme('image', file_create_path('druplicon.png'), 'no alt', 'no title', array(), TRUE) . theme('image', file_create_path('druplicon.png'), 'no alt', 'no title', array(), FALSE) will return: <img src="files/druplicon.png" alt="no alt" title="no title" width="88" height="100" /> <img src="files/druplicon.png" alt="no alt" title="no title" /> (if druplicon.png is copied to the files/ directory). I don't see what you are fixing... You are right about the use of theme('image') in system.module though. The "false" should be "true".

1 0

[drupal-devel] [bug] theme_image() doesn't actually output width and height of image
by Robrecht Jacques 12 Sep '05

12 Sep '05

Issue status update for http://drupal.org/node/30935 Post a follow up: http://drupal.org/project/comments/add/30935 Project: Drupal Version: cvs Component: theme system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: m3avrck Updated by: Robrecht Jacques Status: patch (ready to be committed) I don't see why this patch is needed, "theme_image" returns a img tag with the width and height set if $getsize = TRUE. Eg: $node->body = theme('image', file_create_path('druplicon.png'), 'no alt', 'no title', array(), TRUE) . theme('image', file_create_path('druplicon.png'), 'no alt', 'no title', array(), FALSE) will return: <img src="files/druplicon.png" alt="no alt" title="no title" width="88" height="100" /> <img src="files/druplicon.png" alt="no alt" title="no title" /> (if druplicon.png is copied to the files/ directory). I don't see what you are fixing... You are right about the use of theme('image') in system.module though. The "false" should be "true". Robrecht Jacques Previous comments: ------------------------------------------------------------------------ Sun, 11 Sep 2005 16:22:28 +0000 : m3avrck Function theme_image() doesn't actually return a width and height for an image like it claims to do. ------------------------------------------------------------------------ Sun, 11 Sep 2005 19:30:35 +0000 : m3avrck Attachment: http://drupal.org/files/issues/drupal_11.patch (2.74 KB) Ok patched attached, which fixes this issue. Also, included a patch for system.module which sets the screen shots to 'TRUE' so image dimensions will also be outputted there as well (which they should be!). ------------------------------------------------------------------------ Sun, 11 Sep 2005 19:33:41 +0000 : m3avrck Attachment: http://drupal.org/files/issues/drupal_12.patch (2.75 KB) Fixed a tab issue. ------------------------------------------------------------------------ Sun, 11 Sep 2005 19:35:46 +0000 : m3avrck Attachment: http://drupal.org/files/issues/drupal_13.patch (2.75 KB) Fixed a spacing issue. ------------------------------------------------------------------------ Mon, 12 Sep 2005 14:18:32 +0000 : Souvent22 Used the patch, and did a quick test. Worked well for me. +1.

1 0

[drupal-devel] [feature] Enable customizing of "Title" field on node forms
by Robrecht Jacques 12 Sep '05

12 Sep '05

Issue status update for http://drupal.org/node/10056 Post a follow up: http://drupal.org/project/comments/add/10056 Project: Drupal Version: cvs Component: node system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Anonymous Updated by: Robrecht Jacques Status: patch (ready to be committed) Attachment: http://drupal.org/files/issues/title-validation_1.patch (6.23 KB) +1 I need this too: I want to be able to set the title of a node automatically. Patch still applies with offset (rerolled patch attached). Robrecht Jacques Previous comments: ------------------------------------------------------------------------ Sat, 14 Aug 2004 18:17:11 +0000 : Anonymous Attachment: http://drupal.org/files/issues/node.set-title-field.patch (2.02 KB) The default "title" field in a node object is useful but not always appropriate. For some node types it would be preferable to rename the field for display to users (e.g., from "title" to "name" for a record of an organization or business), while in others the title might be best drawn from a combination of other fields (e.g., first_name and last_name fields, for a record of an individual). This patch enables two new alternatives for node titles: renamingThe title field can be renamed, e.g., from "title" to "name". substutingOther fields can be substituted for the title field. The functionality is implemented through a new proposed node hook, _title_field($op). There are two possible values for $op: "action" (either "rename" or "substitute") and "names" (a list of field names to be used in the title field). Sample uses: [?PHP function example_title_field($node, $op) { switch ($op) { case 'action': $return = 'rename'; break; case 'names': $return = array('Name'); } return $return; } ?] In this case, since the requested action is "rename", the title field would be labelled "Name" (instead of "Title") in node add and edit forms for nodes of type "example". [?PHP function example_title_field($node, $op) { switch ($op) { case 'action': $return = 'substitute'; break; case 'names': $return = array('first_name', 'last_name'); } return $return; } ?] In this case, no "Title" field would be displayed in node add or node edit forms of node type "example". Instead, the fields "first_name" and "last_name" would be concatenated to form a title. Implementing this patch would significantly increase the flexibility of the node system, making it feasible to store information of many types not currently supported because they don't have a "title" attribute. ------------------------------------------------------------------------ Sun, 15 Aug 2004 16:39:37 +0000 : Dries This is best accomplished through the existing nodeapi hook, using a separate module. ------------------------------------------------------------------------ Sun, 15 Aug 2004 23:02:13 +0000 : nedjo Thanks for the suggestion. I did look for a way to accomplish this through _nodeapi (and other existing hooks), but couldn't see how. The "title" field is hard-coded into node.module. The _nodeapi hook allows various types of manipulations, but not, so far as I could see, changes to elements that have been generated by, e.g., form_textfield() calls. Are there possibilities I'm missing? Other approaches? Any specific suggestions as to means we could use to change the hard-coded "title" field? ------------------------------------------------------------------------ Thu, 19 Aug 2004 18:27:15 +0000 : nedjo Attachment: http://drupal.org/files/issues/node.set-title-field_0.patch (741 bytes) Drawing on Dries's suggestion, I've substantially revised this patch to enable node title field customization with only three additional lines of code in node.module. In place of the existing line in function node_form() <?php $output .= form_textfield(t('Title'), 'title', $edit->title, 60, 128, NULL, NULL, TRUE); ?> the patch substitutes a the following: <?php $title = variable_get('node_titlefield_'. $edit->type, 'Title'); if(!($title == 'none')) { $output .= form_textfield(t($title), 'title', $edit->title, 60, 128, NULL, NULL, TRUE); } ?> With this change in place, node modules will be able to override the standard node title label by setting a variable, node_titlefield_nodetype, where nodetype is the type of node. This could be done, e.g., in a _settings hook, so that the first time settings were accessed the module would set the variable: <?php if (variable_get('node_titlefield_example', '') == '') { // since none is already set, set this variable variable_set('node_titlefield_example', 'Name'); drupal_set_message('Example module initialization completed.'); } ?> The special value 'none' would suppress the title field altogether in node forms, used as follows: <?php if (variable_get('node_titlefield_example', '') == '') { // since none is already set, set this variable variable_set('node_titlefield_example', 'none'); drupal_set_message('Example module initialization completed.'); } ?> In this case, a _validate hook would be used to set the title field value. Assuming a module where a first name-last name combination was to be used for a title: <?php function example_validate(&$node) { if(!(isset($node->title))) { $node->title = $node->first_name . ' ' . node->last_name; } } ?> In short, this three-line addition to the node.module would significantly increase the flexibility of the node system by removing the hard-coded 'Title' field in node add and edit forms and instead enabling custom labelling or concatenation of the field from other sources. ------------------------------------------------------------------------ Thu, 19 Aug 2004 18:50:42 +0000 : moshe weitzman I like this functionality. But the implementation still seems unclean. I would prefer to simply remove the 'title' form field from node_form() and require that modules present this field in whatever way they please. in some cases, they will use a hidden form field because no customer interaction is required. This causes a break with backward compatibility, but cleanliness is facored over compatibilityness (when you must choose). I'm moving this back to 'Active', since I don't think this patch is committable as is. ------------------------------------------------------------------------ Fri, 27 Aug 2004 23:46:45 +0000 : nedjo Attachment: http://drupal.org/files/issues/node.set-title-field_1.patch (830 bytes) Thanks for looking at this. The suggestion - dropping the title field altogether and leaving this for module authors - has the advantage of simplicity. However, this change would imply significant new work as it would would require all or nearly all existing modules - core and contributed - be modified. While I think enabling title field customization is important for Drupal as a whole, and while this is a change I need for two modules I'm working on, I'm not immediately convinced that the benefits of this change justify this cost. Also, in most cases, the present title field works fine, so keeping it as a default option would I feel be desirable. Hence the following patch. In place of my (poorly conceived) initial hook proposals, above, this patch introduces a single very straightforward new node hook, _title_field. By setting this hook to return FALSE, node modules authors will suppress the default title field, and be free therefore to substitute what they wish or need. Returning TRUE, or not using the hook, will result in the default title field being used. Sample usage: <?php function example_title_field() { return FALSE; } ?> This is, I feel, a much better solution than the previous two I suggested--proof, if it's true, that the Drupal issue system works! ------------------------------------------------------------------------ Mon, 06 Sep 2004 15:50:38 +0000 : nedjo Are there any objections to or issues raised by this small patch (introducing a new hook to make the title field optional in node forms)? If not, can it be applied? ------------------------------------------------------------------------ Tue, 07 Sep 2004 13:46:29 +0000 : Anonymous I think I agree with Moshe's opinion that this should be accomplished by having node modules display the title field. In any event, this is a new feature and shouldn't go in during the feature freeze for 4.5. ------------------------------------------------------------------------ Tue, 07 Sep 2004 13:58:34 +0000 : ccourtne +1 for just moving the title field to be a responsibility of the implementing module instead of node_form. There is already to some extent "hook overload", in addition there may be several modules which don't want to even display a title module. Why add that only fixes some of the problems just to have to remove it later when you make a fix that address the whole problem. ------------------------------------------------------------------------ Tue, 07 Sep 2004 21:09:53 +0000 : nedjo Attachment: http://drupal.org/files/issues/node.remove-title-field.patch (636 bytes) Thanks for comments. As per feedback, the attached patch removes the title field from node forms, leaving this instead to node modules. Understood that possible approval of this patch this will need to wait until code unfrozen. ------------------------------------------------------------------------ Sun, 24 Oct 2004 12:06:46 +0000 : moshe weitzman please patch all core node modules as well. ------------------------------------------------------------------------ Sun, 28 Nov 2004 01:00:31 +0000 : nedjo Attachment: http://drupal.org/files/issues/node-move-form-title-field.patch (4.29 KB) Good point Moshe. This patch of node.module plus all core node modules simply moves the title field out of node.module and into the node modules, enabling (if desired) customization of the title field by a module. Patches to contributed modules will in most cases be as simple as adding the line <?php $output = form_textfield(t('Subject'), 'title', $node->title, 60, 128, NULL, NULL, TRUE); ?> at the beginning of a typename_form() function (and, if necessary changing an existing $output = to $output .=). In the attached patch, I've customized the title field for only one of the node types, calling the title of a forum topic the "Subject". We could consider calling the title of a blog a "Subject" or "Topic" as well. I feel this is a good solution (thanks for the feedback and discussion) and, for minimal work (minor updates to contributed modules), will have the significant benefit of enabling flexibility in content types beyond those that have "title" attributes. ------------------------------------------------------------------------ Sun, 28 Nov 2004 17:45:35 +0000 : nedjo Ability to customize title as provided in this patch was requested here [1]: "When adding/editing, the 'title' field is manditory, which is fine. Except that its label is hardcoded to 'title'. A custom node modelling, say, a 'Company' would much rather this field be presented to the user as 'Company Name'. " [1] http://drupal.org/node/13596 ------------------------------------------------------------------------ Fri, 04 Mar 2005 03:44:55 +0000 : nedjo Here's another patch that's sat for months without being either applied or turned down, although there was expressed support and, after several iterations, it addressed all issues that had been raised. The point is to remove the hard-coded "Title" field - inapprioriate for many node types, e.g., companies - from node forms, instead allowing node modules to treat this as appropriate (e.g., a "Subject", "Name" or "Topic", or nothing at all). Are there problems with this approach that were not raised? Is there a reason this wasn't accepted? ------------------------------------------------------------------------ Fri, 04 Mar 2005 03:54:02 +0000 : Steven nedjo: if you read the backlog you can see that this feature was delayed for after the 4.6 release. "I've customized the title field for only one of the node types, calling the title of a forum topic the "Subject". " This is really inconsistent, as what you call the title of a blog, story or forum node is purely subjective. "Subject" "Topic" and "Title" are pretty much interchageable and any subtle differences will surely be eroded by translation. The only thing I can agree on so far is naming a polls' title "Question". ------------------------------------------------------------------------ Fri, 04 Mar 2005 05:15:03 +0000 : nedjo Thanks for the note. I'm not sure what you mean by the "backlog". Where would I find this? I agree that a "Question" field would make sense for polls. ------------------------------------------------------------------------ Fri, 04 Mar 2005 14:12:56 +0000 : JonBob Actually UnConeD, it was postponed until after the 4.5 release, not 4.6, and looks like everyone forgot about it when the release happened. And no, Nedjo, I don't take this as proof that Drupal needs more bureaucracy. :-) Marking this active again; I'm sure the patch will have to be updated once the code branches. We had rolled this function into the needs for CCK, but in our discussions split it off again. ------------------------------------------------------------------------ Sun, 03 Apr 2005 05:28:08 +0000 : chx Attachment: http://drupal.org/files/issues/node-move-form-title-field_0.patch (4.59 KB) The patch applies to ucrrent HEAD with some offset. I have rerolled it so it applies cleanly. ------------------------------------------------------------------------ Fri, 20 May 2005 10:09:50 +0000 : chx Patch still applies (yes, with some offset, but applies). ANd yes, we need this very badly. ------------------------------------------------------------------------ Fri, 20 May 2005 10:18:49 +0000 : Thox I'd benefit greatly from having a feature like this. The example already given is one of the cases I need it: I'd like the title field to be a concatenation of two fields: "First name" and "Last name". ------------------------------------------------------------------------ Tue, 24 May 2005 03:39:40 +0000 : gsperk I wonder if someone could help me with the following problem. After applying the patch I made the output for 'title' in my own_node.module this: $output .= form_hidden('title', $node->firstname . ' ' . $node->surname); When the form is first submitted I get the error 'You have to specify a title'. When I submit again the firstname/surname variables are obviously in $node, and the form submits with the desired title. So, I suppose my question is, how can get the values for firstname and surname into $node without submitting twice? (If it's not obvious I can confirm that I dont have much experience with this kind of stuff. Any suggestions would be a big help.) ------------------------------------------------------------------------ Wed, 25 May 2005 04:23:41 +0000 : Steven To make this patch work you also need to move the title validation out of node.module and into the node modules. I don't think this is that much of a problem, it is code that is not going to be touched much. Also, in light of the upcoming CCK it makes sense to do it like this. ------------------------------------------------------------------------ Sat, 02 Jul 2005 17:02:26 +0000 : hanoii Nice thread. I have come up with a slightly different approach I think that would need less patching/updating of other modules. Drupal 4.6.2 node.module:1275 <?php // Get the node-specific bits. // We can't use node_invoke() because $param must be passed by reference. $function = node_get_module_name($edit) .'_form'; $param = array(); if (function_exists($function)) { $form .= $function($edit, $param, $title); } ?> Notice the $title param on the hook_form invoke. This was what I added. As that hook is called like this an not with the node_invoke() I can define on my custom node module, or patch any module I need to modify the title description with the following hook: <?php function budget_form(&$node, &$params, &$title) { ?> and modify the $title argument there, as it is by reference, It will me modified on node.module. Then again on node.module:1319 I added/changed the following: <?php if ( ! $title ) { $title = t('Title') ; } $output .= form_textfield($title, 'title', $edit->title, 60, 128, NULL, NULL, TRUE); ?> So, if the module modify the title var, it uses that, if not, it uses the default one. Worked for me so far, nice to post on drupal. Greetings, a.= ------------------------------------------------------------------------ Sat, 02 Jul 2005 18:10:28 +0000 : hanoii I posted too soon the thing before... :) I did further patches because of the validation keep telling that I have tu put a "title". I was happy with the previous patch, not so much with this one, but I let you know what I did... on the node.module, node_validate() function I move the title validation block just after the <?php // Do node-type-specific validation checks. node_invoke($node, 'validate'); node_invoke_nodeapi($node, 'validate'); ?> and added another parameter to the form_set_error() <?php // Validate the title field. if (isset($node->title)) { if (trim($node->title) == '') { form_set_error('title', t('You have to specify a title.'), TRUE); } } ?> then, on the form_set_error function in common.inc I did the following: <?php /** * File an error against the form element with the specified name. */ function form_set_error($name, $message, $checkexistance = FALSE ) { if ( !$checkexistance || $checkexistance && !isset($GLOBALS['form'][$name]) ) { $GLOBALS['form'][$name] = $message; drupal_set_message($message, 'error'); } } ?> So now, if any previous title error was added, and the $checkexistance flag is TRUE, no error will be added to the message queue. The moving place of the validation block was to let the modules validate first than the node module. Errrr.. I don't like it, but again, it worked :) a.= ------------------------------------------------------------------------ Mon, 01 Aug 2005 00:54:22 +0000 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/title_0.patch (4.56 KB) I've updated the patch to apply to current cvs. As progress on the CCK has been rather slow, I'd appreciate if somebody could address Steven's concerns and the patch could be applied. ------------------------------------------------------------------------ Tue, 16 Aug 2005 19:19:23 +0000 : Thox Attached is a patch with an attempt to move the title validation code into the node modules (from node.module). ------------------------------------------------------------------------ Tue, 16 Aug 2005 19:20:21 +0000 : Thox Attachment: http://drupal.org/files/issues/title-validation.patch (6.22 KB) attached again (issue preview seems busted?) ------------------------------------------------------------------------ Wed, 24 Aug 2005 18:57:26 +0000 : nedjo Thanks chx, killes, and Thox for updates and fixes on the patch. I've applied and tested it and Thox's changes seem to address the title validation issue. It's a couple of releases later--it would be great to see this fix applied! ------------------------------------------------------------------------ Wed, 24 Aug 2005 23:17:25 +0000 : mathias Attachment: http://drupal.org/files/issues/title-validation_0.patch (6.04 KB) +1 I've needed to change the name of the title field or even altogether hide it for custom modules. Issue preview was working for me. We should document for module developers the implications title-less nodes (e.g., less informative watchdog entries, harder to edit nodes, node title lists become buggy, etc). I couldn't get the patch to apply cleanly to HEAD so here's a new one.

1 0

[drupal-devel] Tag performance
by Dries Buytaert 12 Sep '05

12 Sep '05

See http://pui.ch/phred/ for some interesting articles on the performance of tag-systems. Well worth a read if you plan to use Drupal to maintain thousands of tags. -- Dries Buytaert :: http://www.buytaert.net/

1 0

[drupal-devel] [bug] theme_image() doesn't actually output width and height of image
by Souvent22 12 Sep '05

12 Sep '05

Issue status update for http://drupal.org/node/30935 Post a follow up: http://drupal.org/project/comments/add/30935 Project: Drupal Version: cvs Component: theme system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: m3avrck Updated by: Souvent22 Status: patch (ready to be committed) Used the patch, and did a quick test. Worked well for me. +1. Souvent22 Previous comments: ------------------------------------------------------------------------ Sun, 11 Sep 2005 16:22:28 +0000 : m3avrck Function theme_image() doesn't actually return a width and height for an image like it claims to do. ------------------------------------------------------------------------ Sun, 11 Sep 2005 19:30:35 +0000 : m3avrck Attachment: http://drupal.org/files/issues/drupal_11.patch (2.74 KB) Ok patched attached, which fixes this issue. Also, included a patch for system.module which sets the screen shots to 'TRUE' so image dimensions will also be outputted there as well (which they should be!). ------------------------------------------------------------------------ Sun, 11 Sep 2005 19:33:41 +0000 : m3avrck Attachment: http://drupal.org/files/issues/drupal_12.patch (2.75 KB) Fixed a tab issue. ------------------------------------------------------------------------ Sun, 11 Sep 2005 19:35:46 +0000 : m3avrck Attachment: http://drupal.org/files/issues/drupal_13.patch (2.75 KB) Fixed a spacing issue.

1 0

[drupal-devel] code freeze
by Dries Buytaert 12 Sep '05

12 Sep '05

Just a quick reminder that the Drupal 4.7 code freeze is only 3 days away. -- Dries Buytaert :: http://www.buytaert.net/

1 0

[drupal-devel] [bug] Teaser always truncated at 600 characters
by Goba 12 Sep '05

12 Sep '05

Issue status update for http://drupal.org/node/28211 Post a follow up: http://drupal.org/project/comments/add/28211 Project: Drupal Version: cvs Component: node.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: neale Updated by: Goba Status: patch (code needs review) Excuse me, I have not seen that you actually used strrpos() in your patch. You are right that the previous version might have broken tags, but the intention was to search for typical block tags, which are not supposed to be enclosed in inline tags or anything, since it is not valid markup. Your code might break any tag, block tags and inline tags alike. Goba Previous comments: ------------------------------------------------------------------------ Thu, 04 Aug 2005 19:18:23 +0000 : neale Attachment: http://drupal.org/files/issues/diff_27 (1.16 KB) The truncation code in node_teaser doesn't make any sense to me: <?php foreach ($breakpoints as $point => $charnum) { if ($length = strpos($body, $point, $size)) { return substr($body, 0, $length + $charnum); } } ?> I don't understand: why is the offset given to strpos the maximum teaser size? This would cause teasers to only be nicely split if they are enough longer than the max. teaser size to have one of the special characters. But this guarantees the teaser will either be abruptly truncated, or over the max. teaser size! In fact, this is what I'm seeing on my installation. Attached is a patch that makes it work the way I think it was intended. At least, it makes more sense to me. ------------------------------------------------------------------------ Sun, 21 Aug 2005 19:49:15 +0000 : killes(a)www.drop.org changing version and status. ------------------------------------------------------------------------ Mon, 22 Aug 2005 11:36:11 +0000 : Goba Neale, your code does not reflect the intentions in Drupal. The problem with this patch is that it forces a truncate call on the body, regardless of content, and then reduces the teaser size even more, to the first paragraph, first sentence, etc. Problems with your approach are: * If the first paragraph is too short, it will be the teaser, regardless of the set size. * If there are no paragraph or break tags in the truncated teaser part, the first sentence will be used (regardless of how short is it). * On the other hand, if the first paragraph is too long, and the closing tag is out of the initial truncated part, you will end up with broken HTML. Now all these are not the intention of the teaser generation code. Having the exact set length or shorter is sacrificed for having valid HTML, and complete content. While the current Drupal code might produce too long teasers, your code can easily end up producing too short ones. A teaser for this text with your patch would be: /Neale, your code does not reflect the intentions in Drupal./ ------------------------------------------------------------------------ Mon, 22 Aug 2005 18:06:22 +0000 : neale (Oddly, previewing this gives no trimmed version and no full version. I hope the formatting here looks okay.) Goba, I'm not sure I understand your objections. You say: * "If the first paragraph is too short, it will be the teaser, regardless of the set size. " I presume you mean that an article with two paragraphs (one short, one long) would be split at the end of the first paragraph. Currently, if I write an article with three paragraphs (short, long, long), the teaser will be the first two (short, long) even if the second paragraph runs over the max. teaser size. In fact, unless the entire article is under the max. size, it is *guaranteed* that the teaser will be over the max., since the code only looks for a breakpoint *after* $size. I'm not sure this is in line with what drupal wants, since the help for the max. teaser size states (emphasis mine) it is "The *maximum* number of characters used in the trimmed version of a post." My patch addresses this by looking for a split character in the characters before the max. length. * " If there are no paragraph or break tags in the truncated teaser part, the first sentence will be used (regardless of how short is it). " This is untrue. My patch applies after the code that looks for the break tag, and does not alter the existing logic. Unfortunately, the patch doesn't show the (unmodified) part of the code you mention, so it might be worthwhile to look at the patch alongside the original code to see exactly what it does. * " On the other hand, if the first paragraph is too long, and the closing tag is out of the initial truncated part, you will end up with broken HTML. " This is a different problem already present in the code. My patch doesn't try to address this. (Try it: create a new book page right here, and begin it with an em tag, then paste the same sentence over and over, and close the em tag. The teaser will have an unclosed tag.) I humbly suggest the reviewer look over the patch again. ------------------------------------------------------------------------ Mon, 22 Aug 2005 18:22:02 +0000 : neale It just occurred to me that when you said "break tag" you may have meant the "br" tag and not the "!--break--" thing. In that case, your second point is a little closer to true, but still not quite correct. My patch will use as many sentences as it can before it hits the max. size (note the change from strpos to strrpos). Perhaps the help for the "size" should be changed to read *minimum* size of a teaser, instead of maximum size for a teaser, if the current behavior is what drupal is supposd to do. Currently, the teaser will always be larger than the "maximum size" unless the !--break-- thing is used. You can test this here by creating a new book page with a very short paragraph followed by an incredibly long one, maybe 16000 characters in multiple paragraphs. The incredibly long one is always part of the "trimmed version". If you'd like to see my patch in action, head on over to , where it is currently running.

1 0

[drupal-devel] Re: [contributions:MegaGrunt] /modules/publication publication.module publication.mysql readme.txt
by Sheldon Rampton 12 Sep '05

12 Sep '05

Robert Castelo wrote: > 1) This is a 'component' module. For the sake of avoiding confusion, I should mention that Robert's publication.module is completely different from a module by the same name that we have been developing (and which I have discussed with folks on the Civicspace website during our module's beta development). We recently discovered that Robert's module has the same name as ours when our webmaster attempted to add our module to Drupal contributions and found that Robert's module had already been uploaded. (Unfortunately, she realized this after she had already uploaded our files on top of Robert's.) To avoid any future confusion or naming conflicts, we have decided to rename our project to "epublish.module." We're planning to add it to Drupal contribs as soon as we've finished testing the code of the renamed module (hopefully later this week). -------------------------------- | Sheldon Rampton | Research director, Center for Media & Democracy (www.prwatch.org) --------------------------------

1 0