I use pathologic, linkit and ckeditor (ckeditor without wysiwyg)
As default , Limit allowed HTML tags is checked under Security filters for the Filterd HTML profile.
What it does is that its runs some filter function to sanitize the text from Ckeditor before presentation.
One of this functions is filter_xss_bad_protocol() which will delete all non accepted protocols from attributes.
The "internal" prefix in links is considered a protocol and is stripped away as it isnt in the default variable.
My patch includes an install file (pathologic.intall) with 2 hooks.
hook_install and hook_uninstall
What is does is that its adding "internal" to the default variable.
And removes it when the module is uninstalled.
| Comment | File | Size | Author |
|---|---|---|---|
| pathologic.patch | 1.35 KB | anon |
Comments
Comment #1
Garrett Albright commentedIn D7, filter_xss_bad_protocol() calls drupal_strip_dangerous_protocols(), which in turn, as far as I can tell, removes any "dangerous" protocols from URLs - so "internal:foo/bar" would become just "foo/bar". Which should be fine, since that's the kind of path that Pathologic looks for anyway, and my testing seems to back that up - internal: paths are working just fine without this patch.
So maybe I'm not understanding the problem. Could you maybe make a go at explaining it to me again?
Comment #2
anonFor some reason, Ckeditor calls this Filter HTML functions right before the text is rendered inside the editor (in edit mode).
I think they do so because the want to make sure that no bad scripts are executed by "mistake" when the text is rendered.
And its first now we face the problem.
When the text has been processed by all this Filter HTML functions, all "internal:" is gone and if you save the text again, you will end up with links without "internal:"
Lets pretend we are about to create a node with this in the body text.
<p>This is a <a href="internal:node/123">sample</a> text in my textarea</a>After we saved it for the first time, "internal:" will still be there.
<p>This is a <a href="internal:node/123">sample</a> text in my textarea</a>But then we want to add a new line of text, or change the title or something else.
- Go to edit mode
Now, the text is runned through this Filter HTML functions again, before its inserted in the editor area.
The text that will be inserted in the textarea/editor will become
<p>This is a <a href="node/123">sample</a> text in my textarea</a>If you save this, It will look like just the code above.
Comment #3
anonThis should also be the case when ever filter_xss_bad_protocol() is called and the pathologic filter isnt.
Cant think of any cases right now, but Im pretty sure that there are some.
Comment #4
Garrett Albright commentedI get it now. This may not be a bad idea, though it may be a while before I get around to adding it.
It is possible to configure the CKEditor module to not run filters on markup it sends to the editor, but yeah, it does potentially open you up to security issues if you are dealing with untrusted users' input.
Comment #5
anon"though it may be a while before I get around to adding it"
Ok, can I ask why?
Comment #6
Garrett Albright commentedBecause what I'm stuck on at the moment is figuring out how to properly handle an upgrade of Pathologic during the upgrade from Drupal 6 to Drupal 7. The way D7 stores variables for input filters is different enough that I really have no idea the best way to handle that update. I still need to do some experimenting. It's something I want to get done before adding new features.
Comment #7
anonOk, Thanks for the explanation.
Comment #8
Garrett Albright commentedanon, Dave Reid brought my attention to a module he wrote called FIlter Protocols to alter the trouble-causing variable. If you're still having this problem, do you think you could give it a try? Let me know how it goes.
Comment #9
anonGarrett, I have changed the way my module use paths now, so this is no longer needed. Works perfect without the "internal:" now.