Comments

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.

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.

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

Status:Active» Needs review
StatusFileSize
new9.7 KB

StatusFileSize
new9.69 KB

Fixed trailing white-space.

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?

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

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

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.

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.

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(),
  );

um, that snippet contains bugs. See http://drupal.org/node/224333#text_format

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 http://drupal.org/node/224333#text_format I'm not sure where $edit is coming from.

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.

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?

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...

StatusFileSize
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.

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.