Per field format settings with full BF options via CCK widget

Currently, you can not set the default format per field only per content type or globally. So you can force the user to use the default format but the default will apply to the body and all cck textareas in a specific content type.

I would love that feature as well though and if I get around to it, per field settings will be the highlight of a 2.x series. D7 is putting some good items in though that may beat me to the punch.

OK, thank you very much.

Hi, do you know when you will get around to this?

Unkonwn. It is not on the top of my list right now.

I required this functionality on a site I'm working on so I've worked up a patch for the module. The patch adds a new module "Better Formats CCK" that provides two new widgets for the CCK text module - "Text field using Better Formats module" and "Text area using Better Formats module". These widgets have a new "Input format settings" fieldset in the field settings which allows you to select the formats available for the field in the same way the original better formats module allows you to do this for different node types.

The patch makes two minor changes to the original code - both changed to create the admin form in the cck widget:
better-formats-defaults-admin-form.tpl.php
better_formats_defaults.admin.inc

The patch is based on Better Formats 6.x-1-0-rc3

Awesome. Thanks for working on this alexpott.

However, I am not confident I like the approach of a completely different field widget to accomplish this. A more transparent approach would be better I think.

What factors made you decide to use this approach?

I started out trying to do it without the additional widgets and got as far as getting the input formats selection on the existing text field widgets. So that was all working fine but then I had a problem actually limiting the formats to the chosen formats on the node edit form. I was trying to use form_alter to identify text field / text area elements on the edit form and then manipulate them using the existing better_format functions. This approach seemed quite inefficient. So I had a think and realised the simplest way would just be to provide additional widgets - which seemed to have the added bonus that the user is making a conscious choice to use a text field which (a) is formatted and (b) has the possibility of limiting format choices using the better format module. There also didn't seem a high price to pay as the ability to change the basic field information means that swapping between the widgets is quite simple - and therefore easy to apply the new widgets to existing cck fields.

Additionally - if the user can choose if the field is formatted you have issues as to whether or the better_formats options should be there. Having the extra widgets means you don't have this headache to which none of the solutions seems right, for example, do you show/hide the better formats fieldset based on the chosen option using javascript?- or do you only display it once the text field has been saved and formatted text has been selected?

Thinking about your question now... I guess I didn't think about the approach you've already implemented for text areas. How do the existing better_formats_elements() and better_formats_textarea_process() work? Does it replace the existing text area process function or are they chained together?

Looking at this patch more I see you have used the defaults setting by roles just like the global and content type defaults. This is definitely not how I planned to implement this feature, however, I do see some use cases people may want this for. My implementation and I think the more often use case will be just simply selecting the format that field is suppose to be.

In light of that, I think the seperate widget, for the multiple allowed with a default type functionality, is the right way to go. Here are some items that I see need worked on for this module:

1. Better module name: CCK is very generic and doesn't depict exactly what the module is for. The base BF module has CCK functionality. With that name it seems to the user that they need it for BF to work with CCK. Also we want to make sure it will be clear what it does vs the other type of implementation.
2. Code duplication: There seems to be a lot of needless code duplication in this module. Some of it is not needed at all as it is handled by CCK and some of it would be much better off making a couple changes to the base BF module to re-use the code there.
3. 2.x Rewrite: I want to leave 1.x as stable as possible and would include this functionality as early as 2.0. The 2.x series of BF is undergoing a major api rewrite (#371776: Break out format hook code). We will also need to convert this to that api once it lands. I will be posting a dev version soon. With this and the above code duplication efforts, this module should end up being a quarter the the size it is now.

Hi Dragonwise,

Thanks for the comments...

1. I guess a better name might be something like "Better Formats additional CCK text widgets" with a module name of something like better_formats_cck_text_add.module?

2. You've switched a light on in my head regarding the '#process' parameter! Two functions and 30 lines of code now down to just one function with 1 line of code... With regards to the changes to the base module I wanted to make a few changes as possible but of course it would nice to not have to replace all the 'node-' with 'cck-'

3. That makes perfect sense. I look forward to the dev version of 2.x - anything I can do to help or contribute to - let me know.

Yes, #process is the key here. And by using #process, no separate text field/textarea widgets should be required. Better Formats only has to store the settings for each field instance somewhere - ideally directly altering CCK's schema (i.e. columns) for the text field types, so the input format settings are retrieved directly with the field data itself.

Since this is an important feature for me, is it worth it to apply patch in #5 or should I wait for 2.x?

I wouldn't recommend using this as it will be quite different in its final state and there will be no upgrade path. Only use this if you know what you are doing and are willing to accept any and all consequences for doing so.

Using it on a dev site and giving feedback here is encouraged though.

Sorry for the non-constructive comment, but I'd love to see this feature implemented, so I'm subscribing...

Being able to both set allowed formats and a default format for each custom cck text field would be awesome!

well here are my 2 cents on this subject:
you have a content type with one or several cck text or textarea fields, so you'd usually have contemplate.module with these two to have a nice display of the outcome right ...

so let's suppose you're using better_formats.module on a per content type basis: now you have two different routes where things would go:

first one: the cck fields are less permissive(in use of tags) than the main body field, you can use the strip_tags function[strip_tags($string,'')] to let only the desirable tags emerge, a quick scroll down in the contemplate for the content type will show what the string variable for each might be(is :p) something usually like $ node->fieldname['view']

second and less probable one: the main body field is less permissive than the cck fields, you'd give the higher input format for the content type and strip the $ node->content['body']['#value'] accordingly...

so the general rule is to make the input filter the highest one needed for a field in the content type and strip others accordingly...

i think that this approach is more straightforward but it needs some work/code... now you can notify the user that the input of a certain will be processed in a different manner(advanced_help_injector.module anyone)

i vote against having input formats per field because it might/will cause cluttering problems, i'd like the keep this module as is(with some of the improvements proposed) but maybe the modular approach for features that is going to be taken (#378664: Break up features into smaller modules.) will alleviate my concers of this module becoming a potential clutter fest and i know it will ;)

finally i don't like the idea of hijacking threads :P but does any wysiwyg editor load(maybe on profile basis) into body/comment fields on a per input format used/defaulted basis, maybe some project related to this one tnx in advance...

enorp,

This functionality is a seperate module and there is no extra work that you are eluding to. Every field is already filtered separately we will just be adding some different controls to choose that format. Your method would actually the major long complicated way around.

And yes to your wysiwyg question. As the better formats project page lists, you need to look at WYSIWYG API module.

Not sure if this was said. In addition to this handy feature it would be nice if a field remembered the rich text enabled/disabled setting when you saved the node and enabled /disabled based on what it was when you last saved the node. So when rich text is disabled by default for a node type, but you enable it on a text box next time you edit the node, you see the rich text editor again an not html.

Thanks for great work on this module. It helps me a lot.

I've re-rolled the patch to create the per-field format settings against the recent 6.x-1.0 release of the better formats module.

Changes in this version:
1. The module is now called "Better Formats additional CCK text widgets" (better_formats_cck_text_add)
2. The module is now using the forms #process parameter to reduce the amount of code

@pjsz #16 - this sounds like a feature request to which ever wysiwyg module (probably http://drupal.org/project/wysiwyg) you are using rather than better_formats. Better_formats is not providing the enable / disable rich text editor functionality.

@alexpott, thanks. I posted at WYSIWYG here http://drupal.org/node/446586 .

Hi, could this be rerolled again against the latest RC2 please?

@minqensan: As mentioned above, this will be in the upcoming 2.0 release at the earliest.

Is #17 compatible with 1.1 version?

Probably not - hopefully will get round to re-rolling this weekend...

Why isn't this sub-module committed to the official project? It's really useful.

@anrikun Dragonwise has a good release schedule of improvements to the better_formats module and as he says in http://drupal.org/node/350696#comment-1652948 this will be in the upcoming 2.0 release at the earliest.

Rerolled patch against 6.x-1.1

jep, would be cool, too bad I can't test the patch (extra module) at the moment.

+1 subscribe

+1
subscribe

+1 subscribe
And thanks a lot to alexpott for the rerolled patch!

+1 great work
Subscribing

I've applied the patch at #25
tested this changing the creation format across several different node types for a multiline textarea and it is working perfectly.

Great module and great addition.

Patch at #25 applied and working well. Many thanks alexpott for this extremely useful interim solution.

i guess this is just for CCK fields and doesn't allow setting input-format/tiny-profile to the body field, title field or any other fields that are added by modules outside of cck?

i have been looking for the right solution to the question: "how do i control adding different Tiny profiles (ideally Tiny themes; but profiles to start with) to specific fields.

This module (and patch) seemed hopeful but i guess only does part of the story. The FCK Editor module does this with the idea of simply listing fields (any field, title, body, cck or any field added by other modules). But it's interface of adding this to the profile is a bit awkward (but maybe best solution since adding to field config form won't work as not all fields have this form) and also likely to be deprecated at some point by the WYSIWYG API module. Surprised this functionality isn't core to the W-API module; but perhaps in time.

For now i guess i may need to convert the module Tiny Fields that i created a ways back which does similar approach to FCK Editor module of simply listing fields that you assign to a specific Tiny theme (a tiny theme is a more complete configuration of Tiny beyond what W-API lets you define for a Tiny Profile). The advantage of a solution like widgets on cck field form is certainly easier UI; but sadly doesn't cover all fields. FCK Editor does at least provide the strings under each field you see on the site to let the admin know what to add to the list of fields - makes it somewhat easier.

Perhaps better UI is simply under manage fields tab: http://screencast.com/t/p0RXgFvqZm - although still nopt as broad an approach as what Tiny Fields and FCK Editor do since not all fields are even part of a node-type and therefore will never show under any Manage Fields form.

+1 subscriber. Great module and great patch imo.

The project page says this is scheduled for the 3.0 stable release, but some other posts say 2.0. Is there any chance to get this functionality already in 2.0? For me alexpott's version at #25 seems to work just fine (but I'd rather not keep on patching the module for a long time..).

The patch works extremely well for me. When are we going to see a 2.x branch? If it isn't going to happen anytime soon, maybe we can commit this code? This functionality is critical if you want to use WYSWIYG API (which you presently have to use if you want to use CKeditor).

+1
Subscribing

I'm amending my recommendation. It worked for me because it disabled the WYSIWYG editor from showing up. However, it did not actually use the filter setting I specified, rather, it used the site's default filter.

Needs work.

Changed title to actual feature and moved up to the 1.5 release in the roadmap.

Any estimated timeline on the roadmap?

This is a great addition tho the module. I'm using the latest patch against the CSV version of the module and have not noticed any problems so far - though I only installed it an hour ago. Looking good!

patch is not 100%.

I find that the CCK Defaults do not get saved. My field is shared across two content types if that makes any difference (I know that changes the way the field is stored in the database). If I set up the cck defaults per role and then save the field, my changes are not saved and when I go back in to reedit them, all are set back to Full HTML. Also, when I go to create a node, the Filtered HTML format is being used for the field, even though I have uncheck that Input format from the 'Allowed formats' checkboxes, and all of the defaults are set to Full HTML.

ok. seems that it does work, but... only if you have 'Control formats per node type' enabled. This is because of:

Also, I think that you should be able to set the settings per widget instance - not just per field... I think this would probably just mean appending the node_type to the type, so you would have ccc/field_name/node_type as the identifier, rather than just ccc/field_name

Also, widget settings should not be stored in a system variable 'better_formats_allowed_cck_field_name', but instead with the field itself using cck's native settings storage. To do this, I believe you need to implement hook_widget_settings_alter()

@mrfelton

I'm looking into the issues you've raised. One question... do you have the Control formats per node type selected on admin/settings/filters/settings?

This option appears to be required for it to save. If this fixes the issue I will look into why this is occurring and providing a solution.

@alexpott: see above for why it occurring (http://drupal.org/node/350696#comment-2361012)... Enabling that option does make it work, and I detailed the reason for that above.

@mrfelton

Thanks for your feedback. Here's a patch that addresses both the issues you raised

1. This patch now saves per field instance instead of per field
2. Now longer requires the per node type option to be selected (hopefully this was @kmonty's issue too)

Due to issue 1 being resolved if you apply this patch to a site which has already had a previous patch installed you will have to re-set up the defaults for your cck fields.

Are you using this module on a Concern site? I used to work there a while back would make me smile if they're still using my work :)

@alexpott: Thanks for that... better, but still saving the values into a system variable! Move that to the native cck field settings storage engine and we're away!

ps. yes, this is being incorporated into the next release of concern.net. What work did you used to do for Concern?

FYI, ther reason for wanting the settings stored in with all the other cck field settings is to make it fully compatible with features - so that when a content type is exported, all the settings go along with it.

Storing the settings in the cck instance is gonna be fun...

Actually thinking about this - do you think the per instance is the way to go here? Perhaps this should go into the global settings part of the page? Can you think of a use case for the per instance settings?

If they were part of the global settings they could still be saved in cck..

As for Concern... worked there for 3 years doing all sorts... just ask Naoise...

alexpott: I think it should be per instance rather than global. Shared fields get used in different content types in different ways and each instance should have its own configuration. I actually did this just the other day with imagecrop: http://drupal.org/node/654730

I basically copied the code from http://drupal.org/project/insert

mrfelton: isn't the required field setting being set on the global level annoying eh?

Looking at this further... making this exportable with the cck field is not going to be simple as the cck patch relies heavily on the existing code stores the default selections in a table and the available formats in a variable. The only way I can see to do this is to pass in some override values to the original functions or duplicate their functionality in the cck module.

@alexpott: See http://drupal.org/node/616496... the patch there already handles import/export of the database settings. If the fieldlevel cck settings were stored with the cck widget, they would be exported with the content type when that content type was included in a feature. Combined with the patch I mentioned, this would provide a full export of the settings.

And yes, the required field checkbox is very anoying to have as a global setting. I don;'t understand what that was done, but there must be a good reason no?!

@mrfelton - but am I right in thinking that that patch only solves half the better formats exportable issue as it's got the defaults covered but not the variables for saving the available input formats for each object whether it be a comment, node type or cck field...?

Perhaps the better approach might be to make the patch in http://drupal.org/node/616496 export and recreate the variables... then all the better formats settings become exportable rather than just the cck options?

@alexpott: yes, that's right, I think. That patch only covers everything in the database (defaults). Anything that is stored in a system variable is not covered. Which is why I think the cck widget settings moved to cck storage engine, where they should be (IMO), making them export and import with the cck field.

As for the other things that are currently stored as system variables (available input formats for nodes and comments) - Can they somehow be stored along with the node too and then exported/imported with the content type? System variables feels like the wrong place for storing these settings, unless as you say, there is a method to import/export/recreate them.

Apparently, version 2 of http://drupal.org/project/strongarm deales with import/export of variables via ctools and integration with features...