| Project: | Linkit |
| Version: | 7.x-2.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Issue Summary
Problem
Originally started as an issue to test and report multilingual issues, the discussion focused on the fact that Linkit outputs full URL's. these URL's include alias and language prefix.
What is wrong with this feature, is that Linkit is on the input side and should not try to format input directly into an output format. Typical Drupal workflow is to store input as is and filter/format on the output side. This allows to use the same input in multiple channels (website, feeds, mailings). It also allows to make some settings generic and changeable, like the language detection. By not storing the language prefix that settings can be changed. By not storing the alias, the content can be moved.
To work like described, we need tools at both the input and the output side. The input side should store content as agnostic as possible, the output tool should transform to the situation at hand (alias, language prefix, domain based language selection, etc.).
Proposed resolution
Linkit should output links like {a href="node/21" ...} or {a href="sites/default/files/my-image.jpg" ...}. Pathologic (or similar output filters, if they exist) should do the transformations on output.
Original report by [anon]
Test 7.x-2.x with multi languages.
Comments
#1
Works grate with i18n.
But it seems to be some problem with i18n + linkit + pathologic. Pathologic adds dubble language prefixes.
#2
I can't confirm the issue anon posted (#1). Which steps did you make?
I have another issue: You have to change interface language in admin area in order to link to nodes in another language. I guess this is working as intended, but a configuration option like this would be great:
search nodes in current interface language OR search nodes in every language OR search nodes in current node language
The last one should be the default imho. What do you think?
edit: If you save a node in another than the interface language, the urls in the frontend get messed up (e.g. prepending "en" instead of "de" which it was before saving the content in en-interface). Don't know what's happening here. In the database there is just node/4. Where comes that en? The database says node/4 and language en. I'm not that deeply in Drupal and its modules, but this behaviour can't be correct.
edit2: Ok, I've realized that it's an caching issue. Example: If you save an en-node with de-interface the seo link in the node body gets messed up. It links to de/node/4 but that node is english. The german node is node/5. After clearing the cache the link gets fixed. Then it becomes like expected: en/seo-node-title
#3
The error regarding the language prefix isnt something I can control. Thats the filter cache that does.
I like your thoughts about the settings for languages. Let me see what I can do.
#4
I see now what you meant regarding "Pathologic adds dubble language prefixes.".
The created urls in RTE should be in the format node/4 or am I wrong?
You call Drupal's url-function in the function _linkit_node_autocomplete:
<?php'path' => url('node/' . $node->nid, array('alias' => TRUE)),
?>
I'd say calling url-function isn't neccessary because the link will be constructed afterwards. So you just have to set this:
<?php'path' => 'node/' . $node->nid,
?>
What do you think?
However this setup works for me.
Regarding the language configuration option: I've made a quick change to linkit to choose if I want it to search for nodes in all languages or not. See this diff:
diff -r linkit/linkit.module linkit-patched/linkit.module970a971
> 'search_all_languages' => 0,
diff -r linkit/plugins/export_ui/linkit_profiles.inc linkit-patched/plugins/export_ui/linkit_profiles.inc
131a132,137
> $form['data']['node']['search_all_languages'] = array(
> '#title' => t('Search nodes in all languages.'),
> '#type' => 'checkbox',
> '#default_value' => isset($profile->data['node']['search_all_languages']) ? $profile->data['node']['search_all_languages'] : 0,
> );
>
diff -r linkit/plugins/linkit.node.inc linkit-patched/plugins/linkit.node.inc
83a86,90
> // Search in languages
> if ($profile->data['node']['search_all_languages'] == 1) {
> $query->condition('n.language', '', '<>');
> }
>
#5
We call the URL function because it handles basepath, prefix and clean url settings for us.
#6
But doesn't that happen automatically or is it because of my filter settings (convert urls and correct urls with pathologic)?
When I use the url-function I get /drupaltest/en/drupaltest/en/node/4 instead of /drupaltest/en/node/4. But if it works without getting language prefix and subdirectory (if existing) why should we get the basepath and prefix? If it's there you have to struggle with the basepath when for example moving away from that subdirectory. Maybe I've misunderstood something, but with the above changes it works like I'd expect it and like it is in linkit 7.1.2 or not?
Sorry if I maybe annoy you but I'd like to understand and help.
#7
The reason for inserting the links with the base path is that it should work without pathologic or any other filters.
Inserting nodes like "node/4" (as in 7.x-1.2) will result in that if you are linking on node 3, the link will be node/3/node/4.
Its the same as you would do if you was linking the "normal way" I.E whit he regular linktool in the editor.
And no, that doent happend automatically. I think its your filter that does.
#8
I'm wondering if it's possible to get aliased links when linking e.g. from an English node to a Spanish one. When I do this I get a 'node/30'-like link, rather than the aliased 'es/titulo' link. I suppose this makes sense since there is no English alias for that node, but is there any way to do this?
#9
Linkit will not insert any type of alias, it will just insert the generic URL.
To get alias, you will have to use somekind of text filter, like Pathologic.
#10
Ah, I should've mentioned, I'm using Pathologic. When I link from e.g. an English node to another English node, the resulting link uses the alias. But when linking from an English to a Spanish node this doesn't work, and I'm wondering if this isn't possible, or if it's a problem with my configuration (be it of i18n, pathologic, or whatever...).
#11
The multilingual support for Linkit isnt ready yet, but its in the pipeline.
If the link is correct to the spanish site, except the alias, that's a pathologic problem.
Linkit should add the lang prefix I think, and as I said, this in the pipeline.
#12
I don't think that Linkit should add the language prefix. As far as I can see, nowhere in Drupal are language prefixes stored. Not in textfields, not in menu's. Language prefixes are automatically added by Drupal the soon as a link is created for output. So I think that modules that operate on the input side should never ever add language prefixes. Thus Linkit should not, Pathologic should (except not for existing resources... #961618: Language prefix should not be added to the path to files).
Note that language prefixes are a setting that can be changed to e.g. language detection based on subdomain and the site should continue to work.
#13
Agree with you.
#14
I also agree with the opinion stated at #12: linkit should not add language prefix.
Because of this behavior I cannot use linkit at the moment (without manually modifying it).. :/
Do you plan to change / fix this soon at least in 7.x-2.x-dev version?
BTW, version 2.x looks great - thx for such awesome module! :)
#15
Same here, pathologic doesn't work with the language prefix.
#16
setting pathologic to pick up on the language prefix works for me for the moment.
#17
D7.10, pathologic-7.x-2.0-beta1.
I also agree with #12 and #14. Linkit adding the language prefix is causing issues, have to manually remove this prefix and this then works ok. Any solution for this yet?
#18
I haven't been able to take a close look at this, but is it the URL function that adds the lang prefix or is Linkit doing it?
#19
That's the url() function of Drupal. (to be used on the render site of the system)
#20
yes, it's the url()-function.
In my installation I changed...
sorry, doesn't work 100%. I'll investigate further and later post my solution here.
#21
Ok, for me this is working:
change in function _linkit_node_autocomplete in linkit.node.inc
<?php'path' => url('node/' . $node->nid, array('alias' => TRUE)),
?>
to
<?php'path' => 'node/' . $node->nid,
?>
so the url doesn't get prefixed with the language.
I have set up Pathologic to correct URLs and "/" considered local.
I think it's better to not create a language prefix for the link, because there is only one language for a node id and this should be handled by page generation and not when entering links in RTE.
#22
In D7, nodes can be language neutral and its fields can be translatable, resulting in 1 node-id that can be served in multiple languages. (entity translation versus translation sets)
#23
And we still need the URL function for the the subdir issue.
If you have drupal installed in a subdir, or a suddir in a subdir. url() handles that, and I dont think Linkit should add the same functionallity for that.
We have to find another way to get both this to work.
#24
Subdir issue is also a thing that is done on the output side:
I think that your attempt to no longer need pathologic turned out to be more difficult than thought. We are facing problems here that can only be solved on the output side. So either accept that pathologic is still needed or add your own filter. But people would still need to enable that manually and it will largely be a copy of pathologic...
#25
I agree with #24.
#26
Its a smaller issue, but Linkit doesn't seem to search for translated titles of taxonomy terms.
Example:
I have a taxonomy term called "teacher", I translated it in dutch to "docent". But when I try to add a link to this term I can only find it under "teacher". This even though my current language was set to dutch.
CKEditor Link does support this, but the interface isn't as nice, maybe check how they do it.
#27
Please create a separate issue. It does not seem to be related to this one.
#28
Oops, used the tag field instead of the title field.
Making the title more specific to the issue at hand here.
#29
The change from #21 packed in a patch and against the latest dev version where plugins are used.
Notes (to the module maintainer):
#30
Im having real hard time to figureout the different multilingual setups.
locale, i18n, multilingual content, Content translation. This is a djungle for me...
#31
It sure is. The nice thing about using relative internal links is that it works in the editor and on the output:
- The editor iframe, at least for CKEditor via wysywig module, has a base tag in its head that is equal to Drupal's base url. So paths relative to that base url work correctly.
- On the output it is Pathologic that corrects this (or, in very simple cases, i.e. all clean url's at the root level, it works anyway).
So I would say, always output relative internal links, also the links you get from the IMCE plugin. Or at least provide an option to do so, so that people who do not mind being dependent on pathologic (and that nice base tag in wysiwig editor iframe) have a full working environment everywhere they migrate their site to.
If you need specific help on multi-lingual issues, you can ask me.
#32
Sorry maybe you already said it in some posts but I am a newbie so, I don't understand well.
I installed Linkit and made a test. Ok, it find the node but when I see the page it results with the url included in the text space.
Can you say me what I have to do to get a normal link result in the output? I wish not to have do uninstall it like I did with elfinder that is a great fuss to set it.
I attach 2 shot of my test
Problem1.jpg is during the edit phase
Problem2.jpg is the result in view mode
Thank you
Angelo
#33
You are completely off topic, but a hint: Apparently you are using some kind of markdown editor (because of the [url ...]). The editor knows to show a link for [url...], but the content is tored with the markdown. This means you will have to install, enable and configure a filter that changes the markdown in real html (<a href="...">...</a>). You can configure filters in the text formats.
#34
I'm very soorry that I put my post here.
In anycase I don't know where put hands about this markdown I haven't add any tools for writing.
Attached is a shot of Filtered Html settings or if you can help me in what do I have to check more?
I'm very newbie in drupal use.
thanks
#35
Solved! I think something was wrong with some theme or some modules I installed.
I anycase I uninstalled all modules but it was the Wysiwyg module that had problem.
I uninstalled and reinstalled it gave some problems but then worked.
Linkit it's a great module I will discover how better it works.
Thank you
#36
Discovered the problem in my links. It was the BBCode button-plugin in TinyMCE enabled, it changed the html in that other code I didn't know at all. I disabled and anything is ok.
#37
Please find attached a patch against the current dev version.
It solves the problem at hand for:
- all plugins that inherit from linkit-plugin-entity.class.php
- files received from the IMCE dialog
I can imagine that you want to stay independent from pathologic (though I would not recommend that), so that you probably want some setting to influence this behavior. The changes themselves are quite simple, but it will be the settings around it that might make it just a bit more complex.
I would like to see this problem solved, as each project again I run into the same problems (a good deal of my projects are multilingual). So if you need any help, please indicate so.
#38
I really want to stay independent from pathologic as that should just work.
Pathologic is "translating" the urls in the output, fine, but for all those who not use patholocig, it doesnt make sense to insert incorrect urls.
I mean, whats the differences here.
If you use the regular link plugin for the editor, and have your site installed in a sub dir, you have to add the subdir or a slash to the url as it otherwise will not work.
Examples:
Regular site, not pathlogic, no languages.
/node/123
Site in "drupal" sub dir, not pathlogic, no languages
/drupal/node/123
Regular site, not pathlogic, with languages (prefix).
/en/node/123
/sv/node/123
Site in "drupal" sub dir, not pathlogic, with languages (prefix)
/drupal/en/node/123
/drupal/sv/node/123
If pathologic rewrite this later on in some crazy way in the output, they are doing it wrong I think.
Am I missing something?
fietserwin
It seems like you know what your talking about so If im incorrect, please correct me.
#39
You are correct, but only within the context of the current settings and location. It prevents me and many, many other people achieving full independence between
- content
versus
- location (=dev, test, live, subdir, domain name),
- settings (language selection, prefix settings) and
- output format (web, e-mail newsletter, feed).
It should be possible to move the content from a Drupal site to another location or change settings, while the content should remain intact. With Pathologic this can be achieved, but only if Linkit allows for it. So I am saying that at least it should be an option to output relative links.
All fields and settings that store links or paths, only store relative links and paths. Think of file and image fields, reference fields, and settings like "Default front page" and the default 403/404 pages. All fields? That is with the exception of textarea fields that contain free format text. If we add links to these, we are supposed to enter full links???
To "correct" this deviating behavior, the pathologic module was developed. Pathologic allows to also store relative links in free format text, but it will also correct wrong "absolute" links.
The language prefix is a setting. Settings should be changeable, meaning the site should keep working when one changes either the language selection or changes the prefix of a language. I know that the UI of this admin screen explicitly warns for the danger of changing this setting on alive site, but, if necessary, I still would like to be able to do so. And currently the only problem is in the free format text fields.
In my Ideal Drupal installation, modules like linkit (and IMCE) would be configurable to output relative links only, deferring prefixing it with the base path/domain and language prefix to the output side (pathologic or a base tag in your html template).
To stay independent from pathologic the feature we're discussing here, should be made configurable.
As said, I am willing to give it a try, if I can assume that it will be taken seriously and incorporated if everything is OK.
#40
+1000000 for #39 a.k.a.
Please, that would make life a lot easier.
Thx.
#41
fietserwin
Of course, I really appreciate your help here.
My goal is to implement a sustainable solution for this.
In order to build that sustainable soltution we need tackle one hugh problem tho.
The "default front page", 403/404 and all other fields is using relative urls, true, and that work fine because they are dedicated to just "one value" and can be processed in a total different way then the textareas.
I mean they can add whatever they what in a preprocess (or similar) function to make this work.
The only way to do this with the textarea is to make a text format/filter and use that.
And then we are back to depending on a text format/filter, which I feel is the wrong way.
Maybe one solution is that (like you said) a settings for inserting rel. vs. abs. links, but what will/should happen when the user change this setting?
Is there any other possibilities?
Any thoughts about this?
#42
You could see a filter as a preprocess function as well. One that is totally supported and deeply embedded in Drupal :)
But not wanting Linkit to depend on a text filter is also a good thing to strive for. Certain use cases will indeed better be served by "absolute" (i.e. protocol and domain are still left out, but links will start with a '/') links. But other use cases are best served by using relative links.
We have e.g. many clients that, for budgetary reasons, want to start with a single lingual site and want to add additional languages later.
So, I guess that making it optional is the way to go. Everyone can choose his preference based on the use case at hand.
Are there other possibilities?
Adding a base tag to your template and use relative URL's as much as possible. Searching for base tag and Drupal I did not find many issues/requests. It seems that before Drupal 4.x, templates had a base tag. but it has been removed because it was giving other problems. Note that this won't help in multi-lingual sites.
#43
If the "rel vs abs settings" solves all problem, I think this is a good solution.
The settings should be made per profile so different profiles can have different settings.
The default state should be "abs" (we need a better word for this) I think as we dont want to depend on a text filter by default.
#44
I just found 1 more reason to use filters: Most sites use path/pathauto to create SE/User friendly URL's. Linkit emits .../node/23 style links. These should be replaced by their alias. which is, again, a task for the output system, not (for Linkit on) the input side.
Do yo want me to give it a try or do you want to implement this yourself?
#45
But doesnt pathologic replace them with the alias? Or do you mean when you dont have pathlogic installed?
Im not a big fan of adding a text filter into Linkit, as there are so many other modules (filters) out there that probably can handle this.
I more into the idea that having a setting for this, like you mentioned before. Because if we can give other modules the possibility to act on out "output", then I think this is solved.
#46
I indeed meant the case you prefer, thus without Pathologic (or similar filter) installed. And no, do not add a filter to linkit, but make sure it works with existing filters.
#47
Here is a start.
We still need to figure out the terms to use. Absolute and relative doesnt seems right to me.
Also, there is some UX stuff to handle. Im thinking about adding a new fieldset called "Advanced settings" and move the weight and URL insert method in there, but that is another issue.
#48
Has anyone tested this?
#49
Just back from a week away. I will look into it shortly.
#50
I tested your patch and would like to notice the following points:
- Changed the descriptions a bit, though I guess they can be further improved.
- Added support for relative URL's for the IMCE file browser option.
- Tested: nodes, users, taxonomies: OK.
- Tested: IMCE: the link is shown relative in the edit field (correct), but on closing (with "Insert link") the dialog is shown full page instead of closed. But this behavior is also there without the changes of this patch. So I think that is a different error.
Please find attached my additions to your patch.
#51
Any progress? Patch applies without errors to 7.x-2.3. The error with the IMCE dialog still occurs.
#52
I still need help with the naming here.
We cant call the variables relative and absolute as they really is not.
#53
#54
You are right that those are not the best describing options. Hopefully someone else of the current 13 followers of this issue has some good ideas regarding the naming. Another option would be to just pick some naming now and expose all users (nearly 5000 D7 installs) to it and you might get other suggestions, especially if hinting at it on the admin page.
Brainstorming a bit, hopefully this will others give some inspiration to come up with better suggestions:
Absolute - relative (links are not really absolute, but relative to server, relative are relative to Drupal)
External - internal (links are not external in the sense of another site, links are not internal to the current host, but internal to Drupal)
Server based - Drupal internal
Working (on current configuration) - Needs base tag/output filter (and then works on all configurations)
Ready to use URL - Drupal (internal) path
I think I prefer "Drupal internal" and then making it a checkbox (default = off).
#55
Regarding the naming another possibility:
Entity URI vs URL and maybe add a description telling people what to expect (node/xx vs my-node) and tell them when to use one or the other: "If you have Pathologic installed you can better use Entity URI" or "If you have a multilingual site, install the Pathologic module and choose Entity URI to make sure your links are outputted right"
Small typos:
+++ b/plugins/plugin.class.phpundefined@@ -72,13 +72,34 @@ abstract class LinkitPlugin implements LinkitPluginInterface {
+ /**
+ * Contruct an absolute url.
Construct
+++ b/plugins/plugin.class.phpundefined@@ -72,13 +72,34 @@ abstract class LinkitPlugin implements LinkitPluginInterface {
/**
+ * Contruct a relative url.
Construct
#56
+1 for "just pick some naming now and expose all users (nearly 5000 D7 installs) to it and you might get other suggestions, especially if hinting at it on the admin page"
I like also Drupal internal.
+1 for explanation in #55, but not for Entity URI (vs. URL) phrase.
#57
This patch:
- Has been rerolled against current dev.
- Changed to Drupal internal path versus working/ready to sue URL's
- More explanation
- Typo's from #55
I think "Drupal internal (path)" is the name to use instead of relative. Absolute remains difficult, I now describe it as "(ready to use) URL's", thereby emphasizing that we are not really talking URL's and that processing is needed in the former case. I find entity URI a bit misleading as we are also talking about links to existing resources (images, documents).
I would really appreciate it if we could move forward on this, even though it may still not be perfect, it is better than it currently is. Remember, we are not talking about a feature here, but a bug, as multilingual sites just don't work.
#58
I also think we should more forward with this, tho its a new feature and not a bug as I see it.
Can someone else confirm that the patch in #57 is working?
#59
Hmmm, I had to rename plugin.class.inc to plugin.class.php when I wanted to define a profile. Not sure which extension to use. It was .php, but latest dev installed a .inc.