Issue status update for http://drupal.org/node/27155 Post a follow up: http://drupal.org/project/comments/add/27155 Project: Drupal Version: cvs Component: node.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: jakeg Updated by: clydefrog Status: patch (code needs review) nevets, having the values in $node->get is no different than having them in $_GET['edit']. Modules would still have to to be modified to use the values to prefill the form. This patch allows fields to be prefilled on node/add pages without modifications to node or nodeapi modules. clydefrog Previous comments: ------------------------------------------------------------------------ Wed, 20 Jul 2005 17:43:52 +0000 : jakeg I'm creating wiki-like features on my site so that if someone with the permission to create new pages goes to a 'page not found' page then it gives them an option to create a page at that address (i.e. at that path, so if they goto /somepath they can easily create a page with path /somepath). To do this its very handy for the 'path alias' field on the new node page to be pre-filled with a value using e.g. node/add/page?edit[path]=somepath in the same way that you can prefill the title field using node/add/page?edit[title]=sometitle I've got this to work by adding the following line to path.module at line 211 as thus: case 'form pre': if(!$node->path AND isset($_GET['edit']['path'])) $node->path = $_GET['edit']['path']; $output = ... ... my line is the 'if' line in the middle above. Could this be added to core? I'm sure others could find it handy and it would save me from having to rewrite the line on every upgrade. If it can't be added to core, is there anyway for me to put this line into my own custom module somehow so that I don't have to rewrite it every time I upgrade? ------------------------------------------------------------------------ Wed, 27 Jul 2005 16:18:31 +0000 : leafish_paul Not a patch, but I quite like the idea. ------------------------------------------------------------------------ Wed, 27 Jul 2005 16:22:09 +0000 : leafish_paul Attachment: http://drupal.org/files/issues/path.module.wiki.style.create.page.at.404.pat... (956 bytes) Here you go, ready for voting. ------------------------------------------------------------------------ Wed, 27 Jul 2005 17:40:16 +0000 : Bèr Kessels Hmm. I am not sure. In this way, it can only be used by the wiki module. And IMO it is a bad thing to facilitate single implementations in core. In other words: I would definitely +1 this were a more general solution. So, what about a hook? IMNSHO that is actually over the top, a hook, but it would help other modules that want to fiddle with the path too. ------------------------------------------------------------------------ Wed, 27 Jul 2005 17:54:27 +0000 : jakeg It shouldn't be implemented as a hook, that is overkill. Apart from wiki modules, you may generally want to be able to submit a node with any number of the fields prefilled (i.e. not just 'path' but other fields as well... though I can't think of an example right now). Having lines such as the one I suggest for those fields is the only way to make this possible without individuals having to hack the core and update their hacks each time there's a new release. ------------------------------------------------------------------------ Wed, 27 Jul 2005 18:14:36 +0000 : clydefrog jakeg, an example is book module, where the "add child page" link uses its own URL syntax to prefill the parent field. If a hook for listing prefillable fields existed, the URL syntax could be made consistent with the rest of core and contrib. ------------------------------------------------------------------------ Wed, 27 Jul 2005 18:17:22 +0000 : Bèr Kessels an overkill indeed. but $node->path = $_GET['edit']['path'] just doesn't feel right. So I was thinking aloud about how to solve this. Anyone? ------------------------------------------------------------------------ Wed, 27 Jul 2005 18:27:42 +0000 : clydefrog Attachment: http://drupal.org/files/issues/node-prefill.patch (1023 bytes) Why not just prefill $node with everything in $_GET['edit']? This patch should do that (untested) ------------------------------------------------------------------------ Wed, 27 Jul 2005 18:50:57 +0000 : eafarris Attachment: http://drupal.org/files/issues/node.module.fill.node.with.get.patch (497 bytes) /me gets errors with your patch, but here's a tested version. I really like this idea; without it, I can't get a bookmarklet to fill in the 'url' field of the weblink node type, for example. ------------------------------------------------------------------------ Wed, 27 Jul 2005 19:30:08 +0000 : eafarris Attachment: http://drupal.org/files/issues/node.module.fill.node.with.get_0.patch (665 bytes) wrapping that section in an if ($_GET['edit']) block gets rid of the array_keys() error on regular posting pages. updated patch attached. Also, moved issue to the node.module. ------------------------------------------------------------------------ Thu, 28 Jul 2005 08:35:58 +0000 : Bèr Kessels I prefer that last patch. But, still, I dislike it. As far as I can tell, you can achieve all this with properly invoked nodeapi calls. ------------------------------------------------------------------------ Thu, 28 Jul 2005 14:29:48 +0000 : eafarris Bèr, Do you mean that each module should implement its own nodeapi for converting $_GETs to $edits? Seems like it would be better to have node.module do this for everyone, or am I misunderstanding you? Also, I'm wondering what security ramifications a patch like mine would have. Drupal's pretty good at checking input, but you never know. ------------------------------------------------------------------------ Thu, 28 Jul 2005 14:43:54 +0000 : Bèr Kessels What i mean is that with nodeapi, you can add the following to *wiki.module* : <?php wiki_nodeapi() { //... global $node; //.... case 'form pre': node->path = wiki_get_path(); //... } ?> That way you leave the hard work for the module that needs the hard work done. And security: I am simply not sure. But setting the $node object from *_GET data just does not feel right. Off course this should be no problem, because anyone can alter the $POST too. Its just that I prefer to leave it to code to set the node object, and not to url hacking. ------------------------------------------------------------------------ Thu, 28 Jul 2005 15:09:35 +0000 : eafarris Ok, I see. While that would solve the original poster's issue, I have a different need that's solved by this patch: bookmarklets and their ilk. With Moshe's bookmarklet ( http://www.tejasa.com/bookmarklet ) I can post to a blog entry, but hacking it to fill in, in my example, the 'url' field of weblink.module requires this patch for it to be passed along to the form. This also opens up possibilities for a Greasemonkey script I'm working on, too. Without the patch, only title, teaser, and body are passed along from the URL. That's quite constraining, all sorts of cool stuff can't happen because the fields are simply thrown away. I'm not after module->module or module->node interactions, I'm looking at filling Drupal forms from outside. ------------------------------------------------------------------------ Fri, 29 Jul 2005 03:14:34 +0000 : clydefrog I agree with eafarris - it's better to have node.module do the work for everyone rather than each module having its own code to fill fields on the form page. I too was worried about the security ramifications. But I thought about it for a while and now I believe there's really nothing to worry about. The changes only apply to node/add pages, so no data can get from $_GET to the database without the user's approval. As long as the data is properly escaped, it can't mess up the HTML on the page. Modules which use hidden fields may behave strangely if a hidden field is filled from $_GET, but those are certainly in the minority and can avoid the problems simply by checking $_GET before using a value from $node in pre-filling the form. ------------------------------------------------------------------------ Fri, 29 Jul 2005 03:48:25 +0000 : nevets Why not store the fields in node under get so instead of node->somefield it would be node->get->somefield? At least that way there is only one node field that modules need to care about avoiding and it reduces the likelyhood that the change will impact existing modules.