Hi @all,

I just mentioned, that the associated text formats get lost when an editor profile is exported by using the the drush fu feature_name command. On the other hand, everything works fine using the features UI.

Is this a feature module error or is something wrong in the export hooks of the CKEditor module?

Thanx in advance & cheers

hctom

Comments

hctom’s picture

Any news on this? Or can anyone confirm this problem?

Cheers

hctom

mkesicki’s picture

We will check this ASAP. Please be patient. Maybe some else can confirm this issue. Thank you for report this.
Please try latest DEV version and check if the problem exists there

Coop920’s picture

How are you able to export the wysiwyg profiles? I'm trying to find the component to be added to a feature and can't seem to locate anything. Can you advise? Thanks.

hctom’s picture

Hi Coop920,

I configured my global CKEditor profile to have the right paths. And after that all profiles (including the ones that get installed by default) were exportable with the ckeditor_profile component.

Here are the steps I performed to create the feature:

  1. Created a feature module using the administration interface and added my CKEditor profiles (while one of them was associated with a text format) to feature
  2. Changed my CKEditor profile (e.g. available buttons)
  3. Updated my feature using drush fu feature_name
  4. RESULT: Associated text format definition is missing in the export code of the feature's feature_name..features.ckeditor_profile.inc file

Hope this helps?!

dxvargas’s picture

I also have this problem with latest versions:
Drupal 7.14
CKEditor 7.x-1.9
Features 7.x-1.0-rc2

After drush fu feature_name, input_formats array is now empty and feature says it is overriden.

Moreover, if I now do drush fr feature_name, I get a "Current state already matches defaults, aborting." but feature still says it is overriden.

schultetwin’s picture

Version: 7.x-1.6 » 7.x-1.9

Still an issue for me as well.

_tychris’s picture

I think to resolve your problem via drush you can add argument "--user" :
drush fu feature_name --user=1

mbruneel’s picture

I confirm the issue (with 1.9 and -dev).

Adding --user=1 works. IMHO, that should be documented.

Thank you _tychris!

Volx’s picture

I am having the same issue, --user=1 helps, but it doesn't really solve the problem. This should not be documented but instead be fixed. I never needed this flag for any features export and I don't see any reason why it should be necessary here.

Volx’s picture

And here is the fix :)

The problem is that ckeditor_profile_load checks the user's access to the filter formats. I added a parameter $check_access and set that to FALSE on features export. Default is TRUE so it should be fine security wise whenever the function is called somewhere else. I have never seen access checks on other features exports.

lundj’s picture

#10 works pretty well for me!

A very important patch in my opinion.
Could this be included in the next release?

SebCorbin’s picture

Version: 7.x-1.9 » 7.x-1.x-dev
Status: Active » Reviewed & tested by the community

Works nicely here

yched’s picture

Agreed on the issue and on the fix :-)

yched’s picture

Priority: Normal » Major

Seems pretty important too...

jcisio’s picture

Status: Reviewed & tested by the community » Fixed

Thanks. Committed patch #10.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Kristina Katalinic’s picture

this is still not resolved. Regardless of whether the feature was created using features UI or drush exported feature will show as "overridden" on the new site created using custom installation profile

here is the diff

DEFAULT	OVERRIDES
CKEDITOR_PROFILE
Line 1	Line 1
 	
array(
 	
array(
 	
'EzyWYSIWYG' => array(
 	
'EzyWYSIWYG' => array(
-	
'input_formats' => array(
 	 
-	
'ezy_wysiwyg' => 'Ezy WYSIWYG',
 	 
-	
),
 	 
 	
'name' => 'EzyWYSIWYG',
 	
'name' => 'EzyWYSIWYG',
 	
'settings' => array(
 	
'settings' => array(