Currently, the manual links are entered in HTML format, e.g. <a href="http://www.example.com/">Example</a>. This isn't very user friendly. It would be better if users didn't have to know HTML syntax.

This patch changes the input format so that the syntax is http://www.example.com/ Example, the URL followed by the link title (separated by a space). If no title is provided, the URL itself becomes the title.

CommentFileSizeAuthor
#5 relatedlinks_4.7.patch14.18 KBNaX
relatedlinks.module.patch_6.txt3.5 KBcolan

Comments

Zen’s picture

Zen commented

Just a few points of consideration:

  • If we do this, then it might be best to store the URIs in the DB in the same form - nid, URI, text, type. In other words, we follow the same format for all links. This will also make things easier in tackling duplicates etc. and reduce this to and fro conversion between formats for the manual related links textfield.
  • IIRC your original patch had a form_alter variable that disabled tinyMCE.. what are the drawbacks of allowing users to use RTEs here?
  • While I personally have no necessity for it, there might be a need to allow JS (with appropriate checks) in the manual links field. For e.g. to open a pop-up.

Your thoughts on this are appreciated.

Cheers,
-K

tones’s picture

tones commented

RTEs rearrange the input field so that relatedlinks.module can't parse it properly.

BTW, this patch won't actually disable tinymce unless/until tinymce uses this other patch:
http://drupal.org/node/74662

colan’s picture

colan
he/him
Primary language English
Location Toronto 🇨🇦
commented

As far as the DB stuff is concerned, separate fields is totally the way to go. The reason I've been holding off on this is because I was waiting for the Links Package. It, however, seems to be completed. CVS already has 5.0 code. I'm going to looks at the API & see if I can get the 4.7 branch working with what we've got. I'll report back here once I do the research. Do you have any thoughts on this? I think that'll be better in the long term. For example, duplicates checking is handled in that package. What do you think about committing this patch for now? At least we could get the UI bits in there. I'm with you though - I'm not crazy about the to and fro conversions either.

I don't really feel the need for JS myself. I (and others I've been working with) think it would be better keeping it simple, at least for now. I wouldn't be opposed to adding this later, however. Someone could always add it to the wishlist at some point. Tones suggested that external links could open a new window. That would be simple enough.

Zen’s picture

Zen commented
Status: Needs review » Active

Colan: I'd prefer it if it was done in one fell swoop. This UI improvement, while useful is not important enough to warrant the workaround, temporary as it may be.

My initial thoughts on the links package after a perfunctory look-see:

  • The package comes with its own related links module.
  • The package appears to be incomplete and IMO should have just been an API.
  • The API itself is bloated and overkill will be an understatement w.r.t this module's requirements.
  • Primary focus of the package seems to be on link tracking and monitoring.
  • I'm not a fan of URL obfuscation [e.g. "links/goto/80/1"] etc.

I would personally like to keep this module as lean as possible, streamline existing functionality and place more emphasis on "auto-discovery" of related links via the taxonomy and search modules.

I will try to work on this later tonight. Your thoughts are welcome.

Cheers,
-K
P.S Tones: cheers for the explanation.

NaX’s picture

NaX commented
Status: Active » Needs review
StatusFileSize
new relatedlinks_4.7.patch14.18 KB

Purely by chance I notice this issue and I had just finished hacking the related links module. Because I am planning to use it more for manually defined links rather than using the auto-discovery features and need it to be easy for none web designers to add links, so I changed it so that a user adds the links by filling in a form field for a title, url and description.

I added a few columns to the database. I did not edit the pgsql in the install file as I am unfamiliar with pgsql.

I also added a tab to the node pages where you can define the weight of each link. I am later hoping to add to this page the ability to define attributes like target or even JS events like onclick. I have not worked out how I am going to implement this, I am thinking about using a serialized array. Their is a slight problem with this feature at present. Because all links are deleted and then recreated when a node is updated the weights for each node is lost and needs to be reset. This will also cause problems with attributes and will need to be resolved.

When I implement the attributes feature I might need some help with the regular expressions for extracting the attributes from Parsed links..

Take a look and tell me what you think.
Hope you find it useful.

ps. This patch is for the 4.7 version

Zen’s picture

Zen commented
Status: Needs review » Fixed

Colan: I've made a couple of commits that should address this issue and would appreciate a review. If possible, please check and suggest improvements to the regex and if you happen to have a pgSQL install, please test the updater. Cheers :)

Nax: Thanks! I had a browse through your patch. Please check out the CVS version of this module which has had a couple of updates. Please also take a look at the related links module in the links package as it appears to accomplish much of what you've put together in this patch.

UI improvements: I would appreciate input on improving the manual links UI further. JS isn't my strong suit and any help in this regard is appreciated :)

Marking this issue fixed. Please reopen as necessary.

Thanks
-K

colan’s picture

colan
he/him
Primary language English
Location Toronto 🇨🇦
commented
Assigned: colan » Unassigned
Status: Fixed » Active

Thanks! Good work on getting the new database schema implemented. I finally had some time to look over your commits. It looks like there are a couple of outstanding issues. I believe these were in my patch:

  1. The help text when manually entering links should be changed to:

    To manually define links to related material, enter one URL and title (separated by a space) per line. Example: http://www.example.com Clickable Text. Alternately, you can enter an internal site address. Example: about About Us If no title is submitted, the URL itself will become the title.

  2. The display order of manual links should match the entry order. Therefore, the display order needs to be reversed.

I'll post a note here about the regex after I look at it.

colan’s picture

colan
he/him
Primary language English
Location Toronto 🇨🇦
commented

That regex looks good, and even better than that, it works! ;)

The only thing I thought of was that the link title could have whitespace at the end, but I don't really see that as a problem. Someone may want it in there for some reason. I'm happy either way.

Zen’s picture

Zen commented
Status: Active » Fixed

I've fixed the 'description' and link order issues in HEAD. Please check.

Marking as fixed :)

Muchas gracias.
-K

Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)