Download & Extend
CKEditor - WYSIWYG HTML editor » Issues

Profile loses text formats when exported into a feature using Drush

Posted by hctom on November 29, 2011 at 5:03pm
Project:CKEditor - WYSIWYG HTML editor
Version:7.x-1.x-dev
Component:Code
Category:bug report
Priority:major
Assigned:Unassigned
Status:closed (fixed)
Issue tags:needs security review

Issue Summary

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

Login or register to post comments

Comments

#1

Posted by hctom on December 7, 2011 at 5:16pm

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

Cheers

hctom

#2

Posted by mkesicki on December 8, 2011 at 7:43am

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

#3

Posted by Coop920 on December 8, 2011 at 8:07pm

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.

#4

Posted by hctom on December 8, 2011 at 10:12pm

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?!

#5

Posted by hiphip on May 18, 2012 at 1:53pm

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.

#6

Posted by schultetwin on May 24, 2012 at 1:26pm
Version:7.x-1.6» 7.x-1.9

Still an issue for me as well.

#7

Posted by _tychris on September 4, 2012 at 8:45am

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

#8

Posted by mbruneel on October 21, 2012 at 7:02pm

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

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

Thank you _tychris!

#9

Posted by Volx on January 25, 2013 at 12:25pm

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.

#10

Posted by Volx on January 25, 2013 at 1:13pm

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.

AttachmentSize
ckeditor-drush_features_export_fix-1356026-10.patch 1.53 KB

#11

Posted by lundj on February 5, 2013 at 11:44pm

#10 works pretty well for me!

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

#12

Posted by SebCorbin on April 3, 2013 at 4:23pm
Version:7.x-1.9» 7.x-1.x-dev
Status:active» reviewed & tested by the community

Works nicely here

#13

Posted by yched on April 3, 2013 at 4:52pm

Agreed on the issue and on the fix :-)

#14

Posted by yched on April 3, 2013 at 7:35pm
Priority:normal» major

Seems pretty important too...

#15

Posted by jcisio on April 4, 2013 at 6:33pm
Status:reviewed & tested by the community» fixed

Thanks. Committed patch #10.

#16

Posted by System Message on April 18, 2013 at 6:40pm
Status:fixed» closed (fixed)

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