Input Filter

What for? Suppose form should be easy-readable but if you need a special it's possible to form_alter + theme

I turned on default and it does not load the wysiwyg filter in...

That only sets up the input format. as for setting up the wysiwyg, you need to somehow tell wysiwyg to show an editor for the relevant text areas. Not a problem with privatemsg.

I assume this is because the privatemsg textfield is not connected with a "filter widget/chooser", so it is not recognised by wysiwyg.

We may add full input format support at some time, but I don't consider it a high priority. Especially since it might just work (Fields..) with D7.

Ok, here is a first working patch, please test and review...

- Adds a format column to the pm_message table, including upgrade path
- Adds an input filter selector to the new/reply form
- I noticed a strange behavior when I added the filter after the body in the code, the resizable stuff broke, and the body was only 10 cols wide, so I removed that definition. This also fixes that bug report #513656: ie8 shows to small message box if JS Optimizing is on
- It works perfectly fine with wysiwyg now..
- No configuration yet, maybe we need to add some settings (allow/disallow)
- Should also work with the API

Very nice. I did a quick review and things look good for the most part.

Little change in my patch is loading pm.format in privatemsg_sql_load(), without it we get notices that $message['format'] is not a valid index on line 427.

Each filter is per message which made me rather enjoy playing with thread view by refreshing it with a message having this body:

<?php print "hello world ". time() ; ?> // :-D

Review action point: We need to find other places where we may be missing to load pm.format.

I'll do another review later with different wysiwyg editors as i dont have any installed yet.

the format column is not included in privatemsg_schema(), so this will fail for new installs. Also, would we need some sort of updated index for this?

Also, an unrelated doc issue that can be fixed here:

function privatemsg_sql_list(&$fragments, $account, $argument = 'list') {
  ...
}

/**
 * @addtogroup sql
 * @{
 */

^^ That comment should be moved to before the sql_list function (and a second comment to define that query should also be added). May not be for this patch though.

apart from that it looks good.

When this goes in, pmgrowl will need to be updated to allow for the greater choices of input format.

patch rolled to fix the above.

Thanks for the re-roll.

That happens if you drink beer between writing, testing and uploading a patch. :)

I wa meant to set this to rtbc, not the other issue.

rerolled.

How many people actually using this patch on their live site ?

I plan to try it in near feature, because I want to switch from fckeditor module into Wysiwyg module, and without this input filter I can't have wysiwyg editor on private message textarea.

@igorik : Do it soon please. We need live site testers to make sure things work as expected, otherwise it stalls this patch from being committed.

Hi Litwol,

I just patched it and testing it. It seems that it works fine. Thanks.

I have some "design bug", I am using better_formats module which can hide format selection fieldset, info about formatting and more else things.
It is handy module. But now I can see under privatemessage textarea collapsed fieldset for choosing text format.
(screenshot attached)
So I have correctly hide this info on all edit pages with textareas on site except privatemsg textareas.

The permission for better formats are:

collapse format fieldset by default	
collapsible format selection	
show format selection for blocks	
show format selection for comments	
show format selection for nodes	
show format tips	
show more format tips link

There will be probably needed to create a new permission "show format selection for private messages", I think. Do you think that it is work for Better formats module developer, or it will be permission hook in private message module?

thanks and have a nice day
Igor

Well, that's not a design bug, that is simply a missing feature :)

I thought about adding a permission too, but adding it to better_formats does probably make more sense if they are willing to add it. You could create an issue there and cross-link it.

I added a feature request for better_formats for hiding fieldset select format on privatemessage textarea.
http://drupal.org/node/581308

Back to original issue - new privatemessage support for input format works very well.
Thanks

I've just applied the patch and it works quite well. The only problem I've encountered is that all 2000 old messages input format was set to "0" (while previously it was used the default input format: Filtered HTML.

Integrating this patch taking care of better formats (or modify better formats for this patch) would be very useful.

This should not happen, it is supposed to use the current default format for those existing messages. I'll look into it.

Uhm.

It is working fine for me and it's pretty much the same code as system_update_6051() which added the signature_format column.

I'm guessing you have never actually saved the default format form, so variable_get() is using the default value. I updated it to use 1 instead of 0.

Can you remove the pm_message.format column and re-run the 6004 update? It should update the format column to 1 then.

Any time you use the FILTER_FORMAT_DEFAULT global you need to wrap it in filter_resolve_format(). That will get the site default when it is set to 0.

$site_default = filter_resolve_format(FILTER_FORMAT_DEFAULT);

I am using this patch.

as per #24

check_format() already uses filter_resolve_format(), that means we should probably revert to 0 as default value

The question is, what should happen if you change the default format? If 0 is used, all messages will use the new default and if 1 is used, they will still use the "old" format. Not sure what is correct, new messages *will* store the actual value and not 0.

@Berdir - that should not be aproblem as at the time of update the messages would be broken anyway if the format had been changed to something incompatible. Not our problem IMO.

Setting this back to rtbc after some discussion on irc.

I think it best to get this committed and if there are problems, they can be fixed once discovered.

Fixed in 6.x-1.x-dev.

Porting this is a bit more complicated than other things as there were quite a few changes to filter.module. If someone does test this, note that there are currently a few bugs in the 7.x-1.x-dev version because there were changes in Core (for example, autocomplete does not work because drupal_json() was removed)

Edit: The attached patch should work, but note that there is currently no update functions, since I would say that we should currently not support 7.x -> 7.x updates as core doesn't do it either right now. And all users upgrading from 6.x will already have the format column.

Reopened issue in better_formats queue #581308: support for hiding info about select format for private message textarea

agreed at the lack of need for an update function for this.

Added to 7.x-1.x-dev.

Is this patched in 6.x-2.x-dev?

It would be nice if the default field "body" could support better format module ...
It is not possible de mange body field settings...
:'(

@Jarode #36 Do not re-open old issues if the fix was correct (which in this case it was). If you have a new but related issue, open a new issue.