Needs review
Project:
CKEditor Link
Version:
7.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
15 Sep 2010 at 12:13 UTC
Updated:
18 Feb 2016 at 17:35 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
anrikun commentedPlease give a detailled list of the steps to reproduce what you are trying to do.
Comment #2
sinasalek commented- Selecting a text
- Clicking on the Add Link button on CKEditor's toolbar
- Selecting Drupal from the drop down on the opened modal dialog
- Entering a node title and selecting it
- Appending #ancheranem at the end of the link
- Submit and the receiving invalid link error
Comment #3
anrikun commentedSorry this is not possible yet.
Let's add this as a feature request.
Comment #4
sarah_g commentedI would like this feature to include the ability to link make it easier to add links back to the top of the page. Can you scan the site for typical IDs like "top" or "main" maybe provide those as anchors? If not then being able to enter an id would be great. Thank you!
Comment #5
elpino commented@Sarah_G
I think what you want can be accomplished with what is already available through CKEditor.
Just add an anchor at the top of your content with a name attribute, or if you prefer elsewhere on your page you can add said anchor through the appropiate template (i.e. page.tpl.php), and then at the end of your content or wherever you like add a regular link to "#top"
... no need for internal links for this.
Comment #6
ardas commentedHaving anchor is a very good idea because clients need an easy way to add anchor to links. Using standard CK editor link will not work because this module is very good with Pathologic and is used to provide a flexible and user friendly way to add a link that will be transformed into a proper URL. So, it is important to have an ability to add an anchor to this link. In our websites clients don't use standard URL dialogue to create INTERNAL links.
We are now working on a patch that will retrieve all anchors with their titles from the chosen node and present them in a flexible drop down list. We will post this patch shortly...
Comment #7
elpino commentedThat would be great!
The temporary solution I was using was to create the internal links with the help of this module, and after I was finished I'd turn of richtext-editing and manually edit the code adding the needed anchor to the links. Which sometimes is a hassle if I don't remember the named anchor links.
Comment #8
timb commented+1 - this module makes it easy for my client to build out interlinking in his site, and it would be only better if we could add anchors.
Comment #9
sarah_g commented+1 - Yes, this is only an issue for client content contributors. Obviously, I could add links to anchors in page and node templates that I know about but my content contributors don't know about these anchors.
"Back to top" links are really the main functionality they need. If nothing else maybe that could be a built in option. Thanks!
Comment #10
johnpitcairn commented#6 sounds ideal, though how much of the target "page" do you load and examine for anchors?
The entire rendered html output? This can vary hugely depending on many factors, especially user-agent (mobile, desktop, etc) and user account. A lot trickier than it sounds.
Or just the $node->body field? Easier, but may not be called "body" if the node type doesn't use the default body field.
Perhaps this is why there has been no further contribution from @ardas?
Alternately, if the content editors can rely on a standard set of anchors, plus anchors that they have added to the target node themselves, an "arguments" field such as I'm proposing in #1491750: UI to add arguments, query and hash to the linked path (patch) could perhaps serve the purpose.
Comment #11
mirsoft commentedFor those who are interested, I added the patch which supports Drupal node links in latest dev for Drupal 7 (7.x-2.3+3-dev).
Btw.: make sure you clear all the caches and also client browser js cache after applying. Otherwise you won't see any difference :)
Comment #12
zmove commentedPatch applied manually cause I got errors using git on the latest dev, but it works ! I suppose it needs review by the maintainer.
Comment #13
johnpitcairn commentedComment #14
mfernea commentedThe patch at #11 doesn't apply correctly nor on 7.x-2.3 nor on latest 7.x-2.x.
Here are the patches for both.
Comment #15
jeffamI tested this patch and one at https://www.drupal.org/node/1491750 and found that version to be more flexible. I appreciate how much simpler this patch is, but I like how the other version can handle other URL arguments and query parameters in addition to hash fragments. It's nice that it has a setting to enable/disable the extra field, too.
If a choice must be made between this patch and the one at https://www.drupal.org/node/1491750, then I vote for that one.
Comment #16
stefan.r commentedAgreed with for #15, #1491750: UI to add arguments, query and hash to the linked path (patch) makes more sense.