To answer your question about how to modify CKEditor's config.js:
You need to "hack" the config.js file within CiviCRM itself (packages/ckeditor/config.js). Editing this file will modify all instances of CKEditor in CiviCRM (angular and quickform add a few additional settings related to file uploads but they do both respect that file). If you don't ...
There's an issue+patch filed for 4.6.1 at https://issues.civicrm.org/jira/browse/CRM-16246. You can try disabling Drupal's aggregation as a work-around (by visiting "admin/config/development/performance"). If that work-around doesn't resolve it, let us know (since that would mean it's a different problem).
The editor includes a "Source" button which can be used to edit markup directly.
Upgrade to v4.7!
CiviCRM v4.6 includes a pure-JS rewrite of the CiviMail frontend. Unfortunately, the old WYSIWYG abstraction couldn't adapt well to pure-JS, so CiviMail in v4.6 only supports one editor. (Specifically, CiviMail ...
Go to Admisister > Customize and Data Screens > Display Preferences
Scroll down and click the Configure CKEditor Button
In the space for "Plugins" Find "Justify" and save it. While you are at it, add "colorbutton" and "font"
Based on the screenshots it looks like you've installed WP in it's own directory as opposed to the web root.
Starting in Version 4.7.27 CiviCRM will detect if WP is installed in it's own directory
So on new installs we will see a new section in civicrm.settings.php:
// Additional settings generated by installer:
Well, it works again through magic and voodoo.
All I did was go to the Wordpress Access Control page as Christia recommended and clicked "Save". I didn't modify any settings. Just clicking "Save" seems to have reconnected everything.
When CiviCRM is on Pantheon, it needs a special set of config in the civicrm.settings.php which defines various variables to make CiviCRM work in cloud hosting.
I had to add this variable to that list:
$civicrm_setting['URL Preferences']['imageUploadURL'] = 'http://www.mysite.com/sites/default/files/civicrm/persist/contribute/';
Then I had to make sure ...
My understanding is that the new CiviMail approach necessitated disabling the "use CMS default" option for WYSIWYG. The new preferred approach is CiviCRM extensions to implement other WYSIWYG editors - it took about an hour to create the first WYSIWYG extension for CiviCRM, and others can build even quicker, using that extension as a guide. You can find it ...
What WYSIWYG editor are you using? IF CKEditor, reestablish roles and permissions for the CKEditor by going into the configuration settings for text editors on your CMS side and make sure it's still set as the default editor. This is what I had to do after updating to 4.7.15.
Here is a screenshot on Drupal to give you an idea of what I mean. If someone can ...
Not exactly, but I've seen WYSIWYG having problems on one of our sites due to incorrect loading of [cms.root] token in Resource URL. To check what's wrong.
Look for the token populated by clicking on the small help icon on civicrm/admin/setting/url?reset=1 (Administer -> System Setting -> Resource URL).
Similarly on civicrm/admin/setting/path?reset=1 (...
Thank you @demerit and @jitendra for your help!
It turns out, the answer is: don't change the label for the Incoming Email activity type :).
The user changed it from Incoming Email to just Email. Changing the label should definitely not break things - but since this issue is still open, it does.
So, in the short term, I'll change the label back. In the ...
Editor can be disabled completely by the following
Administer > Customize Data and Screens > Display Preferences.
CKEditor can be changed to TextArea
For specify Action
Editor can be disabled before editing the template using SQL
civicrm_setting table holds the ...
CiviCRM Starterkit is installed as a Drupal installation profile, so it's got the civicrm module directory inside /profiles/civicrm_starterkit/modules rather than /sites/all/modules. CiviCRM is assuming that you can go up two levels from the folder where it's currently running and then over to the default folder to find civicrm.settings.php. That's not the ...
JQuery update settings:
Set alternate jQuery version for admin pages to: 1.5
Make sure CiviCRM theme module is installed
In Appearance -> set CiviCRM Administration theme to Adminimal (or some other Admin theme)
You’ll want admin jquery 1.5 for many admin pages on your drupal site to work well. Here’s a reference: https://www.drupal.org/project/...
Ah, I've figured out the problem after looking at the code in ./sites/all/modules/civicrm/CRM/Admin/Form/MessageTemplates.php. The WYSIWYG editor is only shown if the message template is not a system message
Well, finally managed to get CKEditor going, but this is far from an ideal solutuion. The problem is that an extra component is being put into the URL for the editor. My main site that works is mysite.org and the problem is with test.mysite.org. This has all its files in a subdirectory of the main site and this confuses things. Looking up [civicrm.root] in ...
Thanks Jon G, for steering me in the right direction and hopefully this might help someone down the line.
I probably wasn't particularly clear in my description in that I run a Drupal multisite but CiviCRM is still running under it's original single site (although this is bringing me a step closer to having all the sites run CiviCRM especially for webform ...
The settings_location.php file should not normally be required, but an example is described at:
The file civicrm.config.php should be able to handle bootstrap in most common configurations without settings_location.php. However, this depends on having somewhat plain/predictable ...
I'm afraid the answer is "no you can't configure that to allow HTML tags". If you need lots of Help text put most of that into the 'Body' on the Event Info and/or Event Register and/or Contribution pages - keeping the help text nice and short.
Since you are using 4.6, the answer is that you need to ensure templates/CRM/common/wysiwyg.tpl is being loaded and that the smarty variable $includeWysiwygEditor is set to true.
Or since you are hacking around CiviCRM anyway, just keep it simple and stick something like this in your page source:
You're right, it was a bug. Here's a fix for 4.7.
The code in 4.7 is a lot cleaner than 4.6; I don't think fixing it in 4.6 will be a priority for the core team.
CiviCRM 4.1 is not maintained and highly insecure. Unless you have manually backported every security patch on this list plus the relevant ones on this list then you are strongly recommended to upgrade to a supported version. Recent versions, incidentally, ship with TinyMCE.
The TinyMCE editor extension is only for CiviCRM 4.7+ so is not applicable to your situation.
Answering the question of how to install the TinyMCE editor extension: It's marked as compatible with CiviCRM 4.7+. I'm guessing it relies on functionality that doesn't exist in the current version of CiviCRM - but you could always e-mail Tyrell directly and ask him.
Assuming it works - it's submitted to the CiviCRM extensions directory, but hasn't been ...