We are trying to export wysiwyg settings using ctools: #624018: Exportables and Features support for WYSIWYG 7.x

One of the issues that we have is:

dagmar - November 23, 2009 - 02:00
Yes this is an excellent feature. But, if settings of wysiwyg are related to an input format, export settings will mean export the input format too?

rickvug - November 23, 2009 - 05:31
@dagmar You bring up a good point. Especially since input filters are set numerically, making them problematic to import and export reliably. I'm hoping that this is not the case in D7 seeing as how much of the filter module API has changed. The Exportables project may be a good place to tack on an exportable API for this. If not, WYSIWYG could always implement its own work around. In the end, I would hope that this complication doesn't side track any incremental improvements. WYSIWYG configuration exportables would still be helpful for install profiles and other use cases without input format exportables.

Wysiwyg shouldn't depend of Input Formats module. Instead of that, we should provide hooks from wysiwyg to allow to modify the exported code, the dependencies when a feature is created, and the imported code.

Following this approach, this would be the workflow when a feature is created:

  1. Wysiwyg export its settings using ctools.
  2. hook_wysiwyg_export_settings() is called
  3. Input formats implements this hook and modify the numeric ids with the machine name.
  4. hook_wysiwyg_feature_dependencies() is called.
  5. Input formats add itself as a dependency.
  6. The feature is created using a machine name

When the feature is installed.

  1. hook_wysiwyg_import_settings() is called
  2. Input formats load the numeric id using the machine name, and replace in the imported code.
  3. The import continues as usual.

So, once ctools export be committed, input formats should implements this hooks in order to provide features with machine names.

Comments

dagmar’s picture

dagmar
Primary language Spanish
Location Argentina
CreditAttribution: dagmar commented
Status: Active » Fixed

Committed. Requires this patch http://drupal.org/node/624018#comment-3070176 to work.

Status: Fixed » Closed (fixed)

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

xgmorkx’s picture

xgmorkx CreditAttribution: xgmorkx commented

Am I correct if I presume that the patch in this comment http://drupal.org/node/624018#comment-4068830 is the final solution for this problem in D6?

Which implies:
- This patch is actually for the wysiwyg module 6.x-2.3, in combination with Exportables 2.x and CTools 1.7 (or higher?).
- Furthermore, there's the possibility to use the input formats module to associate the wysiwyg settings with the correct input format on importing/exporting.

It could be interesting to elaborate on the "This module is working properly together with #624018-100: Exportables and Features support for WYSIWYG 7.x." on the project page since that thread is getting a bit bloated of patches and information on both D6 and D7?

EDIT: changed comment-4033330 to comment-4068830

mxmilkiib’s picture

mxmilkiib CreditAttribution: mxmilkiib commented

I'm currently trying to get this to work using the slightly later patch on #1060846: Exportables and Features support for 6.x, but so far my problem is that the Input Format part of the Feature is overridden by default on a new build, loosing the wysiwyg_imageupload ('Drupal Wiki inline-images') and image_resize_filter that are also set for Filtered and Full HTML, though unoverriding back to the Feature default resolves this.

I don't understand PHP well enough to dive into the code, but possibly the patch I'm using causes this, though I will try looking at the Feature code to see if shuffling around the order of things resolves this, else try the patch noted in #3.

(n.b., I'm using Exportables 6.x-2.x-dev, Input Formats 6.x-1.0-beta6, Wysiwyg 6.x-2.3, Strongarm 6.x-2.0)