jurgenhaas’s picture

Yep, WYSIWYG is no longer working with the latest D7 dev, there is no '#text_format' field anymore, so wysiwyg_process_form() doesn't add the editor to the page anymore.

sun’s picture

Righto. :) So finally Drupal core can claim "better wysiwyg support" :-D

Our entire logic needs to move into hook_element_info_alter(), assigning a #pre_render for $type['text_format']. All that's done there is to iterate over the available formats, load the profiles, etc. Therefore, gazillion lines of code become ~20.

Note: Also account for the possibility that the textarea may be disabled due to #91663: Permission of text format is not checked when editing an entity and instead reset to something a user can use. -- in that case, we don't load anything at all.

jurgenhaas’s picture

In other words that requires an update for the WYSIWYG module, right?

sun’s picture

Status:Active» Needs review
new9.7 KB
sun’s picture

new9.69 KB

Fixed trailing white-space.

jurgenhaas’s picture

Not sure what else I should do, but so far it's not working to me. I've applied the patch, re-saved the wysiwyg profile and flushed all caches. But when going to /node/1/edit I still do not get back the WYSIWYG editor for the body.

Is there anything else I need to do?

sun’s picture

Nope, it at least worked for me on node/add/article

Only remotely related: #741606: Teaser splitter / text fields with summary support (@Jacob)

jurgenhaas’s picture

Can't get it to work. There is not even any js file loaded from the wysiwyg module and also no Drupal.settings.wysiwyg is available. I suspect that the function wysiwyg_load_editor($profile) doesn't get called.

jurgenhaas’s picture

Strange! I've now put some debugging code into the module and suddenly the editor appeared, no idea why.

Now, on to the next area of interest: is there a quick hint on how to define my own form for a textarea that should also load the editor? I guess that's changed now significantly.

jurgenhaas’s picture

Got it, a sample for the new textarea definition looks like this:

  $form['field1']['editor'] = array(
    '#type' => 'text_format',
    '#base_type' => 'textarea',
    '#rows' => 5,
    '#default_value' => '<p>Text</p>',
    '#format' => filter_default_format(),
sun’s picture

um, that snippet contains bugs. See

jurgenhaas’s picture

Not sure what you mean? The only difference is that '#format' should get NULL assigned to it instead of the filter_default_format() but in the end that doesn't seen to make a difference!? In I'm not sure where $edit is coming from.

hefox’s picture

Patch worked for me after clearing cache (well, installing admin_menu to get my cache clear link) without any other actions.

edit: sun had me do more testing, does not work for only 1 allowed input format.

JacobSingh’s picture

Hmm... I'm confused. IT works for me (more or less), however the input filter I've selected seems to be getting saved incorrectly because it is not being applied when I view the content. Also, the help text for it seems wrong...

What am I doing?

talkingwires’s picture

The patch works for me, too. Just make sure to go under Configuration/Development/Performance and clear the cache. I'm still setting up my Input Formats, so I can't comment on the issues people are reporting with them...

TwoD’s picture

new9.67 KB

Just a quick change.

+++ wysiwyg.module 13 Mar 2010 17:45:26 -0000
@@ -106,97 +97,98 @@ function wysiwyg_form_alter(&$form, &$fo
+    $format_field['format']['guidelines']['format'] = array(

Is now $format_field['guidelines']['format'] (in both instances) and now editors work when there is only one format as well.

Powered by Dreditor.

sun’s picture

Status:Needs review» Fixed

Thanks for reporting, reviewing, and testing! Committed to HEAD.

A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.

Status:Fixed» Closed (fixed)

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