Hello, folks, I'm in need of a little help... I have a module with 3 types of node. Node A, B and C. I am trying to do something like A is the main node and B & C references A. So that, when I show the node A (teaser or full node), I get some informations about nodes type B and C that makes reference to A. Also, I want to node types B and C have a reference to the parent (A). When the user inserts the data, it must be transparent to him as who the parent is (like there is a link on node type A that allows the user to create type B or C and the node creation page will not ask the user who the parent is). The only creation method shoud be like this for nodes B and C (there should not have a link on the node creation list. Just for type A) I took a look at the project module, but I couldn't get much out of it... Any help is appreciated... Thanks, - Luis Sergio Moura
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 16 Nov 2005, at 3:09 PM, Sergio wrote:
Hello, folks, I'm in need of a little help... I have a module with 3 types of node. Node A, B and C. I am trying to do something like A is the main node and B & C references A. So that, when I show the node A (teaser or full node), I get some informations about nodes type B and C that makes reference to A. Also, I want to node types B and C have a reference to the parent (A).
Welcome to the wonderful world of node relationships. We're busy working on a generalized API that allows you to do this kind of thing, but i don't know if there's any code you can use today (you can try clipper.module).
- -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDezvkgegMqdGlkasRAhowAJ9qoGdgkMHJt5szWlr6RiIlBkyclgCgtgc4 jYcY6+AHFSPLfFyV8mz68/U= =QKcE -----END PGP SIGNATURE-----
You just need to get the nid of the main node into the creation of the subordinate node typoes. How about using a query string to specify the parent, like node/add/B?mainnode=(nid of A) or maybe node/add/B/(nid of A) Populate the new field in hook_form(). You can even choose to show an input control for the field if it's not specified On 11/16/05, Sergio <lsmoura@gmail.com> wrote:
Hello, folks, I'm in need of a little help... I have a module with 3 types of node. Node A, B and C. I am trying to do something like A is the main node and B & C references A. So that, when I show the node A (teaser or full node), I get some informations about nodes type B and C that makes reference to A. Also, I want to node types B and C have a reference to the parent (A). When the user inserts the data, it must be transparent to him as who the parent is (like there is a link on node type A that allows the user to create type B or C and the node creation page will not ask the user who the parent is). The only creation method shoud be like this for nodes B and C (there should not have a link on the node creation list. Just for type A)
I took a look at the project module, but I couldn't get much out of it... Any help is appreciated...
Thanks, - Luis Sergio Moura
Earl, I tought about that... I have a ?q=node/add/B/5 and I changed the hook_form to function B_form(&$node, &$param, $nidA = 0) But I don't get the desired result... The page at drupaldocs http://drupaldocs.org/api/4.6/function/page_example_menusays that the 'extra' parameters will be passed as arguments to the function, but it seems that those don't get to the hook_form function. Is there any way to create a custom function and re-create the form as the node/add/B would do? That way I could create the form and it would work transparently to the user... Also, is it that the desired hook_form behavior? Have I found a bug? :-) Thanks for the help... On 11/16/05, Earl Dunovant <prometheus6@gmail.com> wrote:
You just need to get the nid of the main node into the creation of the subordinate node typoes. How about using a query string to specify the parent, like
node/add/B?mainnode=(nid of A)
or maybe
node/add/B/(nid of A)
Populate the new field in hook_form(). You can even choose to show an input control for the field if it's not specified
On 11/16/05, Sergio <lsmoura@gmail.com> wrote:
Hello, folks, I'm in need of a little help... I have a module with 3 types of node. Node A, B and C. I am trying to do something like A is the main node and B & C references A. So that, when I show the node A (teaser or full node), I get some informations about nodes type B and C that makes reference to A. Also, I want to node types B and C have a reference to the parent (A). When the user inserts the data, it must be transparent to him as who the parent is (like there is a link on node type A that allows the user to create type B or C and the node creation page will not ask the user who the parent is). The only creation method shoud be like this for nodes B and C (there should not have a link on the node creation list. Just for type A)
I took a look at the project module, but I couldn't get much out of it... Any help is appreciated...
Thanks, - Luis Sergio Moura
I don't have a DIFF here, but here it goes... I tweaked the node.module a bit (4.6.3) so the I could make the /node/add/<type>/<parameter> works and I get the desires result... This need to be tweaked further so that more parameters can be added... function node_page() { (...) case 'add': print theme('page', node_add(arg(2), arg(3))); break; (...) function node_add($type, $_extra = 0) { (...) } $output = node_form($node, $_extra); drupal_set_title(t('Submit %name', array('%name' => node_invoke($node, 'node_name')))); (...) function node_form($edit, $_extra = 0) { (...) if (function_exists($function)) { if ($_extra) $form .= $function($edit, $param, $_extra); else $form .= $function($edit, $param); } (...) function B_form(&$node, &$param, $nidA = 0) That does the trick... But as I don't think that this is the desired function of node.module, I will try and write my code another way so that it stays compatible with the official version... Altough I get no warnings with the above changes (so far). Back to the module coding now... Thanks all - Sergio On 11/16/05, Sergio <lsmoura@gmail.com> wrote:
Earl, I tought about that...
I have a ?q=node/add/B/5 and I changed the hook_form to function B_form(&$node, &$param, $nidA = 0) But I don't get the desired result... The page at drupaldocs http://drupaldocs.org/api/4.6/function/page_example_menu says that the 'extra' parameters will be passed as arguments to the function, but it seems that those don't get to the hook_form function. Is there any way to create a custom function and re-create the form as the node/add/B would do? That way I could create the form and it would work transparently to the user... Also, is it that the desired hook_form behavior? Have I found a bug? :-)
Thanks for the help...
On 11/16/05, Earl Dunovant < prometheus6@gmail.com> wrote:
You just need to get the nid of the main node into the creation of the subordinate node typoes. How about using a query string to specify the parent, like
node/add/B?mainnode=(nid of A)
or maybe
node/add/B/(nid of A)
Populate the new field in hook_form(). You can even choose to show an input control for the field if it's not specified
On 11/16/05, Sergio <lsmoura@gmail.com> wrote:
Hello, folks, I'm in need of a little help... I have a module with 3 types of node. Node A, B and C. I am trying to do something like A is the main node and B & C references A. So that, when I show the node A (teaser or full node), I get some informations about nodes type B and C that makes reference to A. Also, I want to node types B and C have a reference to the parent (A). When the user inserts the data, it must be transparent to him as who the parent is (like there is a link on node type A that allows the user to create type B or C and the node creation page will not ask the user who the parent is). The only creation method shoud be like this for nodes B and C (there should not have a link on the node creation list. Just for type A)
I took a look at the project module, but I couldn't get much out of it... Any help is appreciated...
Thanks, - Luis Sergio Moura
Assuming /node/add/B?mainnode=5, something like this should work. function B_form(&$node, &$params) { $mainnode = $_GET['mainnode']; // make sure it's a valid node for the purpose if (nid_passes_the_test($mainnode) { $node->mainnode = $mainnode; } else { // yell at them for making an error } ... } On 11/16/05, Sergio <lsmoura@gmail.com> wrote:
Earl, I tought about that...
I have a ?q=node/add/B/5 and I changed the hook_form to function B_form(&$node, &$param, $nidA = 0) But I don't get the desired result... The page at drupaldocs http://drupaldocs.org/api/4.6/function/page_example_menu says that the 'extra' parameters will be passed as arguments to the function, but it seems that those don't get to the hook_form function. Is there any way to create a custom function and re-create the form as the node/add/B would do? That way I could create the form and it would work transparently to the user... Also, is it that the desired hook_form behavior? Have I found a bug? :-)
Thanks for the help...
On 11/16/05, Earl Dunovant < prometheus6@gmail.com> wrote:
You just need to get the nid of the main node into the creation of the subordinate node typoes. How about using a query string to specify the parent, like
node/add/B?mainnode=(nid of A)
or maybe
node/add/B/(nid of A)
Populate the new field in hook_form(). You can even choose to show an input control for the field if it's not specified
On 11/16/05, Sergio <lsmoura@gmail.com> wrote:
Hello, folks, I'm in need of a little help... I have a module with 3 types of node. Node A, B and C. I am trying to do something like A is the main node and B & C references A. So that, when I show the node A (teaser or full node), I get some informations about nodes type B and C that makes reference to A. Also, I want to node types B and C have a reference to the parent (A). When the user inserts the data, it must be transparent to him as who the parent is (like there is a link on node type A that allows the user to create type B or C and the node creation page will not ask the user who the parent is). The only creation method shoud be like this for nodes B and C (there should not have a link on the node creation list. Just for type A)
I took a look at the project module, but I couldn't get much out of it... Any help is appreciated...
Thanks, - Luis Sergio Moura
Clipper module has an add child link; to add a relation to teh node you are looking at. Op woensdag 16 november 2005 16:11, schreef Earl Dunovant:
You just need to get the nid of the main node into the creation of the subordinate node typoes. How about using a query string to specify the parent, like
node/add/B?mainnode=(nid of A)
or maybe
node/add/B/(nid of A)
Populate the new field in hook_form(). You can even choose to show an input control for the field if it's not specified Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
Sergio wrote:
Hello, folks, I'm in need of a little help... I have a module with 3 types of node. Node A, B and C. I am trying to do something like A is the main node and B & C references A. So that, when I show the node A (teaser or full node), I get some informations about nodes type B and C that makes reference to A. Also, I want to node types B and C have a reference to the parent (A). When the user inserts the data, it must be transparent to him as who the parent is (like there is a link on node type A that allows the user to create type B or C and the node creation page will not ask the user who the parent is). The only creation method shoud be like this for nodes B and C (there should not have a link on the node creation list. Just for type A)
I took a look at the project module, but I couldn't get much out of it... Any help is appreciated...
Thanks, - Luis Sergio Moura
As others have mentioned, there are many modules out there that manage node-to-node relationships. One thing that was a problem the last time I looked was how to go about restricting access to node/add/[type that requires parent]/[nid of parent] without other things breaking. Previous discussions led me to override the menu settings to disallow access to this path, but since the menu system does not prioritize it's entries, you may find that your modification of the menu permissions doesn't always work. The result is that the node/add page shows links to add content that is not allowed to exist without a parent. The Node Relativity module (http://drupal.org/node/17004) essentially does what you're looking for, but hasn't been updated in a while. It is big and needs some refactoring and is probably a heavier solution than you're looking for, though. Regards, -Mark
So...an easy way to add a parent reference plus a straightforward way to keep type creation links off the content/add page would pretty much do it? Am I missing something? Because the new node identification method in 4.7can be adjusted slightly to hide those links. A small change to the array hook_node_info() returns (add an element to indicate visibility), a new op for _node_names() (call it "display create link" or something) and a small change to node_add() would do it. On 11/18/05, Mark <mark@nullcraft.org> wrote:
One thing that was a problem the last time I looked was how to go about restricting access to node/add/[type that requires parent]/[nid of parent] without other things breaking. Previous discussions led me to override the menu settings to disallow access to this path, but since the menu system does not prioritize it's entries, you may find that your modification of the menu permissions doesn't always work. The result is that the node/add page shows links to add content that is not allowed to exist without a parent.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19 Nov 2005, at 2:32 PM, Earl Dunovant wrote:
So...an easy way to add a parent reference plus a straightforward way to keep type creation links off the content/add page would pretty much do it?
http://drupal.org/node/28480 - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDfxyRgegMqdGlkasRAlxGAJ4w/XPaTTqzSdi/UhC0dkb4hwceKwCgv4pl v3KQTNOukxam6qCHgKNoD4E= =Xd/w -----END PGP SIGNATURE-----
On 11/19/05, Adrian Rossouw <adrian@bryght.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 19 Nov 2005, at 2:32 PM, Earl Dunovant wrote:
So...an easy way to add a parent reference plus a straightforward way to keep type creation links off the content/add page would pretty much do it?
Okay, there's a lot there. I'll read it. what about simply removing the node/add page using menus module? that page
is often worthless anyway (as is the whole navigation block IMO).
That's a real option if you're not using the navigation block. If you are the "create content" link needs a destination. When I get less busy I may code a patch for those three points I mentioned. I can think of uses for it.
As others have mentioned, there are many modules out there that manage node-to-node relationships. One thing that was a problem the last time I looked was how to go about restricting access to node/add/[type that requires parent]/[nid of parent] without other things breaking. Previous discussions led me to override the menu settings to disallow access to this path, but since the menu system does not prioritize it's entries, you may find that your modification of the menu permissions doesn't always work. The result is that the node/add page shows links to add content that is not allowed to exist without a parent. The Node Relativity module (http://drupal.org/node/17004) essentially does what you're looking for, but hasn't been updated in a while. It is big and needs some refactoring and is probably a heavier solution than you're looking for, though.
what about simply removing the node/add page using menus module? that page is often worthless anyway (as is the whole navigation block IMO). -moshe
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19 Nov 2005, at 3:01 PM, Moshe Weitzman wrote:
As others have mentioned, there are many modules out there that manage node-to-node relationships. One thing that was a problem the last time I looked was how to go about restricting access to node/add/ [type that requires parent]/[nid of parent] without other things breaking. Previous discussions led me to override the menu settings to disallow access to this path, but since the menu system does not prioritize it's entries, you may find that your modification of the menu permissions doesn't always work. The result is that the node/add page shows links to add content that is not allowed to exist without a parent. The Node Relativity module (http://drupal.org/node/17004) essentially does what you're looking for, but hasn't been updated in a while. It is big and needs some refactoring and is probably a heavier solution than you're looking for, though.
what about simply removing the node/add page using menus module? that page is often worthless anyway (as is the whole navigation block IMO).
For the new version of oasismag I am dropping the use of the nagivation block. 1) i am moving the admin menu to it's own block, enabled only for admins. 2) i am putting site wide links (journals, poetry, forum and about) into the primary links (underneath the header). [ anything that is shared space ] 3) I am putting personal links (my account, my journal, my inbox (n) etc.) into the secondary links, which are placed to the top right of the header. [ anything that is personal space ] 4) I am moving all the 'actions' into a flat menu at the top right block. (new journal entry, new forum post, new private message etc.) [ anything that results in an object being created ] I like this because everything has it's place, and it keeps each of the menu's to the bare minimum. Since we have tabs now, i see no reason for deeply nested configurations anymore. I also want to make all the things you can do and see , visible most of the time, without having to click down into trees. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDfyoEgegMqdGlkasRAjAZAKC9oYx2QQLXmOWpbLlCm84esHr2fwCeMpAO /TNLR/G2Tyt1g/o5AZ2dMxk= =RwIj -----END PGP SIGNATURE-----
what about simply removing the node/add page using menus module? that page is often worthless anyway (as is the whole navigation block IMO).
For the new version of oasismag I am dropping the use of the nagivation block.
1) i am moving the admin menu to it's own block, enabled only for admins. 2) i am putting site wide links (journals, poetry, forum and about) into the primary links (underneath the header). [ anything that is shared space ] 3) I am putting personal links (my account, my journal, my inbox (n) etc.) into the secondary links, which are placed to the top right of the header. [ anything that is personal space ] 4) I am moving all the 'actions' into a flat menu at the top right block. (new journal entry, new forum post, new private message etc.) [ anything that results in an object being created ]
I like this because everything has it's place, and it keeps each of the menu's to the bare minimum. Since we have tabs now, i see no reason for deeply nested configurations anymore.
I also want to make all the things you can do and see , visible most of the time, without having to click down into trees.
yeah, thats what i am now doing for my sites too. the navigation block is a failed experiment IMO. A site of any magnitude needs custom navigation beyond what is provided by that block. furthermore, the navigation block is extremely expensive to calculate. thats why we do the whole menu_build() and menu cache. if we get rid of it, we can move the callback system to the DB and skip the menu building business. jonbob posted a note on 10/30 to this list that he was working on this (list archives are mysteriously missing this time period).he said: "I've done some initial work toward separating the data structures for callbacks and for the visible tree. At the moment I can't imagine it has a performance impact in either direction, but it cleans things up a little bit and might be a stepping stone for further separation. I'll post the patch when it's further tested. " we should think a bit about what 'out of the box' experience we can offer without a navigation block. i'm thinking that we offer some default primary links.
Adrian Rossouw wrote:
3) I am putting personal links (my account, my journal, my inbox (n) etc.) into the secondary links, which are placed to the top right of the header. [ anything that is personal space ]
I'd like to keep the 'my account' and 'logout' links in the user login block for it's logged in state. Copies of these links would remain as suggested menu items. This would remove the need to put the username at the top of the standard navigation block, which would make a lot more sense for those who do use it. And the block title would actually be configurable, which it isn't now. -- Neil Drumm http://delocalizedham.com/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 20 Nov 2005, at 12:36 AM, Neil Drumm wrote:
Adrian Rossouw wrote:
3) I am putting personal links (my account, my journal, my inbox (n) etc.) into the secondary links, which are placed to the top right of the header. [ anything that is personal space ]
I'd like to keep the 'my account' and 'logout' links in the user login block for it's logged in state. Copies of these links would remain as suggested menu items. What if you don't use the login block.
I think a seperate menu for anything relating to the current user is all that's needed, but it can be placed wherever you want with regions (in the secondary links location, or in one of the sidebars for what you are looking for) - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDf6yygegMqdGlkasRAr4GAKCw/2wVGYLTSCTm13rF//t2bhc3GgCgqsdu kMSUjRmk6nqNkM8uMm4o/94= =4kot -----END PGP SIGNATURE-----
http://dev.bryght.com/t/wiki/RestructureDrupal is still there. I got there after testing a few different menu structures with several clients. This one seemed most logaical to all. The "Configure Note 2 my profile (my subscriptions)" Part is where all the personal settings go. It is a top level menu entry, but can be made into a separate block very easy. All the top level items can. Ber Op zaterdag 19 november 2005 23:52, schreef Adrian Rossouw:
On 20 Nov 2005, at 12:36 AM, Neil Drumm wrote:
Adrian Rossouw wrote:
3) I am putting personal links (my account, my journal, my inbox (n) etc.) into the secondary links, which are placed to the top right of the header. [ anything that is personal space ]
I'd like to keep the 'my account' and 'logout' links in the user login block for it's logged in state. Copies of these links would remain as suggested menu items.
What if you don't use the login block.
I think a seperate menu for anything relating to the current user is all that's needed, but it can be placed wherever you want with regions (in the secondary links location, or in one of the sidebars for what you are looking for) Bèr -- PGP ber@webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc PGP berkessels@gmx.net http://www.webschuur.com/sites/webschuur.com/files/ber_gmx.asc
Op zaterdag 19 november 2005 14:01, schreef Moshe Weitzman:
what about simply removing the node/add page using menus module? that page is often worthless anyway (as is the whole navigation block IMO).
-moshe
Pease +1. it is broken ATM, hard to get fixed and indeed is quite useless. (do you really read what a blog is, every time you want to add a blog post?) I have no time to code this, though; So my +1 is not worth much :) Bèr -- | Bèr Kessels | webschuur.com | website development | | Jabber & Google Talk: ber@jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com |
Bèr Kessels wrote:
Op zaterdag 19 november 2005 14:01, schreef Moshe Weitzman:
what about simply removing the node/add page using menus module? that page is often worthless anyway (as is the whole navigation block IMO).
Pease +1. it is broken ATM, hard to get fixed and indeed is quite useless. (do you really read what a blog is, every time you want to add a blog post?)
On a site like Drupal.org where you have a constant influx of new members, this page is quite usefull. In fact, I've long wanted that page to be themable in order to be able to add some nice icons. I think Vlado has done some work on this. node_add is one of those functions that are around like forever, time to make it themable.
I have no time to code this, though; So my +1 is not worth much :)
Removing the menu with menu.module should not require any code. Cheers, Gerhard
Moshe Weitzman wrote:
what about simply removing the node/add page using menus module? that page is often worthless anyway (as is the whole navigation block IMO).
I'd like to see a real draft state and other workflow things. The node/add page would be a good place to put a listing of unfinished posts, although it probably isn't the only possibility. (The workflow in core possibilities I'm thinking of are putting the workflow module in core in some form and removing as many of the existing checkboxes from node/add/... since they could be handled with workflow.) If we standardize local links to add nodes (such as the way you can create a forum topic when you are looking at the forum) I think the existing node/add page becomes unnecessary. -- Neil Drumm http://delocalizedham.com/
On Fri, 2005-11-18 at 19:08 -0600, Mark wrote:
Sergio wrote:
Hello, folks, I'm in need of a little help... I have a module with 3 types of node. Node A, B and C. I am trying to do something like A is the main node and B & C references A. So that, when I show the node A (teaser or full node), I get some informations about nodes type B and C that makes reference to A. Also, I want to node types B and C have a reference to the parent (A). When the user inserts the data, it must be transparent to him as who the parent is (like there is a link on node type A that allows the user to create type B or C and the node creation page will not ask the user who the parent is). The only creation method shoud be like this for nodes B and C (there should not have a link on the node creation list. Just for type A)
I took a look at the project module, but I couldn't get much out of it... Any help is appreciated...
Thanks, - Luis Sergio Moura
As others have mentioned, there are many modules out there that manage node-to-node relationships. One thing that was a problem the last time I looked was how to go about restricting access to node/add/[type that requires parent]/[nid of parent] without other things breaking. Previous discussions led me to override the menu settings to disallow access to this path, but since the menu system does not prioritize it's entries, you may find that your modification of the menu permissions doesn't always work. The result is that the node/add page shows links to add content that is not allowed to exist without a parent. The Node Relativity module (http://drupal.org/node/17004) essentially does what you're looking for, but hasn't been updated in a while. It is big and needs some refactoring and is probably a heavier solution than you're looking for, though.
Regards, -Mark
Couldn't you handle checking for missing parents with hook_access? in the if $op == create if there isn't a parent, just theme a page stating a parent must exist to create this node, and exit?
participants (9)
-
Adrian Rossouw -
Bèr Kessels -
Darrel O'Pry -
Earl Dunovant -
Gerhard Killesreiter -
Mark -
Moshe Weitzman -
Neil Drumm -
Sergio