WYSIWYG integration

I was able to get the WYSIWYG editor (WYSIWYG module with TinyMCE) to show up on the edit form just using hook_form_alter() in a custom module:

function mymodule_form_statuses_box_alter(&$form, &$form_state, $form_id) {
  $form['fbss-status']['#type'] = 'text_format';
  $form['fbss-status']['#base_type'] = 'textarea';
  $form['fbss-status']['#format'] = NULL;
}

Changing the input format caused $form_state['values']['fbss-status'] to change from a string to an array (as expected):

[fbss-status] => Array ( [value] => [format] => filtered_html )

But the problem was that "value" submitted was now empty. I believe this is due to the interaction between the Javascript used by Statuses to submit the form and the WYSIWYG editor. If this could be worked out, it seems like it would work.

I'm going to mark this as postponed because I'm not intending to put any new features in the 7.x-1.x branch, but I'm happy to try to answer questions or otherwise help this along if possible.

I have two concerns here:

• Some people with a WYSIWYG module enabled might not want the status update form to be WYSIWYG-enabled, so there should be an option for this -- but at the same time the option shouldn't show up for people who don't have WYSIWYG modules installed.
• Status updates currently only support a single input format, and even if multiple formats were supported I wouldn't want the input format selection fieldset to show up on the status update form.

I'm interested in the idea of supporting multiple input formats, although that probably belongs in a separate issue.

The problem was that "value" submitted was now empty. I believe this is due to the interaction between the Javascript used by Statuses to submit the form and the WYSIWYG editor.

To confirm this, try turning off submitting via JS in the module's advanced settings. I am not aware of anything that would cause this issue, even in JS. In D7 most of the JS stuff is handled by core.

By the way, the format used for status updates is variable_get('statuses_filter', 'none').

When I turned off submitting via JS in the Statuses configuration and tried it with TinyMCE again, the value of "fbss-status" was submitted correctly.

[fbss-status] => Array ( [value] => <p>My status text.</p> [format] => filtered_html )

So, the problem does appear to be the interaction between the Javascript used by Statuses to submit the form and the WYSIWYG editor.

I know that this is a very old issue, but since we had the same need to use the CKEditor within the statuses and comments, I've created a patch that could be helpful for someone else. I've tested it only with the CKEditor.

@nibo I applied your patch, but it is not showing ckeditor toolbar on status form. I downloaded ckeditor module and ckeditor library as well. The toolbar is showing on a content type, but not on statuses form.

I also installed wysiwyg and used ckeditor library to make sure. I also tried tinymce, but nothing worked for me. This will be a great great feature. I am using statuses dev version.

Hey ugintl,

the patch was specific to the problem for statuses not getting submitted when using WYSIWYG editor.

You can add the WYSIWYG editor to the statuses forms by using hook_form_alter() in your own module, something like this:

/**
 * Implements hook_form_alter().
 * Adding WYSIWYG editor to statuses
 */
function MYMODULE_form_alter(&$form, &$form_state, $form_id) {
  switch ($form_id) {
    case 'statuses_box':
      $form['fbss-status']['#type'] = 'text_format';
      $form['fbss-status']['#format'] = 'filtered_html';
      break;
    case 'fbss_comments_edit':
      $form['status-comment-edit']['#type'] = 'text_format';
      $form['status-comment-edit']['#format'] = 'filtered_html';
      break;
  }
  if (substr($form_id, 0, strlen('fbss_comments_box')) === 'fbss_comments_box') {
    $form['status-comment']['#type'] = 'text_format';
    $form['status-comment']['#format'] = 'filtered_html';
  }
}

Thank you for your comment. Few days ago found something and just replaced 'textarea', with 'text_format', like this

$form['fbss-status'] = array(
    '#type' => 'text_format',
    '#rows' => variable_get('statuses_box_rows', 2),
    .........
);

and it worked. However, it was not submitting as you mentioned above because I first applied your patch and then removed it. Do I have to put this code #9 in statuses.module or statuses.form.inc?

See my question on stackexchange

http://drupal.stackexchange.com/questions/225559/enabling-text-editor-on...

Just in case you or anybody else needs it. I was not able to log the activity when statuses is liked as It is not an entity. So I found a patch and it worked. However, I am still using it with flag 2. Tried a lot, but cannot use it with flag 3. Atleast now I can log flagged statuses using rules and message module. There is one more problem, but I guess it is not much of an issue. The statuses events are listed twice in rules. Everything is working perfectly for me though. If anybody wants, I can upload my statuses.module, fbss_flag.module and fbss_comment.module files

hi
@nibo many thanks .. For WYSIWYG , your #9 code + the #5patch make it worked for me.

But for anyone reading, for security reason i think having a strict customized/configured text_format may be helpful .. which mean that it could be a good idea to create a new status_text_format (to be used in @nibo 's #9 code as replacement of filtered_html ) ...

Thanks