- Development - lists.drupal.org

[drupal-devel] [feature] Enable customizing of "Title" field on node forms
by fago 16 Sep '05

16 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: fago Status: patch (ready to be committed) Attachment: http://drupal.org/files/issues/nodetitle-updated2.patch (7.13 KB) updated the patch again. now node_validate_title() takes the whole error message as optional second parameter as this allows more customization by modules. fago 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. ------------------------------------------------------------------------ Mon, 12 Sep 2005 15:42:30 +0000 : Robrecht Jacques 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). ------------------------------------------------------------------------ Tue, 13 Sep 2005 13:59:39 +0000 : fago +1 for this functionality i've tested the patch and it looks nice, however node_validate_title() produces an validation error, where the field is called title, which isn't suitable if the modules changes the name, as the forum.module does. ------------------------------------------------------------------------ Tue, 13 Sep 2005 15:50:15 +0000 : Thox Perhaps node_validate_title() should be passed the name of the field? 'Title' by default. ------------------------------------------------------------------------ Fri, 16 Sep 2005 13:22:24 +0000 : fago Attachment: http://drupal.org/files/issues/nodetitle-updated.patch (7.05 KB) i've updated node_validate_title() as thox suggested and added a title "question" to the poll.module, as there was no title field for it.

1 0

[drupal-devel] [feature] Prevent accidentally navigating away from pages where content has changed
by m3avrck 16 Sep '05

16 Sep '05

Issue status update for http://drupal.org/node/30220 Post a follow up: http://drupal.org/project/comments/add/30220 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: m3avrck Updated by: m3avrck Status: patch (ready to be committed) nedjo, great catch! I totally missed that too, haha! Anyways retested, everything is still working as expected. Dries, please committ JS in #35 with patch in #30. Thanks! m3avrck Previous comments: ------------------------------------------------------------------------ Thu, 01 Sep 2005 22:47:42 +0000 : m3avrck How many times have you been posting a comment or working on a new post when you click on a link in another application and you navigate away from the content you are editing, losing all of your changes? Well I say we introduce a script, much similiar to that of Blogger, that uses the Javascript window.onbeforeunload handler to prevent this from happening. We can set this handler to call a function that compares the contents of all forms when the page loads and then quickly compares that to the current contents just before the user is about to leave the page. If they have changed, we should prompt the user so they don't lose their work. This would save many headaches and degrade nicely for users without Javascript. Additionally, this script should work with the newly introduced JS-based upload feature to prevent navigating away as a file is being uploaded as well. If I have sometime I'll start work on a patch tomorrow, just wanted to get the idea into the queue right now :) ------------------------------------------------------------------------ Sat, 10 Sep 2005 23:48:33 +0000 : StuartDH Sounds like a great feature to me. We regularly get authors and editors telling us that they've lost the last hour of work by accidentally navigating away, and I've even just had one of them email me about it a few minutes ago, so it'd be great if you could put something together for this. Cheers ------------------------------------------------------------------------ Mon, 12 Sep 2005 14:33:58 +0000 : MichelleC Sounds great to me, too. I often have several tabs open doing stuff and it's easy to lose my place and leave a page with unfinished edits. Would this alert you when you're going to close an unsaved tab/window as well? Michelle ------------------------------------------------------------------------ Mon, 12 Sep 2005 14:34:19 +0000 : MrMattles Great for us multitaskers that rush and click the wrong thing ------------------------------------------------------------------------ Mon, 12 Sep 2005 14:36:52 +0000 : chx Very strong -1 as this is IE only. ------------------------------------------------------------------------ Mon, 12 Sep 2005 14:38:40 +0000 : praseodymium Konqueror already does this, +1 for the idea in general. ------------------------------------------------------------------------ Mon, 12 Sep 2005 15:07:21 +0000 : webchick Yeah, I think chx is correc that onbeforeunload is an extension developed by MS [1] (it's not in the ECMAScript specification [2]. However, I found out that this is implemented in Mozilla since 1.7 [3] (which corresponds to Firefox 1.0, I think?) and I've tested Blogger.com's version of this functionality in: Firefox 1.0.6 (working) Firefox Deer Park Alpha 1 (working) Opera 8.0.2 (working) Safari 1.3 (does NOT work) Safari 2.0.1 (working) So it seems to be a 'de facto' standard if nothing else. [1] http://msdn.microsoft.com/workshop/author/dhtml/reference/events/onbeforeun… [2] http://www.ecma-international.org/publications/standards/Ecma-262.htm [3] http://www.mozilla.org/status/2004-03-01.html ------------------------------------------------------------------------ Mon, 12 Sep 2005 15:09:15 +0000 : webchick Also, I should clarify... that "does NOT work" in Safari doesn't display any errors or anything, it just doesn't save the form results as expected (so pre-Tiger Safari users are going to be used to this). So I don't see any harm in including this functionality since it seems to degrade gracefully in non-supporting browsers. ------------------------------------------------------------------------ Mon, 12 Sep 2005 21:10:18 +0000 : m3avrck Attachment: http://drupal.org/files/issues/node.module_11.patch (951 bytes) And a patch is ready! Code was based on many example, including this [4] and this [5] along with adding my own thoughts and what not ;) [4] http://www.codestore.org/store.nsf/cmnts/451FA051398A9AF486256EE0000FB7D1?O… [5] http://www.blogger.com/app/scripts/formcheck.js ------------------------------------------------------------------------ Mon, 12 Sep 2005 21:10:45 +0000 : m3avrck Attachment: http://drupal.org/files/issues/formcheck.js (1.54 KB) And here is the JS to throw in misc/. ------------------------------------------------------------------------ Mon, 12 Sep 2005 21:22:56 +0000 : m3avrck Attachment: http://drupal.org/files/issues/formcheck_0.js (1.61 KB) Better JS file attached without tabs. Also, tested and working great in FF and IE6. Doesn't work in Opera 8, however no errors are present, I believe this is just because the event handler is not supported. If there is a work around for Opera, please let me know! ------------------------------------------------------------------------ Mon, 12 Sep 2005 21:24:18 +0000 : m3avrck Attachment: http://drupal.org/files/issues/formcheck_1.js (1.61 KB) One more try with those tabs. ------------------------------------------------------------------------ Mon, 12 Sep 2005 21:32:48 +0000 : moshe weitzman hmmm. i usually find these prompts annoying. any chance we can attach the behavior only to the node and comment forms? those are the "high risk" areas. what do others think? ------------------------------------------------------------------------ Mon, 12 Sep 2005 21:42:39 +0000 : m3avrck Yes, the JS is only loaded on the node edit/create pages, won't affect any admin/login/etc form. Also, the prompt is unobstrusive and if you goto save a node you don't get a warning that the contents have changed because you are explicity saving the node (hence no reason!). ------------------------------------------------------------------------ Mon, 12 Sep 2005 21:53:01 +0000 : Dries I want some JS-folks to review the code. ------------------------------------------------------------------------ Mon, 12 Sep 2005 22:09:10 +0000 : m3avrck Attachment: http://drupal.org/files/issues/drupal_15.patch (1.94 KB) After talking with Drumm on IRC, this patch makes the integration with Drupal much simpler and it's off by default. Only turned on for the node edit/change page right now but any module/form can easily add this by passing a 'TRUE' parameter. ------------------------------------------------------------------------ Mon, 12 Sep 2005 23:38:35 +0000 : nedjo +1 on idea, js looks generally good, a few suggestions: 1. Instead of writing onsubmit via PHP, use a js addLoadEvent call. 2. Shouldn't the return false in isElementChanged be at the end (outside the switch block)? 3. It's be nice to find a way to make messages like 'You have unsaved changes.' translatable. Pass in global js variables via a t('') call? 4. onbeforeunload event should probably be in a if isJsEnabled test, and should parallel drupal.js's event adding (see addLoadEvent). 5. Comments should be in standard format and in present tense, e.g., /** * Checks to see if a form has been changed after the page loads */ 6. e_ should be just e to match other js files, e.g., autocomplete. ------------------------------------------------------------------------ Tue, 13 Sep 2005 13:54:35 +0000 : m3avrck Attachment: http://drupal.org/files/issues/formcheck_2.js (1.58 KB) Ok here is an updated JS file. A few notes, I couldn't get the addSubmitEvent() in drupa.js to reliably work so I had to set the isSubmit() true in the PHP creation of the form. If you look at Blogger.com, they do this as well... so either we both missed an obvious way to do this, or that is the most practical. Hopefully some wise JS gurus will chime in with an answer. Same goes for onbeforeunload event, which is completely different then addEvent defined in drupal.js. As for the t('') I agree this would be useful but I'm not sure of the best way to do this. One way would be to put in form() a t('') passed in, and then write this to a var in formcheck.php which returns a JS file type. Thoughts? ------------------------------------------------------------------------ Tue, 13 Sep 2005 14:06:44 +0000 : Junyor FWIW, Opera doesn't support the onbeforeunload event. However, this issue doesn't affect Opera anyway: form contents are retained in history as long as the page isn't closed. IOW, this feature doesn't work in Opera, but it isn't needed either. ------------------------------------------------------------------------ Tue, 13 Sep 2005 14:15:56 +0000 : m3avrck Attachment: http://drupal.org/files/issues/formcheck_3.js (1.64 KB) Updated JS styling and JS-killswitch after talking with Unconed on IRC. ------------------------------------------------------------------------ Tue, 13 Sep 2005 14:39:15 +0000 : m3avrck Just to build on Junyor's comment [6] this functionality is built into Opera 8 and it *doesn't* produce any errors. [6] http://drupal.org/#comment-44066 ------------------------------------------------------------------------ Tue, 13 Sep 2005 15:04:37 +0000 : m3avrck Attachment: http://drupal.org/files/issues/drupal_16.patch (2.1 KB) Updated patch to fix possible problem of overwriting onsubmit event handler thanks to Thox on IRC. ------------------------------------------------------------------------ Tue, 13 Sep 2005 15:13:59 +0000 : webchick I tested this and can confirm that it works in *both* versions of Safari that I have access to: 2.0.1 (OS X Tiger) and 1.3 (OS X Panther). So looks like this code goes one better over the Blogger.com stuff, because their stuff doesn't workk in 1.3. Nice job! ;) ------------------------------------------------------------------------ Tue, 13 Sep 2005 15:25:21 +0000 : m3avrck Well I'm gonna set this to commit then. Tested and working on IE, FF, Safari. Doesn't work or break Opera or Konqueror but not needed in these cases. Thox and Unconded have offered thoughts and I've modified code as needed. Doesn't seem like there is anything else left except a commit :) ------------------------------------------------------------------------ Tue, 13 Sep 2005 17:13:48 +0000 : Bèr Kessels In general I dislike the feature. Konqueror somehow dies this, and that is the way it /should/ be. Browsers should take care of this, not the web app. But, since it is only konq. this patch has a good enough additional value :) I would like to see this patch tested with, tinyMCE and HTMLAREA, at least. For I am quite sure this will break these modules so bad that they are near unusable. Which brings me to the next point: using the textarea hook a simple module could take care of this. I would very very much prefer this living in a contrib, or even a core module. Just not "enforced" on me. And the last point: if this is for core, please use that textarea hook too. This is where that hook is for: extending the textareas. ------------------------------------------------------------------------ Tue, 13 Sep 2005 17:32:25 +0000 : m3avrck Attachment: http://drupal.org/files/issues/drupal_18.patch (2.23 KB) Updated patch after talking with Thox and Uncloned to attach this event only to forms with a specific class (hence avoiding the problem of being on an edit page with other admin/search forms). ------------------------------------------------------------------------ Tue, 13 Sep 2005 17:32:55 +0000 : m3avrck Attachment: http://drupal.org/files/issues/formcheck_4.js (1.67 KB) Updated JS file. ------------------------------------------------------------------------ Tue, 13 Sep 2005 17:45:21 +0000 : m3avrck Berkes, this patch *does not* break TinyMCE, just tried. However, TinyMCE does not take into account this script. This should be an easy patch to TinyMCE. Also, this doesn't affect just textareas, it affects all fields within a given form (e.g., text fields, check boxes, etc...). Sure the blunt of editing/creating a node is in the textarea, but there are still all of those other changes that can be made (new title, revision status, front page promotion, etc...) so this needs to account for them all which it does. This script is unobtrusive and degrades perfectly well. It is tested and working in FF, IE, Safari and doens't cause problems in Opera or Konqueror which don't need this feature anyways (since they already have it). The usability boost of this script is too enormous *not* to include in core. As a contributed module, it is really too flaky, and along those lines, autocomplete.js, inlineuploads.js and related should be in their own contributed modules :) I do see your points and I hope this clears it up. It doesn't cause any problems and only attaches to specified forms, and is off by default. Any module can easily make use of this script when they use: form(..., TRUE). This is the same behavior as the other JS files included with HEAD as well. Once this is in core I'll work on a patch to TinyMCE to get that up to speed ;-) (and as such, TinyMCE still works fine, no probs/errors/etc, and good reason too if you look at how the code *actually* works ;-)). ------------------------------------------------------------------------ Tue, 13 Sep 2005 17:54:37 +0000 : Bèr Kessels I see. the "why" for not using form textarea is perfectly valid. And I tried to explain that, eventough I feel this belongs in the Agent, it is a usability enhancement for all the others using sillier browsers ;). And you are right about that part of contributions, exp since you cannot use hook_texarea, having this in a contrib cannot be achieved. I hereby retract my hesitations. (though I have no time to reapply the latest patch and test it on konq. The last JS updates broke drupal on konq, which Steven fixed, right away though!) ------------------------------------------------------------------------ Thu, 15 Sep 2005 16:31:11 +0000 : m3avrck Ready to go! ------------------------------------------------------------------------ Thu, 15 Sep 2005 20:50:06 +0000 : nedjo Attachment: http://drupal.org/files/issues/formcheck.patch (1.37 KB) Nice work m3avrck. I've made some tweaks to minimize code additions on the PHP side and improve the js. Mainly, it's now enough to set the 'formcheck' class attribute for a form. function form() will add the js file, and the needed onsubmit event will be added dynamically to forms. This is consistent with other core js files, which don't hard-code event calls but add them dynamically, based on js support. The useful functionality is unchanged. ------------------------------------------------------------------------ Thu, 15 Sep 2005 20:50:44 +0000 : nedjo Attachment: http://drupal.org/files/issues/formcheck_5.js (2.12 KB) The revised js file. ------------------------------------------------------------------------ Thu, 15 Sep 2005 22:52:08 +0000 : m3avrck Attachment: http://drupal.org/files/issues/drupal_19.patch (1.56 KB) nedjo, nice! However, the addSubmitEvent does not actually set the variable true, does not work in any browser I tried, already looked into this issue. After some research I found out that Blogger.com actually sets this variable in the form element as I did. I have updated the patch to reflect this, while still incorporating all of your changes. Code is sexy and sleek, ready for commit ;-) ------------------------------------------------------------------------ Thu, 15 Sep 2005 22:52:39 +0000 : m3avrck Attachment: http://drupal.org/files/issues/formcheck_6.js (1.78 KB) And the new JS with the attach event taken out. ------------------------------------------------------------------------ Thu, 15 Sep 2005 22:59:43 +0000 : m3avrck Attachment: http://drupal.org/files/issues/drupal_19_0.patch (1.59 KB) Fixed tab issue with patch. ------------------------------------------------------------------------ Fri, 16 Sep 2005 04:58:13 +0000 : nedjo Attachment: http://drupal.org/files/issues/formcheck_7.js (2.12 KB) Thanks for noting that it wasn't working. The problem isn't using autoattach, it's just that I'd sloppily put formcheckIsSubmit = false in the attached function instead of formcheckIsSubmit = true. Here's the fixed js to go with update #30, using the autoattach behaviour.

1 0

[drupal-devel] [feature] Enable customizing of "Title" field on node forms
by fago 16 Sep '05

16 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: fago Status: patch (ready to be committed) Attachment: http://drupal.org/files/issues/nodetitle-updated.patch (7.05 KB) i've updated node_validate_title() as thox suggested and added a title "question" to the poll.module, as there was no title field for it. fago 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. ------------------------------------------------------------------------ Mon, 12 Sep 2005 15:42:30 +0000 : Robrecht Jacques 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). ------------------------------------------------------------------------ Tue, 13 Sep 2005 13:59:39 +0000 : fago +1 for this functionality i've tested the patch and it looks nice, however node_validate_title() produces an validation error, where the field is called title, which isn't suitable if the modules changes the name, as the forum.module does. ------------------------------------------------------------------------ Tue, 13 Sep 2005 15:50:15 +0000 : Thox Perhaps node_validate_title() should be passed the name of the field? 'Title' by default.

1 0

[drupal-devel] [bug] Menu.inc array_merge error
by Thox 16 Sep '05

16 Sep '05

Issue status update for http://drupal.org/node/31306 Post a follow up: http://drupal.org/project/comments/add/31306 Project: Drupal Version: cvs Component: menu system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: Thox Updated by: Thox Status: patch (code needs review) Attachment: http://drupal.org/files/issues/menu.inc_3.patch (801 bytes) On a PHP 5 system, enabling comments and visiting a comment adding screen causes an array_merge error for me. The patch included prevents this from happening on my system. Thox

5 9

[drupal-devel] [feature] Prevent accidentally navigating away from pages where content has changed
by nedjo 16 Sep '05

16 Sep '05

Issue status update for http://drupal.org/node/30220 Post a follow up: http://drupal.org/project/comments/add/30220 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: m3avrck Updated by: nedjo Status: patch (ready to be committed) Attachment: http://drupal.org/files/issues/formcheck_7.js (2.12 KB) Thanks for noting that it wasn't working. The problem isn't using autoattach, it's just that I'd sloppily put formcheckIsSubmit = false in the attached function instead of formcheckIsSubmit = true. Here's the fixed js to go with update #30, using the autoattach behaviour. nedjo Previous comments: ------------------------------------------------------------------------ Thu, 01 Sep 2005 22:47:42 +0000 : m3avrck How many times have you been posting a comment or working on a new post when you click on a link in another application and you navigate away from the content you are editing, losing all of your changes? Well I say we introduce a script, much similiar to that of Blogger, that uses the Javascript window.onbeforeunload handler to prevent this from happening. We can set this handler to call a function that compares the contents of all forms when the page loads and then quickly compares that to the current contents just before the user is about to leave the page. If they have changed, we should prompt the user so they don't lose their work. This would save many headaches and degrade nicely for users without Javascript. Additionally, this script should work with the newly introduced JS-based upload feature to prevent navigating away as a file is being uploaded as well. If I have sometime I'll start work on a patch tomorrow, just wanted to get the idea into the queue right now :) ------------------------------------------------------------------------ Sat, 10 Sep 2005 23:48:33 +0000 : StuartDH Sounds like a great feature to me. We regularly get authors and editors telling us that they've lost the last hour of work by accidentally navigating away, and I've even just had one of them email me about it a few minutes ago, so it'd be great if you could put something together for this. Cheers ------------------------------------------------------------------------ Mon, 12 Sep 2005 14:33:58 +0000 : MichelleC Sounds great to me, too. I often have several tabs open doing stuff and it's easy to lose my place and leave a page with unfinished edits. Would this alert you when you're going to close an unsaved tab/window as well? Michelle ------------------------------------------------------------------------ Mon, 12 Sep 2005 14:34:19 +0000 : MrMattles Great for us multitaskers that rush and click the wrong thing ------------------------------------------------------------------------ Mon, 12 Sep 2005 14:36:52 +0000 : chx Very strong -1 as this is IE only. ------------------------------------------------------------------------ Mon, 12 Sep 2005 14:38:40 +0000 : praseodymium Konqueror already does this, +1 for the idea in general. ------------------------------------------------------------------------ Mon, 12 Sep 2005 15:07:21 +0000 : webchick Yeah, I think chx is correc that onbeforeunload is an extension developed by MS [1] (it's not in the ECMAScript specification [2]. However, I found out that this is implemented in Mozilla since 1.7 [3] (which corresponds to Firefox 1.0, I think?) and I've tested Blogger.com's version of this functionality in: Firefox 1.0.6 (working) Firefox Deer Park Alpha 1 (working) Opera 8.0.2 (working) Safari 1.3 (does NOT work) Safari 2.0.1 (working) So it seems to be a 'de facto' standard if nothing else. [1] http://msdn.microsoft.com/workshop/author/dhtml/reference/events/onbeforeun… [2] http://www.ecma-international.org/publications/standards/Ecma-262.htm [3] http://www.mozilla.org/status/2004-03-01.html ------------------------------------------------------------------------ Mon, 12 Sep 2005 15:09:15 +0000 : webchick Also, I should clarify... that "does NOT work" in Safari doesn't display any errors or anything, it just doesn't save the form results as expected (so pre-Tiger Safari users are going to be used to this). So I don't see any harm in including this functionality since it seems to degrade gracefully in non-supporting browsers. ------------------------------------------------------------------------ Mon, 12 Sep 2005 21:10:18 +0000 : m3avrck Attachment: http://drupal.org/files/issues/node.module_11.patch (951 bytes) And a patch is ready! Code was based on many example, including this [4] and this [5] along with adding my own thoughts and what not ;) [4] http://www.codestore.org/store.nsf/cmnts/451FA051398A9AF486256EE0000FB7D1?O… [5] http://www.blogger.com/app/scripts/formcheck.js ------------------------------------------------------------------------ Mon, 12 Sep 2005 21:10:45 +0000 : m3avrck Attachment: http://drupal.org/files/issues/formcheck.js (1.54 KB) And here is the JS to throw in misc/. ------------------------------------------------------------------------ Mon, 12 Sep 2005 21:22:56 +0000 : m3avrck Attachment: http://drupal.org/files/issues/formcheck_0.js (1.61 KB) Better JS file attached without tabs. Also, tested and working great in FF and IE6. Doesn't work in Opera 8, however no errors are present, I believe this is just because the event handler is not supported. If there is a work around for Opera, please let me know! ------------------------------------------------------------------------ Mon, 12 Sep 2005 21:24:18 +0000 : m3avrck Attachment: http://drupal.org/files/issues/formcheck_1.js (1.61 KB) One more try with those tabs. ------------------------------------------------------------------------ Mon, 12 Sep 2005 21:32:48 +0000 : moshe weitzman hmmm. i usually find these prompts annoying. any chance we can attach the behavior only to the node and comment forms? those are the "high risk" areas. what do others think? ------------------------------------------------------------------------ Mon, 12 Sep 2005 21:42:39 +0000 : m3avrck Yes, the JS is only loaded on the node edit/create pages, won't affect any admin/login/etc form. Also, the prompt is unobstrusive and if you goto save a node you don't get a warning that the contents have changed because you are explicity saving the node (hence no reason!). ------------------------------------------------------------------------ Mon, 12 Sep 2005 21:53:01 +0000 : Dries I want some JS-folks to review the code. ------------------------------------------------------------------------ Mon, 12 Sep 2005 22:09:10 +0000 : m3avrck Attachment: http://drupal.org/files/issues/drupal_15.patch (1.94 KB) After talking with Drumm on IRC, this patch makes the integration with Drupal much simpler and it's off by default. Only turned on for the node edit/change page right now but any module/form can easily add this by passing a 'TRUE' parameter. ------------------------------------------------------------------------ Mon, 12 Sep 2005 23:38:35 +0000 : nedjo +1 on idea, js looks generally good, a few suggestions: 1. Instead of writing onsubmit via PHP, use a js addLoadEvent call. 2. Shouldn't the return false in isElementChanged be at the end (outside the switch block)? 3. It's be nice to find a way to make messages like 'You have unsaved changes.' translatable. Pass in global js variables via a t('') call? 4. onbeforeunload event should probably be in a if isJsEnabled test, and should parallel drupal.js's event adding (see addLoadEvent). 5. Comments should be in standard format and in present tense, e.g., /** * Checks to see if a form has been changed after the page loads */ 6. e_ should be just e to match other js files, e.g., autocomplete. ------------------------------------------------------------------------ Tue, 13 Sep 2005 13:54:35 +0000 : m3avrck Attachment: http://drupal.org/files/issues/formcheck_2.js (1.58 KB) Ok here is an updated JS file. A few notes, I couldn't get the addSubmitEvent() in drupa.js to reliably work so I had to set the isSubmit() true in the PHP creation of the form. If you look at Blogger.com, they do this as well... so either we both missed an obvious way to do this, or that is the most practical. Hopefully some wise JS gurus will chime in with an answer. Same goes for onbeforeunload event, which is completely different then addEvent defined in drupal.js. As for the t('') I agree this would be useful but I'm not sure of the best way to do this. One way would be to put in form() a t('') passed in, and then write this to a var in formcheck.php which returns a JS file type. Thoughts? ------------------------------------------------------------------------ Tue, 13 Sep 2005 14:06:44 +0000 : Junyor FWIW, Opera doesn't support the onbeforeunload event. However, this issue doesn't affect Opera anyway: form contents are retained in history as long as the page isn't closed. IOW, this feature doesn't work in Opera, but it isn't needed either. ------------------------------------------------------------------------ Tue, 13 Sep 2005 14:15:56 +0000 : m3avrck Attachment: http://drupal.org/files/issues/formcheck_3.js (1.64 KB) Updated JS styling and JS-killswitch after talking with Unconed on IRC. ------------------------------------------------------------------------ Tue, 13 Sep 2005 14:39:15 +0000 : m3avrck Just to build on Junyor's comment [6] this functionality is built into Opera 8 and it *doesn't* produce any errors. [6] http://drupal.org/#comment-44066 ------------------------------------------------------------------------ Tue, 13 Sep 2005 15:04:37 +0000 : m3avrck Attachment: http://drupal.org/files/issues/drupal_16.patch (2.1 KB) Updated patch to fix possible problem of overwriting onsubmit event handler thanks to Thox on IRC. ------------------------------------------------------------------------ Tue, 13 Sep 2005 15:13:59 +0000 : webchick I tested this and can confirm that it works in *both* versions of Safari that I have access to: 2.0.1 (OS X Tiger) and 1.3 (OS X Panther). So looks like this code goes one better over the Blogger.com stuff, because their stuff doesn't workk in 1.3. Nice job! ;) ------------------------------------------------------------------------ Tue, 13 Sep 2005 15:25:21 +0000 : m3avrck Well I'm gonna set this to commit then. Tested and working on IE, FF, Safari. Doesn't work or break Opera or Konqueror but not needed in these cases. Thox and Unconded have offered thoughts and I've modified code as needed. Doesn't seem like there is anything else left except a commit :) ------------------------------------------------------------------------ Tue, 13 Sep 2005 17:13:48 +0000 : Bèr Kessels In general I dislike the feature. Konqueror somehow dies this, and that is the way it /should/ be. Browsers should take care of this, not the web app. But, since it is only konq. this patch has a good enough additional value :) I would like to see this patch tested with, tinyMCE and HTMLAREA, at least. For I am quite sure this will break these modules so bad that they are near unusable. Which brings me to the next point: using the textarea hook a simple module could take care of this. I would very very much prefer this living in a contrib, or even a core module. Just not "enforced" on me. And the last point: if this is for core, please use that textarea hook too. This is where that hook is for: extending the textareas. ------------------------------------------------------------------------ Tue, 13 Sep 2005 17:32:25 +0000 : m3avrck Attachment: http://drupal.org/files/issues/drupal_18.patch (2.23 KB) Updated patch after talking with Thox and Uncloned to attach this event only to forms with a specific class (hence avoiding the problem of being on an edit page with other admin/search forms). ------------------------------------------------------------------------ Tue, 13 Sep 2005 17:32:55 +0000 : m3avrck Attachment: http://drupal.org/files/issues/formcheck_4.js (1.67 KB) Updated JS file. ------------------------------------------------------------------------ Tue, 13 Sep 2005 17:45:21 +0000 : m3avrck Berkes, this patch *does not* break TinyMCE, just tried. However, TinyMCE does not take into account this script. This should be an easy patch to TinyMCE. Also, this doesn't affect just textareas, it affects all fields within a given form (e.g., text fields, check boxes, etc...). Sure the blunt of editing/creating a node is in the textarea, but there are still all of those other changes that can be made (new title, revision status, front page promotion, etc...) so this needs to account for them all which it does. This script is unobtrusive and degrades perfectly well. It is tested and working in FF, IE, Safari and doens't cause problems in Opera or Konqueror which don't need this feature anyways (since they already have it). The usability boost of this script is too enormous *not* to include in core. As a contributed module, it is really too flaky, and along those lines, autocomplete.js, inlineuploads.js and related should be in their own contributed modules :) I do see your points and I hope this clears it up. It doesn't cause any problems and only attaches to specified forms, and is off by default. Any module can easily make use of this script when they use: form(..., TRUE). This is the same behavior as the other JS files included with HEAD as well. Once this is in core I'll work on a patch to TinyMCE to get that up to speed ;-) (and as such, TinyMCE still works fine, no probs/errors/etc, and good reason too if you look at how the code *actually* works ;-)). ------------------------------------------------------------------------ Tue, 13 Sep 2005 17:54:37 +0000 : Bèr Kessels I see. the "why" for not using form textarea is perfectly valid. And I tried to explain that, eventough I feel this belongs in the Agent, it is a usability enhancement for all the others using sillier browsers ;). And you are right about that part of contributions, exp since you cannot use hook_texarea, having this in a contrib cannot be achieved. I hereby retract my hesitations. (though I have no time to reapply the latest patch and test it on konq. The last JS updates broke drupal on konq, which Steven fixed, right away though!) ------------------------------------------------------------------------ Thu, 15 Sep 2005 16:31:11 +0000 : m3avrck Ready to go! ------------------------------------------------------------------------ Thu, 15 Sep 2005 20:50:06 +0000 : nedjo Attachment: http://drupal.org/files/issues/formcheck.patch (1.37 KB) Nice work m3avrck. I've made some tweaks to minimize code additions on the PHP side and improve the js. Mainly, it's now enough to set the 'formcheck' class attribute for a form. function form() will add the js file, and the needed onsubmit event will be added dynamically to forms. This is consistent with other core js files, which don't hard-code event calls but add them dynamically, based on js support. The useful functionality is unchanged. ------------------------------------------------------------------------ Thu, 15 Sep 2005 20:50:44 +0000 : nedjo Attachment: http://drupal.org/files/issues/formcheck_5.js (2.12 KB) The revised js file. ------------------------------------------------------------------------ Thu, 15 Sep 2005 22:52:08 +0000 : m3avrck Attachment: http://drupal.org/files/issues/drupal_19.patch (1.56 KB) nedjo, nice! However, the addSubmitEvent does not actually set the variable true, does not work in any browser I tried, already looked into this issue. After some research I found out that Blogger.com actually sets this variable in the form element as I did. I have updated the patch to reflect this, while still incorporating all of your changes. Code is sexy and sleek, ready for commit ;-) ------------------------------------------------------------------------ Thu, 15 Sep 2005 22:52:39 +0000 : m3avrck Attachment: http://drupal.org/files/issues/formcheck_6.js (1.78 KB) And the new JS with the attach event taken out. ------------------------------------------------------------------------ Thu, 15 Sep 2005 22:59:43 +0000 : m3avrck Attachment: http://drupal.org/files/issues/drupal_19_0.patch (1.59 KB) Fixed tab issue with patch.

1 0

[drupal-devel] [feature] Admin option to toggle between headline, teaser, and full text in RSS feeds
by walkah 16 Sep '05

16 Sep '05

Issue status update for http://drupal.org/node/3986 Post a follow up: http://drupal.org/project/comments/add/3986 Project: Drupal Version: cvs Component: node.module Category: feature requests Priority: critical Assigned to: walkah Reported by: Boris Mann Updated by: walkah Status: patch (code needs review) Attachment: http://drupal.org/files/issues/feeds_1.patch (10.27 KB) ARGH! sorry for the spam, but nobody's gonna like array_merge'ing an array and a string. *sigh* last one i promise. walkah Previous comments: ------------------------------------------------------------------------ Fri, 07 Nov 2003 00:22:51 +0000 : Boris Mann As the title says. It might be nice to add a feed.module to Drupal that consolidates all feed-related info in one place, so that this can be toggled for different types of nodes all in one place. ------------------------------------------------------------------------ Tue, 14 Jun 2005 23:44:20 +0000 : Boris Mann I love the fact that this has been active forever :P One day we will have a feed.module to rule them all... ------------------------------------------------------------------------ Wed, 14 Sep 2005 14:41:10 +0000 : Boris Mann Attachment: http://drupal.org/files/issues/node_4.module (70.01 KB) What the heck, let's make this critical. Google launched blogsearch [1] today -- it reads feeds, so if you're not outputting full feeds, it means Google's not indexing everything you put out. Attached is an updated node.module which sets options for this, as well as includes an option for RSS or Atom feeds (but doesn't implement this yet). If someone could refactor and turn into a patch, we could still get this into 4.7. [1] http://google.com/blogsearch ------------------------------------------------------------------------ Wed, 14 Sep 2005 14:58:08 +0000 : Dries Would this be your first core patch? ;) ------------------------------------------------------------------------ Wed, 14 Sep 2005 15:21:02 +0000 : Boris Mann It would/will be if I were better at rolling patches against HEAD and didn't stuff so much stuff into it... ...back to non-coding work. ------------------------------------------------------------------------ Wed, 14 Sep 2005 16:00:21 +0000 : walkah Attachment: http://drupal.org/files/issues/node-feed-length.patch (3.95 KB) so, Boris is a wimp... but this is a pretty cool feature. attached is a re-worked patch. all working 'n' stuff. ------------------------------------------------------------------------ Thu, 15 Sep 2005 21:51:34 +0000 : walkah Attachment: http://drupal.org/files/issues/feeds.patch (10.25 KB) at Dries' request - here's an updated patch (where I hereby admit to sneaking in some other things I'd wanted to do). Hopfeully it's worthy to be snuck in at the deadline. (it's even still the 15th in .be for another couple minutes). So this patch does the following: * adds a "feed settings" section to admin/settings where 2 new settings are introduced: * number of items per feed * default length of feed descriptions (title only, teaser, full) * patches all of core to obey the above - including the new aggregator (out) feeds * adds support for adding namespaces in _nodeapi('rss item') - which means things like iTunes RSS and yahoo's media rss can be implemented by the appropriate modules (i.e. audio.module) * includes some additional info in the default node feed - specifically the element (links directly to comments) - and dc:creator - to show node author information. ------------------------------------------------------------------------ Thu, 15 Sep 2005 22:09:43 +0000 : sepeck +1 on the features. This is one of those things that gets mentioned and or requested in the forums enough and I sure would like it. ------------------------------------------------------------------------ Thu, 15 Sep 2005 22:30:51 +0000 : walkah oh yeah, i forgot to mention one other little thing, that I think is nice... if you're using the teaser length (as is the default) it inserts a read more link in the description... which makes it obvious to your readers that there is more to the post :) (and a good way to drive traffic back to your site, i suppose) ------------------------------------------------------------------------ Thu, 15 Sep 2005 23:47:30 +0000 : walkah Attachment: http://drupal.org/files/issues/feeds_0.patch (10.27 KB) d'oh. cleaning up some little boo boos in that last version. should be commit ready now - if i may be so bold ;)

1 0

[drupal-devel] [feature] Admin option to toggle between headline, teaser, and full text in RSS feeds
by walkah 16 Sep '05

16 Sep '05

Issue status update for http://drupal.org/node/3986 Post a follow up: http://drupal.org/project/comments/add/3986 Project: Drupal Version: cvs Component: node.module Category: feature requests Priority: critical -Assigned to: Anonymous +Assigned to: walkah Reported by: Boris Mann Updated by: walkah Status: patch (code needs review) Attachment: http://drupal.org/files/issues/feeds_0.patch (10.27 KB) d'oh. cleaning up some little boo boos in that last version. should be commit ready now - if i may be so bold ;) walkah Previous comments: ------------------------------------------------------------------------ Fri, 07 Nov 2003 00:22:51 +0000 : Boris Mann As the title says. It might be nice to add a feed.module to Drupal that consolidates all feed-related info in one place, so that this can be toggled for different types of nodes all in one place. ------------------------------------------------------------------------ Tue, 14 Jun 2005 23:44:20 +0000 : Boris Mann I love the fact that this has been active forever :P One day we will have a feed.module to rule them all... ------------------------------------------------------------------------ Wed, 14 Sep 2005 14:41:10 +0000 : Boris Mann Attachment: http://drupal.org/files/issues/node_4.module (70.01 KB) What the heck, let's make this critical. Google launched blogsearch [1] today -- it reads feeds, so if you're not outputting full feeds, it means Google's not indexing everything you put out. Attached is an updated node.module which sets options for this, as well as includes an option for RSS or Atom feeds (but doesn't implement this yet). If someone could refactor and turn into a patch, we could still get this into 4.7. [1] http://google.com/blogsearch ------------------------------------------------------------------------ Wed, 14 Sep 2005 14:58:08 +0000 : Dries Would this be your first core patch? ;) ------------------------------------------------------------------------ Wed, 14 Sep 2005 15:21:02 +0000 : Boris Mann It would/will be if I were better at rolling patches against HEAD and didn't stuff so much stuff into it... ...back to non-coding work. ------------------------------------------------------------------------ Wed, 14 Sep 2005 16:00:21 +0000 : walkah Attachment: http://drupal.org/files/issues/node-feed-length.patch (3.95 KB) so, Boris is a wimp... but this is a pretty cool feature. attached is a re-worked patch. all working 'n' stuff. ------------------------------------------------------------------------ Thu, 15 Sep 2005 21:51:34 +0000 : walkah Attachment: http://drupal.org/files/issues/feeds.patch (10.25 KB) at Dries' request - here's an updated patch (where I hereby admit to sneaking in some other things I'd wanted to do). Hopfeully it's worthy to be snuck in at the deadline. (it's even still the 15th in .be for another couple minutes). So this patch does the following: * adds a "feed settings" section to admin/settings where 2 new settings are introduced: * number of items per feed * default length of feed descriptions (title only, teaser, full) * patches all of core to obey the above - including the new aggregator (out) feeds * adds support for adding namespaces in _nodeapi('rss item') - which means things like iTunes RSS and yahoo's media rss can be implemented by the appropriate modules (i.e. audio.module) * includes some additional info in the default node feed - specifically the element (links directly to comments) - and dc:creator - to show node author information. ------------------------------------------------------------------------ Thu, 15 Sep 2005 22:09:43 +0000 : sepeck +1 on the features. This is one of those things that gets mentioned and or requested in the forums enough and I sure would like it. ------------------------------------------------------------------------ Thu, 15 Sep 2005 22:30:51 +0000 : walkah oh yeah, i forgot to mention one other little thing, that I think is nice... if you're using the teaser length (as is the default) it inserts a read more link in the description... which makes it obvious to your readers that there is more to the post :) (and a good way to drive traffic back to your site, i suppose)

1 0

[drupal-devel] [feature] Prevent accidentally navigating away from pages where content has changed
by m3avrck 16 Sep '05

16 Sep '05

Issue status update for http://drupal.org/node/30220 Post a follow up: http://drupal.org/project/comments/add/30220 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: m3avrck Updated by: m3avrck Status: patch (ready to be committed) Attachment: http://drupal.org/files/issues/drupal_19_0.patch (1.59 KB) Fixed tab issue with patch. m3avrck Previous comments: ------------------------------------------------------------------------ Thu, 01 Sep 2005 22:47:42 +0000 : m3avrck How many times have you been posting a comment or working on a new post when you click on a link in another application and you navigate away from the content you are editing, losing all of your changes? Well I say we introduce a script, much similiar to that of Blogger, that uses the Javascript window.onbeforeunload handler to prevent this from happening. We can set this handler to call a function that compares the contents of all forms when the page loads and then quickly compares that to the current contents just before the user is about to leave the page. If they have changed, we should prompt the user so they don't lose their work. This would save many headaches and degrade nicely for users without Javascript. Additionally, this script should work with the newly introduced JS-based upload feature to prevent navigating away as a file is being uploaded as well. If I have sometime I'll start work on a patch tomorrow, just wanted to get the idea into the queue right now :) ------------------------------------------------------------------------ Sat, 10 Sep 2005 23:48:33 +0000 : StuartDH Sounds like a great feature to me. We regularly get authors and editors telling us that they've lost the last hour of work by accidentally navigating away, and I've even just had one of them email me about it a few minutes ago, so it'd be great if you could put something together for this. Cheers ------------------------------------------------------------------------ Mon, 12 Sep 2005 14:33:58 +0000 : MichelleC Sounds great to me, too. I often have several tabs open doing stuff and it's easy to lose my place and leave a page with unfinished edits. Would this alert you when you're going to close an unsaved tab/window as well? Michelle ------------------------------------------------------------------------ Mon, 12 Sep 2005 14:34:19 +0000 : MrMattles Great for us multitaskers that rush and click the wrong thing ------------------------------------------------------------------------ Mon, 12 Sep 2005 14:36:52 +0000 : chx Very strong -1 as this is IE only. ------------------------------------------------------------------------ Mon, 12 Sep 2005 14:38:40 +0000 : praseodymium Konqueror already does this, +1 for the idea in general. ------------------------------------------------------------------------ Mon, 12 Sep 2005 15:07:21 +0000 : webchick Yeah, I think chx is correc that onbeforeunload is an extension developed by MS [1] (it's not in the ECMAScript specification [2]. However, I found out that this is implemented in Mozilla since 1.7 [3] (which corresponds to Firefox 1.0, I think?) and I've tested Blogger.com's version of this functionality in: Firefox 1.0.6 (working) Firefox Deer Park Alpha 1 (working) Opera 8.0.2 (working) Safari 1.3 (does NOT work) Safari 2.0.1 (working) So it seems to be a 'de facto' standard if nothing else. [1] http://msdn.microsoft.com/workshop/author/dhtml/reference/events/onbeforeun… [2] http://www.ecma-international.org/publications/standards/Ecma-262.htm [3] http://www.mozilla.org/status/2004-03-01.html ------------------------------------------------------------------------ Mon, 12 Sep 2005 15:09:15 +0000 : webchick Also, I should clarify... that "does NOT work" in Safari doesn't display any errors or anything, it just doesn't save the form results as expected (so pre-Tiger Safari users are going to be used to this). So I don't see any harm in including this functionality since it seems to degrade gracefully in non-supporting browsers. ------------------------------------------------------------------------ Mon, 12 Sep 2005 21:10:18 +0000 : m3avrck Attachment: http://drupal.org/files/issues/node.module_11.patch (951 bytes) And a patch is ready! Code was based on many example, including this [4] and this [5] along with adding my own thoughts and what not ;) [4] http://www.codestore.org/store.nsf/cmnts/451FA051398A9AF486256EE0000FB7D1?O… [5] http://www.blogger.com/app/scripts/formcheck.js ------------------------------------------------------------------------ Mon, 12 Sep 2005 21:10:45 +0000 : m3avrck Attachment: http://drupal.org/files/issues/formcheck.js (1.54 KB) And here is the JS to throw in misc/. ------------------------------------------------------------------------ Mon, 12 Sep 2005 21:22:56 +0000 : m3avrck Attachment: http://drupal.org/files/issues/formcheck_0.js (1.61 KB) Better JS file attached without tabs. Also, tested and working great in FF and IE6. Doesn't work in Opera 8, however no errors are present, I believe this is just because the event handler is not supported. If there is a work around for Opera, please let me know! ------------------------------------------------------------------------ Mon, 12 Sep 2005 21:24:18 +0000 : m3avrck Attachment: http://drupal.org/files/issues/formcheck_1.js (1.61 KB) One more try with those tabs. ------------------------------------------------------------------------ Mon, 12 Sep 2005 21:32:48 +0000 : moshe weitzman hmmm. i usually find these prompts annoying. any chance we can attach the behavior only to the node and comment forms? those are the "high risk" areas. what do others think? ------------------------------------------------------------------------ Mon, 12 Sep 2005 21:42:39 +0000 : m3avrck Yes, the JS is only loaded on the node edit/create pages, won't affect any admin/login/etc form. Also, the prompt is unobstrusive and if you goto save a node you don't get a warning that the contents have changed because you are explicity saving the node (hence no reason!). ------------------------------------------------------------------------ Mon, 12 Sep 2005 21:53:01 +0000 : Dries I want some JS-folks to review the code. ------------------------------------------------------------------------ Mon, 12 Sep 2005 22:09:10 +0000 : m3avrck Attachment: http://drupal.org/files/issues/drupal_15.patch (1.94 KB) After talking with Drumm on IRC, this patch makes the integration with Drupal much simpler and it's off by default. Only turned on for the node edit/change page right now but any module/form can easily add this by passing a 'TRUE' parameter. ------------------------------------------------------------------------ Mon, 12 Sep 2005 23:38:35 +0000 : nedjo +1 on idea, js looks generally good, a few suggestions: 1. Instead of writing onsubmit via PHP, use a js addLoadEvent call. 2. Shouldn't the return false in isElementChanged be at the end (outside the switch block)? 3. It's be nice to find a way to make messages like 'You have unsaved changes.' translatable. Pass in global js variables via a t('') call? 4. onbeforeunload event should probably be in a if isJsEnabled test, and should parallel drupal.js's event adding (see addLoadEvent). 5. Comments should be in standard format and in present tense, e.g., /** * Checks to see if a form has been changed after the page loads */ 6. e_ should be just e to match other js files, e.g., autocomplete. ------------------------------------------------------------------------ Tue, 13 Sep 2005 13:54:35 +0000 : m3avrck Attachment: http://drupal.org/files/issues/formcheck_2.js (1.58 KB) Ok here is an updated JS file. A few notes, I couldn't get the addSubmitEvent() in drupa.js to reliably work so I had to set the isSubmit() true in the PHP creation of the form. If you look at Blogger.com, they do this as well... so either we both missed an obvious way to do this, or that is the most practical. Hopefully some wise JS gurus will chime in with an answer. Same goes for onbeforeunload event, which is completely different then addEvent defined in drupal.js. As for the t('') I agree this would be useful but I'm not sure of the best way to do this. One way would be to put in form() a t('') passed in, and then write this to a var in formcheck.php which returns a JS file type. Thoughts? ------------------------------------------------------------------------ Tue, 13 Sep 2005 14:06:44 +0000 : Junyor FWIW, Opera doesn't support the onbeforeunload event. However, this issue doesn't affect Opera anyway: form contents are retained in history as long as the page isn't closed. IOW, this feature doesn't work in Opera, but it isn't needed either. ------------------------------------------------------------------------ Tue, 13 Sep 2005 14:15:56 +0000 : m3avrck Attachment: http://drupal.org/files/issues/formcheck_3.js (1.64 KB) Updated JS styling and JS-killswitch after talking with Unconed on IRC. ------------------------------------------------------------------------ Tue, 13 Sep 2005 14:39:15 +0000 : m3avrck Just to build on Junyor's comment [6] this functionality is built into Opera 8 and it *doesn't* produce any errors. [6] http://drupal.org/#comment-44066 ------------------------------------------------------------------------ Tue, 13 Sep 2005 15:04:37 +0000 : m3avrck Attachment: http://drupal.org/files/issues/drupal_16.patch (2.1 KB) Updated patch to fix possible problem of overwriting onsubmit event handler thanks to Thox on IRC. ------------------------------------------------------------------------ Tue, 13 Sep 2005 15:13:59 +0000 : webchick I tested this and can confirm that it works in *both* versions of Safari that I have access to: 2.0.1 (OS X Tiger) and 1.3 (OS X Panther). So looks like this code goes one better over the Blogger.com stuff, because their stuff doesn't workk in 1.3. Nice job! ;) ------------------------------------------------------------------------ Tue, 13 Sep 2005 15:25:21 +0000 : m3avrck Well I'm gonna set this to commit then. Tested and working on IE, FF, Safari. Doesn't work or break Opera or Konqueror but not needed in these cases. Thox and Unconded have offered thoughts and I've modified code as needed. Doesn't seem like there is anything else left except a commit :) ------------------------------------------------------------------------ Tue, 13 Sep 2005 17:13:48 +0000 : Bèr Kessels In general I dislike the feature. Konqueror somehow dies this, and that is the way it /should/ be. Browsers should take care of this, not the web app. But, since it is only konq. this patch has a good enough additional value :) I would like to see this patch tested with, tinyMCE and HTMLAREA, at least. For I am quite sure this will break these modules so bad that they are near unusable. Which brings me to the next point: using the textarea hook a simple module could take care of this. I would very very much prefer this living in a contrib, or even a core module. Just not "enforced" on me. And the last point: if this is for core, please use that textarea hook too. This is where that hook is for: extending the textareas. ------------------------------------------------------------------------ Tue, 13 Sep 2005 17:32:25 +0000 : m3avrck Attachment: http://drupal.org/files/issues/drupal_18.patch (2.23 KB) Updated patch after talking with Thox and Uncloned to attach this event only to forms with a specific class (hence avoiding the problem of being on an edit page with other admin/search forms). ------------------------------------------------------------------------ Tue, 13 Sep 2005 17:32:55 +0000 : m3avrck Attachment: http://drupal.org/files/issues/formcheck_4.js (1.67 KB) Updated JS file. ------------------------------------------------------------------------ Tue, 13 Sep 2005 17:45:21 +0000 : m3avrck Berkes, this patch *does not* break TinyMCE, just tried. However, TinyMCE does not take into account this script. This should be an easy patch to TinyMCE. Also, this doesn't affect just textareas, it affects all fields within a given form (e.g., text fields, check boxes, etc...). Sure the blunt of editing/creating a node is in the textarea, but there are still all of those other changes that can be made (new title, revision status, front page promotion, etc...) so this needs to account for them all which it does. This script is unobtrusive and degrades perfectly well. It is tested and working in FF, IE, Safari and doens't cause problems in Opera or Konqueror which don't need this feature anyways (since they already have it). The usability boost of this script is too enormous *not* to include in core. As a contributed module, it is really too flaky, and along those lines, autocomplete.js, inlineuploads.js and related should be in their own contributed modules :) I do see your points and I hope this clears it up. It doesn't cause any problems and only attaches to specified forms, and is off by default. Any module can easily make use of this script when they use: form(..., TRUE). This is the same behavior as the other JS files included with HEAD as well. Once this is in core I'll work on a patch to TinyMCE to get that up to speed ;-) (and as such, TinyMCE still works fine, no probs/errors/etc, and good reason too if you look at how the code *actually* works ;-)). ------------------------------------------------------------------------ Tue, 13 Sep 2005 17:54:37 +0000 : Bèr Kessels I see. the "why" for not using form textarea is perfectly valid. And I tried to explain that, eventough I feel this belongs in the Agent, it is a usability enhancement for all the others using sillier browsers ;). And you are right about that part of contributions, exp since you cannot use hook_texarea, having this in a contrib cannot be achieved. I hereby retract my hesitations. (though I have no time to reapply the latest patch and test it on konq. The last JS updates broke drupal on konq, which Steven fixed, right away though!) ------------------------------------------------------------------------ Thu, 15 Sep 2005 16:31:11 +0000 : m3avrck Ready to go! ------------------------------------------------------------------------ Thu, 15 Sep 2005 20:50:06 +0000 : nedjo Attachment: http://drupal.org/files/issues/formcheck.patch (1.37 KB) Nice work m3avrck. I've made some tweaks to minimize code additions on the PHP side and improve the js. Mainly, it's now enough to set the 'formcheck' class attribute for a form. function form() will add the js file, and the needed onsubmit event will be added dynamically to forms. This is consistent with other core js files, which don't hard-code event calls but add them dynamically, based on js support. The useful functionality is unchanged. ------------------------------------------------------------------------ Thu, 15 Sep 2005 20:50:44 +0000 : nedjo Attachment: http://drupal.org/files/issues/formcheck_5.js (2.12 KB) The revised js file. ------------------------------------------------------------------------ Thu, 15 Sep 2005 22:52:08 +0000 : m3avrck Attachment: http://drupal.org/files/issues/drupal_19.patch (1.56 KB) nedjo, nice! However, the addSubmitEvent does not actually set the variable true, does not work in any browser I tried, already looked into this issue. After some research I found out that Blogger.com actually sets this variable in the form element as I did. I have updated the patch to reflect this, while still incorporating all of your changes. Code is sexy and sleek, ready for commit ;-) ------------------------------------------------------------------------ Thu, 15 Sep 2005 22:52:39 +0000 : m3avrck Attachment: http://drupal.org/files/issues/formcheck_6.js (1.78 KB) And the new JS with the attach event taken out.

1 0

[drupal-devel] [feature] Prevent accidentally navigating away from pages where content has changed
by m3avrck 16 Sep '05

16 Sep '05

Issue status update for http://drupal.org/node/30220 Post a follow up: http://drupal.org/project/comments/add/30220 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: m3avrck Updated by: m3avrck -Status: patch (code needs review) +Status: patch (ready to be committed) Attachment: http://drupal.org/files/issues/formcheck_6.js (1.78 KB) And the new JS with the attach event taken out. m3avrck Previous comments: ------------------------------------------------------------------------ Thu, 01 Sep 2005 22:47:42 +0000 : m3avrck How many times have you been posting a comment or working on a new post when you click on a link in another application and you navigate away from the content you are editing, losing all of your changes? Well I say we introduce a script, much similiar to that of Blogger, that uses the Javascript window.onbeforeunload handler to prevent this from happening. We can set this handler to call a function that compares the contents of all forms when the page loads and then quickly compares that to the current contents just before the user is about to leave the page. If they have changed, we should prompt the user so they don't lose their work. This would save many headaches and degrade nicely for users without Javascript. Additionally, this script should work with the newly introduced JS-based upload feature to prevent navigating away as a file is being uploaded as well. If I have sometime I'll start work on a patch tomorrow, just wanted to get the idea into the queue right now :) ------------------------------------------------------------------------ Sat, 10 Sep 2005 23:48:33 +0000 : StuartDH Sounds like a great feature to me. We regularly get authors and editors telling us that they've lost the last hour of work by accidentally navigating away, and I've even just had one of them email me about it a few minutes ago, so it'd be great if you could put something together for this. Cheers ------------------------------------------------------------------------ Mon, 12 Sep 2005 14:33:58 +0000 : MichelleC Sounds great to me, too. I often have several tabs open doing stuff and it's easy to lose my place and leave a page with unfinished edits. Would this alert you when you're going to close an unsaved tab/window as well? Michelle ------------------------------------------------------------------------ Mon, 12 Sep 2005 14:34:19 +0000 : MrMattles Great for us multitaskers that rush and click the wrong thing ------------------------------------------------------------------------ Mon, 12 Sep 2005 14:36:52 +0000 : chx Very strong -1 as this is IE only. ------------------------------------------------------------------------ Mon, 12 Sep 2005 14:38:40 +0000 : praseodymium Konqueror already does this, +1 for the idea in general. ------------------------------------------------------------------------ Mon, 12 Sep 2005 15:07:21 +0000 : webchick Yeah, I think chx is correc that onbeforeunload is an extension developed by MS [1] (it's not in the ECMAScript specification [2]. However, I found out that this is implemented in Mozilla since 1.7 [3] (which corresponds to Firefox 1.0, I think?) and I've tested Blogger.com's version of this functionality in: Firefox 1.0.6 (working) Firefox Deer Park Alpha 1 (working) Opera 8.0.2 (working) Safari 1.3 (does NOT work) Safari 2.0.1 (working) So it seems to be a 'de facto' standard if nothing else. [1] http://msdn.microsoft.com/workshop/author/dhtml/reference/events/onbeforeun… [2] http://www.ecma-international.org/publications/standards/Ecma-262.htm [3] http://www.mozilla.org/status/2004-03-01.html ------------------------------------------------------------------------ Mon, 12 Sep 2005 15:09:15 +0000 : webchick Also, I should clarify... that "does NOT work" in Safari doesn't display any errors or anything, it just doesn't save the form results as expected (so pre-Tiger Safari users are going to be used to this). So I don't see any harm in including this functionality since it seems to degrade gracefully in non-supporting browsers. ------------------------------------------------------------------------ Mon, 12 Sep 2005 21:10:18 +0000 : m3avrck Attachment: http://drupal.org/files/issues/node.module_11.patch (951 bytes) And a patch is ready! Code was based on many example, including this [4] and this [5] along with adding my own thoughts and what not ;) [4] http://www.codestore.org/store.nsf/cmnts/451FA051398A9AF486256EE0000FB7D1?O… [5] http://www.blogger.com/app/scripts/formcheck.js ------------------------------------------------------------------------ Mon, 12 Sep 2005 21:10:45 +0000 : m3avrck Attachment: http://drupal.org/files/issues/formcheck.js (1.54 KB) And here is the JS to throw in misc/. ------------------------------------------------------------------------ Mon, 12 Sep 2005 21:22:56 +0000 : m3avrck Attachment: http://drupal.org/files/issues/formcheck_0.js (1.61 KB) Better JS file attached without tabs. Also, tested and working great in FF and IE6. Doesn't work in Opera 8, however no errors are present, I believe this is just because the event handler is not supported. If there is a work around for Opera, please let me know! ------------------------------------------------------------------------ Mon, 12 Sep 2005 21:24:18 +0000 : m3avrck Attachment: http://drupal.org/files/issues/formcheck_1.js (1.61 KB) One more try with those tabs. ------------------------------------------------------------------------ Mon, 12 Sep 2005 21:32:48 +0000 : moshe weitzman hmmm. i usually find these prompts annoying. any chance we can attach the behavior only to the node and comment forms? those are the "high risk" areas. what do others think? ------------------------------------------------------------------------ Mon, 12 Sep 2005 21:42:39 +0000 : m3avrck Yes, the JS is only loaded on the node edit/create pages, won't affect any admin/login/etc form. Also, the prompt is unobstrusive and if you goto save a node you don't get a warning that the contents have changed because you are explicity saving the node (hence no reason!). ------------------------------------------------------------------------ Mon, 12 Sep 2005 21:53:01 +0000 : Dries I want some JS-folks to review the code. ------------------------------------------------------------------------ Mon, 12 Sep 2005 22:09:10 +0000 : m3avrck Attachment: http://drupal.org/files/issues/drupal_15.patch (1.94 KB) After talking with Drumm on IRC, this patch makes the integration with Drupal much simpler and it's off by default. Only turned on for the node edit/change page right now but any module/form can easily add this by passing a 'TRUE' parameter. ------------------------------------------------------------------------ Mon, 12 Sep 2005 23:38:35 +0000 : nedjo +1 on idea, js looks generally good, a few suggestions: 1. Instead of writing onsubmit via PHP, use a js addLoadEvent call. 2. Shouldn't the return false in isElementChanged be at the end (outside the switch block)? 3. It's be nice to find a way to make messages like 'You have unsaved changes.' translatable. Pass in global js variables via a t('') call? 4. onbeforeunload event should probably be in a if isJsEnabled test, and should parallel drupal.js's event adding (see addLoadEvent). 5. Comments should be in standard format and in present tense, e.g., /** * Checks to see if a form has been changed after the page loads */ 6. e_ should be just e to match other js files, e.g., autocomplete. ------------------------------------------------------------------------ Tue, 13 Sep 2005 13:54:35 +0000 : m3avrck Attachment: http://drupal.org/files/issues/formcheck_2.js (1.58 KB) Ok here is an updated JS file. A few notes, I couldn't get the addSubmitEvent() in drupa.js to reliably work so I had to set the isSubmit() true in the PHP creation of the form. If you look at Blogger.com, they do this as well... so either we both missed an obvious way to do this, or that is the most practical. Hopefully some wise JS gurus will chime in with an answer. Same goes for onbeforeunload event, which is completely different then addEvent defined in drupal.js. As for the t('') I agree this would be useful but I'm not sure of the best way to do this. One way would be to put in form() a t('') passed in, and then write this to a var in formcheck.php which returns a JS file type. Thoughts? ------------------------------------------------------------------------ Tue, 13 Sep 2005 14:06:44 +0000 : Junyor FWIW, Opera doesn't support the onbeforeunload event. However, this issue doesn't affect Opera anyway: form contents are retained in history as long as the page isn't closed. IOW, this feature doesn't work in Opera, but it isn't needed either. ------------------------------------------------------------------------ Tue, 13 Sep 2005 14:15:56 +0000 : m3avrck Attachment: http://drupal.org/files/issues/formcheck_3.js (1.64 KB) Updated JS styling and JS-killswitch after talking with Unconed on IRC. ------------------------------------------------------------------------ Tue, 13 Sep 2005 14:39:15 +0000 : m3avrck Just to build on Junyor's comment [6] this functionality is built into Opera 8 and it *doesn't* produce any errors. [6] http://drupal.org/#comment-44066 ------------------------------------------------------------------------ Tue, 13 Sep 2005 15:04:37 +0000 : m3avrck Attachment: http://drupal.org/files/issues/drupal_16.patch (2.1 KB) Updated patch to fix possible problem of overwriting onsubmit event handler thanks to Thox on IRC. ------------------------------------------------------------------------ Tue, 13 Sep 2005 15:13:59 +0000 : webchick I tested this and can confirm that it works in *both* versions of Safari that I have access to: 2.0.1 (OS X Tiger) and 1.3 (OS X Panther). So looks like this code goes one better over the Blogger.com stuff, because their stuff doesn't workk in 1.3. Nice job! ;) ------------------------------------------------------------------------ Tue, 13 Sep 2005 15:25:21 +0000 : m3avrck Well I'm gonna set this to commit then. Tested and working on IE, FF, Safari. Doesn't work or break Opera or Konqueror but not needed in these cases. Thox and Unconded have offered thoughts and I've modified code as needed. Doesn't seem like there is anything else left except a commit :) ------------------------------------------------------------------------ Tue, 13 Sep 2005 17:13:48 +0000 : Bèr Kessels In general I dislike the feature. Konqueror somehow dies this, and that is the way it /should/ be. Browsers should take care of this, not the web app. But, since it is only konq. this patch has a good enough additional value :) I would like to see this patch tested with, tinyMCE and HTMLAREA, at least. For I am quite sure this will break these modules so bad that they are near unusable. Which brings me to the next point: using the textarea hook a simple module could take care of this. I would very very much prefer this living in a contrib, or even a core module. Just not "enforced" on me. And the last point: if this is for core, please use that textarea hook too. This is where that hook is for: extending the textareas. ------------------------------------------------------------------------ Tue, 13 Sep 2005 17:32:25 +0000 : m3avrck Attachment: http://drupal.org/files/issues/drupal_18.patch (2.23 KB) Updated patch after talking with Thox and Uncloned to attach this event only to forms with a specific class (hence avoiding the problem of being on an edit page with other admin/search forms). ------------------------------------------------------------------------ Tue, 13 Sep 2005 17:32:55 +0000 : m3avrck Attachment: http://drupal.org/files/issues/formcheck_4.js (1.67 KB) Updated JS file. ------------------------------------------------------------------------ Tue, 13 Sep 2005 17:45:21 +0000 : m3avrck Berkes, this patch *does not* break TinyMCE, just tried. However, TinyMCE does not take into account this script. This should be an easy patch to TinyMCE. Also, this doesn't affect just textareas, it affects all fields within a given form (e.g., text fields, check boxes, etc...). Sure the blunt of editing/creating a node is in the textarea, but there are still all of those other changes that can be made (new title, revision status, front page promotion, etc...) so this needs to account for them all which it does. This script is unobtrusive and degrades perfectly well. It is tested and working in FF, IE, Safari and doens't cause problems in Opera or Konqueror which don't need this feature anyways (since they already have it). The usability boost of this script is too enormous *not* to include in core. As a contributed module, it is really too flaky, and along those lines, autocomplete.js, inlineuploads.js and related should be in their own contributed modules :) I do see your points and I hope this clears it up. It doesn't cause any problems and only attaches to specified forms, and is off by default. Any module can easily make use of this script when they use: form(..., TRUE). This is the same behavior as the other JS files included with HEAD as well. Once this is in core I'll work on a patch to TinyMCE to get that up to speed ;-) (and as such, TinyMCE still works fine, no probs/errors/etc, and good reason too if you look at how the code *actually* works ;-)). ------------------------------------------------------------------------ Tue, 13 Sep 2005 17:54:37 +0000 : Bèr Kessels I see. the "why" for not using form textarea is perfectly valid. And I tried to explain that, eventough I feel this belongs in the Agent, it is a usability enhancement for all the others using sillier browsers ;). And you are right about that part of contributions, exp since you cannot use hook_texarea, having this in a contrib cannot be achieved. I hereby retract my hesitations. (though I have no time to reapply the latest patch and test it on konq. The last JS updates broke drupal on konq, which Steven fixed, right away though!) ------------------------------------------------------------------------ Thu, 15 Sep 2005 16:31:11 +0000 : m3avrck Ready to go! ------------------------------------------------------------------------ Thu, 15 Sep 2005 20:50:06 +0000 : nedjo Attachment: http://drupal.org/files/issues/formcheck.patch (1.37 KB) Nice work m3avrck. I've made some tweaks to minimize code additions on the PHP side and improve the js. Mainly, it's now enough to set the 'formcheck' class attribute for a form. function form() will add the js file, and the needed onsubmit event will be added dynamically to forms. This is consistent with other core js files, which don't hard-code event calls but add them dynamically, based on js support. The useful functionality is unchanged. ------------------------------------------------------------------------ Thu, 15 Sep 2005 20:50:44 +0000 : nedjo Attachment: http://drupal.org/files/issues/formcheck_5.js (2.12 KB) The revised js file. ------------------------------------------------------------------------ Thu, 15 Sep 2005 22:52:08 +0000 : m3avrck Attachment: http://drupal.org/files/issues/drupal_19.patch (1.56 KB) nedjo, nice! However, the addSubmitEvent does not actually set the variable true, does not work in any browser I tried, already looked into this issue. After some research I found out that Blogger.com actually sets this variable in the form element as I did. I have updated the patch to reflect this, while still incorporating all of your changes. Code is sexy and sleek, ready for commit ;-)

1 0

[drupal-devel] [feature] Prevent accidentally navigating away from pages where content has changed
by m3avrck 16 Sep '05

16 Sep '05

Issue status update for http://drupal.org/node/30220 Post a follow up: http://drupal.org/project/comments/add/30220 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: m3avrck Updated by: m3avrck Status: patch (code needs review) Attachment: http://drupal.org/files/issues/drupal_19.patch (1.56 KB) nedjo, nice! However, the addSubmitEvent does not actually set the variable true, does not work in any browser I tried, already looked into this issue. After some research I found out that Blogger.com actually sets this variable in the form element as I did. I have updated the patch to reflect this, while still incorporating all of your changes. Code is sexy and sleek, ready for commit ;-) m3avrck Previous comments: ------------------------------------------------------------------------ Thu, 01 Sep 2005 22:47:42 +0000 : m3avrck How many times have you been posting a comment or working on a new post when you click on a link in another application and you navigate away from the content you are editing, losing all of your changes? Well I say we introduce a script, much similiar to that of Blogger, that uses the Javascript window.onbeforeunload handler to prevent this from happening. We can set this handler to call a function that compares the contents of all forms when the page loads and then quickly compares that to the current contents just before the user is about to leave the page. If they have changed, we should prompt the user so they don't lose their work. This would save many headaches and degrade nicely for users without Javascript. Additionally, this script should work with the newly introduced JS-based upload feature to prevent navigating away as a file is being uploaded as well. If I have sometime I'll start work on a patch tomorrow, just wanted to get the idea into the queue right now :) ------------------------------------------------------------------------ Sat, 10 Sep 2005 23:48:33 +0000 : StuartDH Sounds like a great feature to me. We regularly get authors and editors telling us that they've lost the last hour of work by accidentally navigating away, and I've even just had one of them email me about it a few minutes ago, so it'd be great if you could put something together for this. Cheers ------------------------------------------------------------------------ Mon, 12 Sep 2005 14:33:58 +0000 : MichelleC Sounds great to me, too. I often have several tabs open doing stuff and it's easy to lose my place and leave a page with unfinished edits. Would this alert you when you're going to close an unsaved tab/window as well? Michelle ------------------------------------------------------------------------ Mon, 12 Sep 2005 14:34:19 +0000 : MrMattles Great for us multitaskers that rush and click the wrong thing ------------------------------------------------------------------------ Mon, 12 Sep 2005 14:36:52 +0000 : chx Very strong -1 as this is IE only. ------------------------------------------------------------------------ Mon, 12 Sep 2005 14:38:40 +0000 : praseodymium Konqueror already does this, +1 for the idea in general. ------------------------------------------------------------------------ Mon, 12 Sep 2005 15:07:21 +0000 : webchick Yeah, I think chx is correc that onbeforeunload is an extension developed by MS [1] (it's not in the ECMAScript specification [2]. However, I found out that this is implemented in Mozilla since 1.7 [3] (which corresponds to Firefox 1.0, I think?) and I've tested Blogger.com's version of this functionality in: Firefox 1.0.6 (working) Firefox Deer Park Alpha 1 (working) Opera 8.0.2 (working) Safari 1.3 (does NOT work) Safari 2.0.1 (working) So it seems to be a 'de facto' standard if nothing else. [1] http://msdn.microsoft.com/workshop/author/dhtml/reference/events/onbeforeun… [2] http://www.ecma-international.org/publications/standards/Ecma-262.htm [3] http://www.mozilla.org/status/2004-03-01.html ------------------------------------------------------------------------ Mon, 12 Sep 2005 15:09:15 +0000 : webchick Also, I should clarify... that "does NOT work" in Safari doesn't display any errors or anything, it just doesn't save the form results as expected (so pre-Tiger Safari users are going to be used to this). So I don't see any harm in including this functionality since it seems to degrade gracefully in non-supporting browsers. ------------------------------------------------------------------------ Mon, 12 Sep 2005 21:10:18 +0000 : m3avrck Attachment: http://drupal.org/files/issues/node.module_11.patch (951 bytes) And a patch is ready! Code was based on many example, including this [4] and this [5] along with adding my own thoughts and what not ;) [4] http://www.codestore.org/store.nsf/cmnts/451FA051398A9AF486256EE0000FB7D1?O… [5] http://www.blogger.com/app/scripts/formcheck.js ------------------------------------------------------------------------ Mon, 12 Sep 2005 21:10:45 +0000 : m3avrck Attachment: http://drupal.org/files/issues/formcheck.js (1.54 KB) And here is the JS to throw in misc/. ------------------------------------------------------------------------ Mon, 12 Sep 2005 21:22:56 +0000 : m3avrck Attachment: http://drupal.org/files/issues/formcheck_0.js (1.61 KB) Better JS file attached without tabs. Also, tested and working great in FF and IE6. Doesn't work in Opera 8, however no errors are present, I believe this is just because the event handler is not supported. If there is a work around for Opera, please let me know! ------------------------------------------------------------------------ Mon, 12 Sep 2005 21:24:18 +0000 : m3avrck Attachment: http://drupal.org/files/issues/formcheck_1.js (1.61 KB) One more try with those tabs. ------------------------------------------------------------------------ Mon, 12 Sep 2005 21:32:48 +0000 : moshe weitzman hmmm. i usually find these prompts annoying. any chance we can attach the behavior only to the node and comment forms? those are the "high risk" areas. what do others think? ------------------------------------------------------------------------ Mon, 12 Sep 2005 21:42:39 +0000 : m3avrck Yes, the JS is only loaded on the node edit/create pages, won't affect any admin/login/etc form. Also, the prompt is unobstrusive and if you goto save a node you don't get a warning that the contents have changed because you are explicity saving the node (hence no reason!). ------------------------------------------------------------------------ Mon, 12 Sep 2005 21:53:01 +0000 : Dries I want some JS-folks to review the code. ------------------------------------------------------------------------ Mon, 12 Sep 2005 22:09:10 +0000 : m3avrck Attachment: http://drupal.org/files/issues/drupal_15.patch (1.94 KB) After talking with Drumm on IRC, this patch makes the integration with Drupal much simpler and it's off by default. Only turned on for the node edit/change page right now but any module/form can easily add this by passing a 'TRUE' parameter. ------------------------------------------------------------------------ Mon, 12 Sep 2005 23:38:35 +0000 : nedjo +1 on idea, js looks generally good, a few suggestions: 1. Instead of writing onsubmit via PHP, use a js addLoadEvent call. 2. Shouldn't the return false in isElementChanged be at the end (outside the switch block)? 3. It's be nice to find a way to make messages like 'You have unsaved changes.' translatable. Pass in global js variables via a t('') call? 4. onbeforeunload event should probably be in a if isJsEnabled test, and should parallel drupal.js's event adding (see addLoadEvent). 5. Comments should be in standard format and in present tense, e.g., /** * Checks to see if a form has been changed after the page loads */ 6. e_ should be just e to match other js files, e.g., autocomplete. ------------------------------------------------------------------------ Tue, 13 Sep 2005 13:54:35 +0000 : m3avrck Attachment: http://drupal.org/files/issues/formcheck_2.js (1.58 KB) Ok here is an updated JS file. A few notes, I couldn't get the addSubmitEvent() in drupa.js to reliably work so I had to set the isSubmit() true in the PHP creation of the form. If you look at Blogger.com, they do this as well... so either we both missed an obvious way to do this, or that is the most practical. Hopefully some wise JS gurus will chime in with an answer. Same goes for onbeforeunload event, which is completely different then addEvent defined in drupal.js. As for the t('') I agree this would be useful but I'm not sure of the best way to do this. One way would be to put in form() a t('') passed in, and then write this to a var in formcheck.php which returns a JS file type. Thoughts? ------------------------------------------------------------------------ Tue, 13 Sep 2005 14:06:44 +0000 : Junyor FWIW, Opera doesn't support the onbeforeunload event. However, this issue doesn't affect Opera anyway: form contents are retained in history as long as the page isn't closed. IOW, this feature doesn't work in Opera, but it isn't needed either. ------------------------------------------------------------------------ Tue, 13 Sep 2005 14:15:56 +0000 : m3avrck Attachment: http://drupal.org/files/issues/formcheck_3.js (1.64 KB) Updated JS styling and JS-killswitch after talking with Unconed on IRC. ------------------------------------------------------------------------ Tue, 13 Sep 2005 14:39:15 +0000 : m3avrck Just to build on Junyor's comment [6] this functionality is built into Opera 8 and it *doesn't* produce any errors. [6] http://drupal.org/#comment-44066 ------------------------------------------------------------------------ Tue, 13 Sep 2005 15:04:37 +0000 : m3avrck Attachment: http://drupal.org/files/issues/drupal_16.patch (2.1 KB) Updated patch to fix possible problem of overwriting onsubmit event handler thanks to Thox on IRC. ------------------------------------------------------------------------ Tue, 13 Sep 2005 15:13:59 +0000 : webchick I tested this and can confirm that it works in *both* versions of Safari that I have access to: 2.0.1 (OS X Tiger) and 1.3 (OS X Panther). So looks like this code goes one better over the Blogger.com stuff, because their stuff doesn't workk in 1.3. Nice job! ;) ------------------------------------------------------------------------ Tue, 13 Sep 2005 15:25:21 +0000 : m3avrck Well I'm gonna set this to commit then. Tested and working on IE, FF, Safari. Doesn't work or break Opera or Konqueror but not needed in these cases. Thox and Unconded have offered thoughts and I've modified code as needed. Doesn't seem like there is anything else left except a commit :) ------------------------------------------------------------------------ Tue, 13 Sep 2005 17:13:48 +0000 : Bèr Kessels In general I dislike the feature. Konqueror somehow dies this, and that is the way it /should/ be. Browsers should take care of this, not the web app. But, since it is only konq. this patch has a good enough additional value :) I would like to see this patch tested with, tinyMCE and HTMLAREA, at least. For I am quite sure this will break these modules so bad that they are near unusable. Which brings me to the next point: using the textarea hook a simple module could take care of this. I would very very much prefer this living in a contrib, or even a core module. Just not "enforced" on me. And the last point: if this is for core, please use that textarea hook too. This is where that hook is for: extending the textareas. ------------------------------------------------------------------------ Tue, 13 Sep 2005 17:32:25 +0000 : m3avrck Attachment: http://drupal.org/files/issues/drupal_18.patch (2.23 KB) Updated patch after talking with Thox and Uncloned to attach this event only to forms with a specific class (hence avoiding the problem of being on an edit page with other admin/search forms). ------------------------------------------------------------------------ Tue, 13 Sep 2005 17:32:55 +0000 : m3avrck Attachment: http://drupal.org/files/issues/formcheck_4.js (1.67 KB) Updated JS file. ------------------------------------------------------------------------ Tue, 13 Sep 2005 17:45:21 +0000 : m3avrck Berkes, this patch *does not* break TinyMCE, just tried. However, TinyMCE does not take into account this script. This should be an easy patch to TinyMCE. Also, this doesn't affect just textareas, it affects all fields within a given form (e.g., text fields, check boxes, etc...). Sure the blunt of editing/creating a node is in the textarea, but there are still all of those other changes that can be made (new title, revision status, front page promotion, etc...) so this needs to account for them all which it does. This script is unobtrusive and degrades perfectly well. It is tested and working in FF, IE, Safari and doens't cause problems in Opera or Konqueror which don't need this feature anyways (since they already have it). The usability boost of this script is too enormous *not* to include in core. As a contributed module, it is really too flaky, and along those lines, autocomplete.js, inlineuploads.js and related should be in their own contributed modules :) I do see your points and I hope this clears it up. It doesn't cause any problems and only attaches to specified forms, and is off by default. Any module can easily make use of this script when they use: form(..., TRUE). This is the same behavior as the other JS files included with HEAD as well. Once this is in core I'll work on a patch to TinyMCE to get that up to speed ;-) (and as such, TinyMCE still works fine, no probs/errors/etc, and good reason too if you look at how the code *actually* works ;-)). ------------------------------------------------------------------------ Tue, 13 Sep 2005 17:54:37 +0000 : Bèr Kessels I see. the "why" for not using form textarea is perfectly valid. And I tried to explain that, eventough I feel this belongs in the Agent, it is a usability enhancement for all the others using sillier browsers ;). And you are right about that part of contributions, exp since you cannot use hook_texarea, having this in a contrib cannot be achieved. I hereby retract my hesitations. (though I have no time to reapply the latest patch and test it on konq. The last JS updates broke drupal on konq, which Steven fixed, right away though!) ------------------------------------------------------------------------ Thu, 15 Sep 2005 16:31:11 +0000 : m3avrck Ready to go! ------------------------------------------------------------------------ Thu, 15 Sep 2005 20:50:06 +0000 : nedjo Attachment: http://drupal.org/files/issues/formcheck.patch (1.37 KB) Nice work m3avrck. I've made some tweaks to minimize code additions on the PHP side and improve the js. Mainly, it's now enough to set the 'formcheck' class attribute for a form. function form() will add the js file, and the needed onsubmit event will be added dynamically to forms. This is consistent with other core js files, which don't hard-code event calls but add them dynamically, based on js support. The useful functionality is unchanged. ------------------------------------------------------------------------ Thu, 15 Sep 2005 20:50:44 +0000 : nedjo Attachment: http://drupal.org/files/issues/formcheck_5.js (2.12 KB) The revised js file.

1 0