Modify the weburl.module to (optionally) use the APIs provided by the links package if the links.module is enabled.

I envision something that allows you to easily select an existing link, or enter a URL and title for a new link.

I would love to see this implemented as an enhancement to the existing weburl.module, but if not, I suppose it could be a separate CCK field module in the links package.

Comments

KarenS’s picture

The weburl module is badly broken, and you can get full-featured links functionality by enabling the links package and enabling the cck module to allow links. The only thing you cannot do with the links module is completely control where on the page they display (although the links module gives you some options in that regard). Using that package would be the best option, in my opinion, for anyone who needs lots of control and management over links.

That leaves the occasional internal or external link. That is basically a text field with some themeing to format it into a link. We could remove the weburl module, add a "link" option to the text field module with a simple validation function and a themeing function, and suggest that people use the links module for more heavy duty needs.

I would use the same approach for email links.

RayZ’s picture

Well, what I really want is all of the flexibility and link management offered by the links package, but implemented as a cck field, with all of it's per field configuration options (field name/label, required/optional, weight, help text, etc.). With the related_links feature in the links package, you can only specify whether a content type has related links (disabled, required or optional), but not how many and what each is called, etc.

So I still think a separate link field module is needed. If it's included in cck (as a weburl enhancement/replacement) then it should handle two cases:

(1) links package not present: text field with special handling
(2) links package is present: use the links API

If, on the other hand, this module is included as part of the links package it would only need to handle (2) and leave (1) for the existing weburl.module or your simple "link" option on a standard text field.

syscrusher’s picture

RayZ wrote:

With the related_links feature in the links package, you can only specify whether a content type has related links
(disabled, required or optional), but not how many and what each is called, etc.

(Nota bene: It's actually links_related, but I know what you're talking about.)

This is absolutely correct. I had eventually planned to add those features to the links_related module, but having reviewed the discussion threads about CCK, I think it would be silly for me to put that much work into links_related. Instead, I think the best plan is to keep links_related lean and simple for those who just need basic functionality, and let those who need more flexibility use the CCK/Links integration module. Does this make sense to you?

Point to ponder: Is it worth offering a Links API implementation for Flexinode, or is Flexinode going to be soon supplanted by CCK? I know the general concepts of CCK but haven't been closely following its development. Comments welcome.

Syscrusher

RayZ’s picture

Syscrusher wrote:

I think the best plan is to keep links_related lean and simple for those who just need basic functionality, and let those who need more flexibility use the CCK/Links integration module. Does this make sense to you?

Yes. I think that makes perfect sense.

Regarding flexinode, I don't get the feeling there is much new development going on for flexinode. I think it's mostly maintenance work, so I wouldn't recommend spending any time on it.

KarenS’s picture

Removed weburl from cvs, please use link instead (http://drupal.org/project/link). Weburl is not being maintained.

KarenS’s picture

Status: Active » Fixed

Forgot to mark fixed.

Anonymous’s picture

Status: Fixed » Closed (fixed)