Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
The CCK project already has a weburl field type, but it would be nice to have a CCK field module that integrates with the links API.
I envision something that allows you to easily select an existing link, or enter a URL and title for a new link. And obviously it should be Views enabled.
Been giving a bit more thought to a possible design, now that I'm becoming more familiar with the Links API and I see that other related modules keep popping up that do not use the Links API ([1], [2], [3]).
Initially, I was thinking that each link field would simply store the corresponding link id (lid). However, it appears that the unique identifier for a particular instance of a link associated with a node is (lid, nid, module) in the {links_node} table. If I understand correctly, this means that in order for different instances of the same link in a single node to have different titles and to have their own click counts, the 'module' column has to have a different value for each link field in the content type. (Hmm, was that clear?)
Maybe an example would help. Suppose we have a CCK content type for a user profile that has two link fields, one to point to the user's home page and another to their photo album. For a given node, you might want to use the same link for both fields, but with different titles. The only way to distinguish between these two instances in the {links_node} table is if they are stored with a different value in the 'module' column for each of the fields. Maybe something that contains the field name.
I'm not sure whether the module column in that table was meant to be used that way. If not, it may indicate the need for another field in the {links_node} table to distinguish the multiple instances of the same (lid, nid) pair.
Sorry to be so slow weighing in on this. I'm 100% in favor of the idea of a CCK field that integrates with Links API. RayZ, if you are still volunteering to code it, I'll happily take you up on that as right now I'm trying to get Links out the door tagged for 4.7. I'll be glad to collaborate to the extent of answering questions about Links API as needed, even sharing my cell number with you if necessary.
If you don't have the time or inclination to code this, I'm willing to do it myself, but it'll be a couple of weeks before I can start on it.
Thanks for the response. While I would really love to code this up, I just don't see how I can realistically find the time to do it. However, I'm happy to collaborate (off-line via e-mail if that's better) on the design and testing.
And on that note, do you have any comments on my design ideas in #3 above? Will it require a change to the Links schema?
If I do get any time to start working on coding I'll be sure let you know.
Any ideas what would be involved to add Links API support to this module? I wouldn't mind giving it an attempt, but I'm not sure where to start.
Or maybe to put it another way, how would I go about adding Links API functionality to some custom node module I wrote? That might lend some clues for how the two could be integrated.
@webchick.
A personal need for such a field comes up now. So I am re-activating this issue.
What is needed, is for links (the CCK field) to use the links APIS to store its data. Instead of its own (cck-based) storage.
In fact, this will greatly reduce the size of links, since it can re-use 70% of its code (validation, storage, duplication-finding etc).
I completely agree that this would be a great feature, but I haven't had time to implement it yet. I took a look at the CCK code, and it looked to me as if CCK had fairly deeply-embedded expectations that it would always be writing fields to its own tables. They didn't seem to have a clean way to externalize the load/store process. Now, that was a version or two ago, so things may be better.
I'd welcome a contrib if anyone has the time to do this. Otherwise, the best I can say is that I want it too and will do it as soon as I can get the 6.0 port done.
Yes, your assumptions are correct on all counts about the links API. The "module" field is intended to establish a context for the link (in fact, I originally named the field that in the database table). The idea is that modules that associate links with nodes can operate independently of one another without stepping on each other's namespace. For example, one might have a "weblink" node type that also allows related links, and for whatever reason one might want to have the same link for the primary "weblink" link and for one of the node's related links. Seems silly, but I didn't want to presume that I could anticipate all possible needs of all possible modules, hence the added versatility of the context. This is also a way for modules to avoid accidentally editing one another's links for a node.
In the normal case, the $module parameter should get the name of the module (e.g., "links_related" or similar), but as far as the API is concerned *any* site-unique string is valid. I would *strongly* encourage that this should at least begin with the owning module's name, but there's no problem with an extended modifier within the module's "namespace". That is, if CCK wanted to, it could use "cck", "cck.foo", "cck.foo.bar", and so on, as long as the separator character is something like "." or "#" that is not itself valid within a module filename (that is, I would discourage "cck_foo_bar" because there might later be a module called "cck_foo", making that ambiguous). "#" might be a really good choice here.
Alternatively, I don't object to adding a module-local ID field to the schema. I could fairly easily make the Links Package core modules stuff a constant null into that field, since they don't need it. CCK or other complex modules could put a sequence number or field ID into that field to uniquify their node/link/module tuples.
@syscrusher #9: No its not that hard. CCK allows you to use your own storage. Its just that you then cannot re-use CCKs "DBA".
E.g. http://drupal.org/project/cck_taxonomy uses its own storage in addition to a (to allow fast JOINS) a foreign key in the node_x tables.
AFAIK the hardest part is building the interface, storage should be simple with link API.
Comments
Comment #1
RayZ CreditAttribution: RayZ commentedThis might best be implemented as an enhancement to the existing weburl module.
Comment #2
RayZ CreditAttribution: RayZ commentedPretty please ;-)
Comment #3
RayZ CreditAttribution: RayZ commentedBeen giving a bit more thought to a possible design, now that I'm becoming more familiar with the Links API and I see that other related modules keep popping up that do not use the Links API ([1], [2], [3]).
Initially, I was thinking that each link field would simply store the corresponding link id (lid). However, it appears that the unique identifier for a particular instance of a link associated with a node is (lid, nid, module) in the {links_node} table. If I understand correctly, this means that in order for different instances of the same link in a single node to have different titles and to have their own click counts, the 'module' column has to have a different value for each link field in the content type. (Hmm, was that clear?)
Maybe an example would help. Suppose we have a CCK content type for a user profile that has two link fields, one to point to the user's home page and another to their photo album. For a given node, you might want to use the same link for both fields, but with different titles. The only way to distinguish between these two instances in the {links_node} table is if they are stored with a different value in the 'module' column for each of the fields. Maybe something that contains the field name.
I'm not sure whether the module column in that table was meant to be used that way. If not, it may indicate the need for another field in the {links_node} table to distinguish the multiple instances of the same (lid, nid) pair.
Thoughts anyone?
[1] http://drupal.org/project/link (see also: http://drupal.org/node/75248)
[2] http://drupal.org/node/65206
[3] weburl.module currently included in CCK
Comment #4
syscrusher CreditAttribution: syscrusher commentedHi, all.
Sorry to be so slow weighing in on this. I'm 100% in favor of the idea of a CCK field that integrates with Links API. RayZ, if you are still volunteering to code it, I'll happily take you up on that as right now I'm trying to get Links out the door tagged for 4.7. I'll be glad to collaborate to the extent of answering questions about Links API as needed, even sharing my cell number with you if necessary.
If you don't have the time or inclination to code this, I'm willing to do it myself, but it'll be a couple of weeks before I can start on it.
Please let me know how you'd like to proceed.
Syscrusher
Comment #5
RayZ CreditAttribution: RayZ commentedThanks for the response. While I would really love to code this up, I just don't see how I can realistically find the time to do it. However, I'm happy to collaborate (off-line via e-mail if that's better) on the design and testing.
And on that note, do you have any comments on my design ideas in #3 above? Will it require a change to the Links schema?
If I do get any time to start working on coding I'll be sure let you know.
Comment #6
webchickThere is now the Link module, which is a URL field type for CCK: http://drupal.org/project/link
Any ideas what would be involved to add Links API support to this module? I wouldn't mind giving it an attempt, but I'm not sure where to start.
Or maybe to put it another way, how would I go about adding Links API functionality to some custom node module I wrote? That might lend some clues for how the two could be integrated.
Comment #7
Bèr Kessels CreditAttribution: Bèr Kessels commented@webchick.
A personal need for such a field comes up now. So I am re-activating this issue.
What is needed, is for links (the CCK field) to use the links APIS to store its data. Instead of its own (cck-based) storage.
In fact, this will greatly reduce the size of links, since it can re-use 70% of its code (validation, storage, duplication-finding etc).
Comment #8
Anonymous (not verified) CreditAttribution: Anonymous commentedThis gets my vote as well. This would be a great enhancement to the links package.
Mark
Comment #9
syscrusher CreditAttribution: syscrusher commentedI completely agree that this would be a great feature, but I haven't had time to implement it yet. I took a look at the CCK code, and it looked to me as if CCK had fairly deeply-embedded expectations that it would always be writing fields to its own tables. They didn't seem to have a clean way to externalize the load/store process. Now, that was a version or two ago, so things may be better.
I'd welcome a contrib if anyone has the time to do this. Otherwise, the best I can say is that I want it too and will do it as soon as I can get the 6.0 port done.
Syscrusher
Comment #10
syscrusher CreditAttribution: syscrusher commented@ RayZ, comment #3...
Yes, your assumptions are correct on all counts about the links API. The "module" field is intended to establish a context for the link (in fact, I originally named the field that in the database table). The idea is that modules that associate links with nodes can operate independently of one another without stepping on each other's namespace. For example, one might have a "weblink" node type that also allows related links, and for whatever reason one might want to have the same link for the primary "weblink" link and for one of the node's related links. Seems silly, but I didn't want to presume that I could anticipate all possible needs of all possible modules, hence the added versatility of the context. This is also a way for modules to avoid accidentally editing one another's links for a node.
In the normal case, the $module parameter should get the name of the module (e.g., "links_related" or similar), but as far as the API is concerned *any* site-unique string is valid. I would *strongly* encourage that this should at least begin with the owning module's name, but there's no problem with an extended modifier within the module's "namespace". That is, if CCK wanted to, it could use "cck", "cck.foo", "cck.foo.bar", and so on, as long as the separator character is something like "." or "#" that is not itself valid within a module filename (that is, I would discourage "cck_foo_bar" because there might later be a module called "cck_foo", making that ambiguous). "#" might be a really good choice here.
Alternatively, I don't object to adding a module-local ID field to the schema. I could fairly easily make the Links Package core modules stuff a constant null into that field, since they don't need it. CCK or other complex modules could put a sequence number or field ID into that field to uniquify their node/link/module tuples.
Syscrusher
Comment #11
Bèr Kessels CreditAttribution: Bèr Kessels commented@syscrusher #9: No its not that hard. CCK allows you to use your own storage. Its just that you then cannot re-use CCKs "DBA".
E.g. http://drupal.org/project/cck_taxonomy uses its own storage in addition to a (to allow fast JOINS) a foreign key in the node_x tables.
AFAIK the hardest part is building the interface, storage should be simple with link API.
Comment #12
Anonymous (not verified) CreditAttribution: Anonymous commentedAny further news on this? Can anything be done to speed up development of this feature?
Mark
Comment #13
quicksketchLink module is up for adoption. Syscrusher, if you're interested I'd love to give it to you.