Author Topic: ckeditor config (Read 88862 times)

ken · August 25, 2010, 02:34:04 pm

I just found the answer to my previous question about setting absolute URLs in IMCE. I tracked down an issue in the IMCE project which suggested editing the file sites/all/modules/imce/tpl/imce-content.tpl.php and uncommenting the line which says

Code: [Select]

  //imce.vars.absurls = 1; //make IMCE return absolute file URLs to external applications.

Howver, this affects IMCE across the whole application. And because I'm using Secure Pages and have set CiviCRM to use HTTPS, that will mean all my image links will use the secure scheme.

Ideally, I would like embedded images to use relative URLs across the site and only use absolute URLs in CiviMails.

Thoughts?

Ken

looksystems · September 05, 2010, 05:02:32 am

Quote from: ken on August 04, 2010, 09:22:07 pm

In my Drupal environment, I'm using ckeditor + imce and the integration (almost) works. This is still a test environment, so it hasn't yet stood the fire of live users.

Thanks Ken!

Just in case it helps anyone, here's another version for use with Drupal 6 IMCE module and CiviCRM ckeditor...

Change to civicrm/packages/HTML/QuickForm/ckeditor.php:

Code: [Select]

- CKEDITOR.replace( '{$name}' );
+ CKEDITOR.replace( '{$name}',
+ {
+ filebrowserBrowseUrl : '/index.php?q=imce&app=ckeditor|sendto@imceCkeditSendTo|params@',
+ filebrowserImageBrowseUrl : '/index.php?q=imce&app=ckeditor|sendto@imceCkeditSendTo|params@',
+ filebrowserFlashBrowseUrl : '/index.php?q=imce&app=ckeditor|sendto@imceCkeditSendTo|params@',
+ } );

And adding referencing the imce_wysiwyg js:

Change to civicrm/templates/CRM/common/drupal.tpl:

Code: [Select]

{elseif $defaultWysiwygEditor eq 2}
+    <script type="text/javascript" src="/sites/all/modules/imce_wysiwyg/js/imce_wysiwyg.js"></script>
    <script type="text/javascript" src="{$config->resourceBase}packages/ckeditor/ckeditor.js"></script>
{/if}

For absolute urls you can go to: admin/settings/imce under "common settings" choose the "Absolute Urls" option.

The bad news is that this will take affect site wide.

Perhaps one approach would be to drupal's IMCE module to allow configuration of this option per profile and then create a "mailing manager" role in Civi & Drupal with absolute urls enabled. Just a thought.

westy · September 13, 2010, 02:50:48 pm

Thanks to junglecoder and Ken I have now got CiviMail working with a file browser and we can now easily upload and use images in our emails
Similarly to Ken, in my Drupal environment, I'm using CKEditor but I use CKFinder as the file browser. This is still a test environment, but we are an organisation where only trusted and trained co-workers should be creating content.
• First, I got the Drupal side working with the Drupal CKEditor module and CKEditor. I then added CKFinder and got that working perfectly. Its important to get this sorted first as many people have had problems with this
• I also used the ‘Better Formats’ module and only allowed trusted co-workers ‘Full HTML’
• Like Ken, I also made 2 changes to the CiviCRM code; the first one identical to Ken’s,

i.e. Changing civicrm/templates/CRM/common/drupal.tpl to point to the Drupal CKEditor rather than the CiviCRM bundled copy
- <script type="text/javascript" src="{$config->resourceBase}packages/ckeditor/ckeditor.js"></script>
+ <script type="text/javascript" src="/sites/all/modules/ckeditor/ckeditor/ckeditor.js?I"></script>

• The second change was to the junglecoder code that Ken used for the Browser URLs in civicrm/packages/HTML/QuickForm/ckeditor.php
Mine was slightly different due to me using the default Drupal locations for CKFinder.

CKEDITOR.replace( '{$name}',
   {
filebrowserBrowseUrl : '/sites/all/modules/ckeditor/ckfinder/ckfinder.html',
filebrowserImageBrowseUrl : '/sites/all/modules/ckeditor/ckfinder/ckfinder.html?Type=Images',
filebrowserFlashBrowseUrl : '/sites/all/modules/ckeditor/ckfinder/ckfinder.html?Type=Flash',
   filebrowserUploadUrl : '/sites/default/files/',
   filebrowserImageUploadUrl : '/sites/default/files/',
   filebrowserFlashUploadUrl : '/sites/default/files/'
   });

So that’s it, it’s working, upload and browse for images in CiviMail. Now would someone like to point out all the security problems and, more important, how to fix them.

ken · September 15, 2010, 04:06:47 pm

@westy,

One security hole to check for is this: when forwarding CiviMails, does the HTML editor gives unauthorised people access to your file system.
A second is whether the HTML editor allows people to inject scripts into the HTML (the HTML should be filtered).
Do others have further suggestions?

Here's how to test...

Send a CiviMail to yourself which includes a 'forward' token
Log out from Drupal
Click on the forward link in the email
Edit the HTML
If you can access the file browser, you've got a security issue (people can get private information from your server). Can CKFinder be limited to users with certain roles?
If you can enter a script, such as the one below, you've got a security (?) issue (people can post nasties from your site: perhaps this is more a PR issue than a security issue). One way to solve this is to use the better_formats module to force all user roles to have "filtered HTML" input, except those roles which are editing content (who get "all HTML"). This module becomes part of core in Drupal 7.

Code: [Select]

<script type="text/javascript">
document.write("Hello World!")
</script>

Also, if you have user roles that should not have access to the file system, try logging in as such a person and see if you get access to the file system.

Ken

westy · September 21, 2010, 04:15:14 am

Thanks for your comment Ken.
I've just updated to CiviCRM 3.2.3 so had to redo the above changes and just got round to testing mailing and replying.

Point #1 I'm using better formats and filtered HTML in Drupal
Inserting your code snippet into a forwarding email window gave me the following;
"Sorry. A non-recoverable error has occurred.
There is a validation error with your HTML input. Your activity is a bit suspicious, hence aborting"
Now that seems to be what I want to happen so, on the face of it, I'm happy with that.
The second point i.e. browsing the file system is a bit more debateable
I, as a recipient of the email, can browse the image folder and from a purely technical point of view this is undesirable.
However, I have not been able to browse any other folders on my system using the CKFinder browser and the images in this folder are freely available to any recipient of our emails and are also available in our Drupal content. So far, I'm happy with that too. In our case, production of a news letter, it seems to make no real difference.

We don't have any really confidential information or financial details on our site. Anyone who does could investigate this further.[/list]

ken · September 21, 2010, 04:52:25 am

@westy,

@stoob made a post about security in ckfinder (it's an earlier post in this thread: http://forum.civicrm.org/index.php/topic,12091.msg57981.html#msg57981 ). He talked of changing "line 21" of a certain file, but didn't seem to (yet) have a fix: perhaps you can ask him if he's nailed it.

Ken

PS: post number 300! woohoo!

ken · September 21, 2010, 05:09:21 am

Folks,

In reply #30 on this thread I indicated I was looking for a way to force URLs of links to be absolute (ICME for instance gives you relative URLs if you're browsing for files to link to, or for images to use).

Rather than trying to find an editor solution, I've implemented a Drupal module that searches for relative URLs in emails, and replaces them with absolute.

It's called 'cbf' and here's the code...

Code: [Select]

<?php

/*
 *  This hook is called when an email is about to be sent by CiviCRM
 */
function cbf_civicrm_alterMailParams( &$params ) {
    /*
     *  Change relative URLs to absolute.
     */
    $htmlMessage = CRM_Utils_Array::value( 'html', $params );
    if ( $htmlMessage ) {
        /*
         *  Links:  Relative URLs start with a '/' and occur in the HREF attribute of an A element
         *  Images: Relative URLs start with a '/' and occur in the SRC attribute of an IMG element
         *  The '/' is replaced by the CiviCRM User Framework Base URL, which terminates with a '/'
         */
        $config = CRM_Core_Config::singleton( );
        $htmlMessage = str_replace(' href="/', ' href="'.$config->userFrameworkBaseURL, $htmlMessage);
        $htmlMessage = str_replace(' src="/',  ' src="'.$config->userFrameworkBaseURL,  $htmlMessage);
        $params['html'] = $htmlMessage;
    }
}

...it has a few limitations...

The module only currently alters the HTML message (haven't got around to the text message yet)
It will break if the text 'href="' occurs in the message text (it would be bizarre for us to send messages containing HTML code samples though!)

I hope this might be useful to others, and I'd be glad for pointers on how to improve it!

Ken

dpolant · October 08, 2010, 07:51:54 am

I confirm that leonard's solution works - thanks to him for figuring it out, seems like it took some digging ...

I solved the rest of this problem by editing civicrm/packages/ckeditor/config.js, adding

Code: [Select]

config.filebrowserBrowseUrl = '/index.php?q=imce&app=ckeditor|sendto@ckeditor_fileUrl|';
config.filebrowserImageBrowseUrl = '/index.php?q=imce&app=ckeditor|sendto@ckeditor_fileUrl|';
config.filebrowserFlashBrowseUrl = '/index.php?q=imce&app=ckeditor|sendto@ckeditor_fileUrl|';

... inside CKEDITOR.config = function (){ ... }

It took me a while to research a solution to ckeditor/imce/civicrm integration, and this was the thread that finally did it. Thanks!

westy · October 08, 2010, 11:47:13 am

@ ken

Thanks ,
Seems like a really neat solution to me.
Is this going to be incorporated in some future version or as an official module?
westy

ken · October 08, 2010, 11:23:04 pm

@westy,

Upon reflection, the hook I should implement is hook_civicrm_postProcess to catch the form containing the HTML email message before it gets saved. This would permit the URLs to be made absolute *before* the Text message is generated from the HTML message. I'll post it when I've modified it.

Ken

Donald Lobo · October 09, 2010, 07:49:02 am

any reason why you are not using the:

hook_alterMailParams

for altering the mail messages? that way you get all emails sent via the system

lobo

ken · October 09, 2010, 09:42:44 pm

@lobo,

I am currently using the hook_civicrm_alterMailParams hook. And I've realised I can continue using that.

My concern (expressed in the previous post) was regarding the text part of a message that is generated from the HTML: that if the HTML message contained relative URLs, that these would be converted to relative URLs in the text part.

Further testing shows this is not the case: if the civicrm_mailing row has a body_html of...

Code: [Select]

<p>this is a <a href="/sites/default/files/download/link.pdf">link</a></p>"
...then the corresponding row in civicrm_mailing_trackable_url has a url of...

Code: [Select]

http://www.example.com/sites/default/files/download/link.pdf
Thus, the code that generates trackable URLs converts relative to absolute URLs.

FatherShawn · October 15, 2010, 08:33:07 am

I've posted a wiki page for adding CKFinder using the modifications discussed in this thread and leveraging the same authentication code that the CKEditor module for Drupal uses. I hope it's helpful to others!

westy · October 17, 2010, 04:40:34 am

•   Thanks to FatherShawn for his wiki posting but I think there is an alternative, possibly more logical approach, as posted above by several writers, i.e. to use the Drupal text editor.
•   With standalone versions of CiviCRM it was obviously necessary for Civimail to have a wysiwyg text editor however, as the standalone versions are no longer being supported, It seems to me to be rather odd that CiviCRM should still use its own separate installation of CKEditor when one may already be available in Drupal.
(CKEditors’ predecessor, FCKEditor, is the sixth most downloaded Drupal module!)
•   One could argue that CiviCRM already packages CKEditor so why not use it, but that would mean two separate instances to upgrade which is not ideal. I also feel that installing the file browser in a totally separate directory is somewhat counter-intuitive.
•   There is now no default file browser currently packaged with CiviCRM but many people now use CKFinder in conjunction with CKEditor in their Drupal install. Why not then use this combination for CiviMail instead of adding a duplicate version? Apparently this was done in CiviCRM 2.x.
And rather than create a new image directory, why not share the Drupal CKFinder image directory for CiviMail images? The same images on the site are likely to be used in emails/newsletters and vice versa.

•   The CiviCRM Drupal install currently loads CKEditor into civicrm/packages.
Could not the CiviCRM installer script check if CKEditor/CKFinder is already installed in Drupal, if so use it and if not add “Do you want to add CKEditor to your Drupal installation?". The CKEditor/CKFinder package could then be installed and enabled in the …sites/all/modules/ directory, complete with the CheckAuthentication() function. Then changing civicrm/templates/CRM/common/drupal.tpl to point to the Drupal CKEditor would nearly complete the installation.

•   The only thing remaining would be for the install to add a new module as in ken’s post above to force Absolute URLs, an issue that does not appear to be addressed in the FatherShawn wiki.

•   Maybe lobo or one of the Civi gods might like to comment on the philosophical/architectural aspects of this approach.

It’s worth reminding people of Stoob’s post back in April “A story of woe regarding CiviMail, and the start of a discussion how to improve” http://forum.civicrm.org/index.php/topic,13232.msg63795.html
CKEditor may not be perfect but it appears to do the job better than the alternatives, as does CKFinder

For my organization CiviMail is the most important component. What’s the point in collecting all this contact information if we can’t easily send them a presentable Newsletter?

Donald Lobo · October 17, 2010, 07:34:47 am

hey peter:

your approach below sounds logical and fairly reasonable. You might want to consider a few things:

1. How to deal with this issue for Joomla. From an internal CiviCRM code, we should not care where CKE/CKF come from (this is most likely true right now)

2. I dont think the Civi installer should install other drupal modules. If we ship CKE/CKF for joomla, maybe drupal installs without CKE use the shipped version?

3. Would be great if you can contribute code that makes the above changes possible. We'll definitely be willing to consider and work with you it getting this part of a future version of CiviCRM. If interested ping us on IRC

lobo

CiviCRM Community Forums (archive)

News:

Author Topic: ckeditor config (Read 88862 times)

ken

Re: ckeditor config

looksystems

Re: ckeditor config

westy

Re: ckeditor config

ken

Re: ckeditor config

westy

Re: ckeditor config

ken

Re: ckeditor config

ken

Re: ckeditor config

dpolant

Re: ckeditor config

westy

Re: ckeditor config

ken

Re: ckeditor config

Donald Lobo

Re: ckeditor config

ken

Re: ckeditor config

FatherShawn

Re: ckeditor config

westy

Re: ckeditor config

Donald Lobo

Re: ckeditor config