[drupal-devel] [feature] Prefill the $node object from the $_GET
variables
nevets
drupal-devel at drupal.org
Fri Jul 29 03:48:44 UTC 2005
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: nevets
Status: patch
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.
nevets
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.patch (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.
More information about the drupal-devel
mailing list