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.

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.

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 .

@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:

function better_formats_get_default_format($mode, $node_type = '') {
  static $format;

  // Default our type to the mode (node or comment).
  $type = $mode;

  // Check if per node type is enabled and set type accordingly.
  $per_node_type = variable_get('better_formats_per_node_type', FALSE);
  if ($per_node_type && $node_type) {
    $type = $mode . '/' . $node_type;
  }

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

Hi, which patch is best to use with version 6.x-1.2?
#45?
Thanks

Can anyone confirm that patch #45 will work with 6.x-1.2?
Thanks, Nick

I have changed up the roadmap in light of #720278: better_formats overrides CCK default values..

I will be helping to work on this CCK widget module to get it production ready and be posting a 2.x dev version that it will be a major part of in the coming weeks. Once we have this module ready with sufficient testing and simpletests, BF 2.0 will be the stable recommended version.

subscribing. I'm using patch 45 with 6.x-1.1, but haven't tried 1.2 yet sorry (@nickrice)

Here's a patch that cleanly applies against 6.x-1.2

Additionally adds a warning if the cck widget is used and the "Control formats per node type" setting is not enabled which makes configuration a bit simpler.

(subscribing)

#59: Thank you very much for this updated patch alexpott!

(subscribing)

Subscribing.

Hope I find the time to test this over the easter days.

deleted

Hmmm. Our requirements have expanded somewhat - I'm finding that implementing this patch and using the extra CCK textarea widget has an unexpected side effect - it does not allow a user with suitable permissions to switch the input format. The entire "input formats" fieldset is missing from the node edit form.

Not sure what I'll do here, I need to be able to:

A - set different default input formats per node type (ie the node body)

B - override that default format per-CCK-textfield (intro, caption, etc) in the node type

C - allow admin users to override the input format on any of the above

D - use a wysiwyg editor (wymeditor), filtering the available wysiwyg tools as appropriate for the selected input format (this is working but better formats or this patch does seem to make it twitchier).

B and C are mutually exclusive?

No, 2.x dev has the modified code from this patch. More commits on it to come this weekend.

Allright, applied patch at #59, works nicely.
Thanks for that!

Will this patch be committed?

I also applied patch at #59 to version 1.2 and it works great!

This patch makes Better Formats a perfect solution!

Thanks, alexpott. Thanks to your patch (#59), and the excellent Better Formats module, I can finally start using WYSIWYG.

subscribe

subscribe

Tracking.

#71 - great that some people feel this makes WYSIWYG now a usable solution; personally, sadly, i think we are still a few steps back from D5 and the much simpler FCK module where you could assign different editor setups to ANY text area on your site. I am still fairly sure (but hopefully wrong) that there is still no solution to assign js editor to non-cck fields.

i do need to check out the latest work here though for sure but i think the UI for this is still a bit convoluted as there are completely different places to define editor for Body as there for a cck field (and in total maybe as many as 6 admin pages to go through to configure). However, I guess this is only complicated for site admins to set up (as opposed to the user). But i most devs i know are still scared to attempt using WYSIWYG due to setup complexity.

sorry for the rant... certainly lots of good work going on here and i do believe in the W-api strategy (i manage the Autosave project and for D6 made decision that it would require W-api) - but doesn't mean i can't be frustrated that almost at D7 and still no solid WYSIWYG solution in Drupal :(

Subscribing. Nice work here. Seems to have solved my problem.

Can someone clarify, at this point, where the settings are that control this feature? Is it just in the cck field configuration page as default input format?

#76 This patch provides a new CCK field formatter for text fields.

Better Formats is a great and essential module.
But I really *really* do not understand why an official release including this patch is not out yet!
What the hell is the maintainer waiting for?
Come on! alexpott's patch was first posted on March 22, 2009 and has been tested & reviewed & rerolled so many times since then that it is a shame it is not officially in the module yet!

Patch from #59 worked great for me too... once I figured out what it was doing.

Some super-quick documentation:

This patch adds a new module called "Better Formats additional CCK text widgets". Once enabled, this allows you to select a "using Better Formats module" widget in the CCK field settings.

To use:

• Go to Your Content Type -> Manage Fields -> Configure -> Change Basic Information
• Select the "Text field using Better Formats module" or "Text area using Better Formats module"
• Back on the configuration page for the field, the "Input format settings" section will reveal a number of options to limit what roles can use what input formats for this field
• Enjoy

Thanks @froboy for the awesome docs (saved me a lot of head-scratching), and @alexpott for the awesome patch in #59 (solved my problem!).

This is exactly what I needed. Thanks to all who contributed here. Special props go to alexpott!
(subscribing)

+1
btw:The patch works great

works great!

Hi,

I'm fairly new to drupal, can anyone tell me how I go about implementing this patch?

Thanks

#84: http://drupal.org/patch/apply

#84

Beginner's Guide: http://drupal.org/node/620014

To clarify on #68:

No, 2.x dev has the modified code from this patch. More commits on it to come this weekend.

Does this mean that 2.x dev does does contain the patch from #59? I installed the dev release from 2010-Jul-11 and noticed the following differences as compared to the patched 1.2 version:

• Does not seem to contain the "Better Formats additional CCK text widgets" (Better_formats_cck_text_add) module
• CCK fields do not list the "Text field using Better Formats module" or "Text area using Better Formats module" formatters/widget options

Just asking, did you guys read this one? #720278-1: better_formats overrides CCK default values.
See also #57 (dragonwize) of this issue.
What exactly are we trying to get in addition to that one? CCK allows to set a default format for a field instance. This will fix most people's problems. If we don't override it, which the 1.x branch still does.

What more do we want? Set allowed options for each field? Or for each field instance? Would it make sense to put this extra stuff in an optional sub-module?

@dragonwize: Could you release a 6.x-2.0-unstable1 ?
I imagine this could convince more people to do some testing on the 2.x branch.
I already tried, you can go two digit numbers with -unstable, so i guess you can go up to -unstable99 at least :)

Or, as 2.x is taking longer than we want, could we backport the changes from #720278 to the 1.x branch? It didn't seem so complex.

EDIT:
A problem with this solution is that CCK will not save the format if the field is left empty. I always have to put a dummy space (which is awkward). Maybe an issue for CCK ?

Subscribe

@donquixote: geez, that is not exactly an intuitive way to set the default filter for a CCK field. Thanks for sharing.

Has anyone successfully backported this to 1.x? Or if not... how usable is 2.0-dev at present?

Never mind, answered the first part of my own question. It works very nicely on 1.x.

Subscribing. Thanks

The patch in #59 solves my need. Great work! Can we get this committed?

#59 works great! Plz, commit it to the main branch!

following

Subscribing

+1 .. much appreciated. What a mess (not the patch, of course .. but the situation) ..

I agree. This is really becoming ridiculous that this patch is not committed yet!

C'mon dragonwize, please roll this out. It is heavily tested and a very valuable contribution. I upgrade the priority because it is mentioned as one of the most important items on the project page.

Some of this is already implemented in 2.x. Lots of it needs more work both in these features and others. If people want to see this in production release help out with 2.x. See my comment in #59 which still stands. Also the issue mentioned in #88 needs to be fixed as well.

Subscribe

Subscribe

I would add

Step one, after applying the patch go back and enable the newly created module: Better Formats additional CCK text widgets.

subscribe

Here are the files needed for 6.x.-1.2 in case you can't figure out how to patch.

Just unzip and upload the 5 files to: modules/better_formats and overwrite.

Keep a backup of the originals just in case

Enable as #103 says to above.

See #79 to use: http://drupal.org/node/350696#comment-3316738

Great job!

following..

subscribed

subcribe.
thanks for the module and the patch :)

John Pitcairn is right in #66. The input formats selection doesn't show for CCK instance when apply this patch - except for user #1. Add the following function

function better_formats_cck_text_add_perm() {
  return array(
    'show format selection for CCK fields',
  );
}

to better_formats_cck_text_add.module, and enable this permission for roles you want to show input formats, and everything will be ok.

Subscribing

Subscribing, although I'm only really interested in the Drupal 7 version of this. :-)

Subscribing, although I'm only really interested in the Drupal 7 version of this. :-)

Important
People that are using BF 6.1 + this patch should not upgrade to BF 6.2 + reapplying the patch.
Doing so, previous per field settings are lost.

I'm strongly missing this feature in 7.x-1.x (and it seems it's not yet in 6.x

dragonwize, i hope you'll apply a clean solution soon, if we do a D7 port?
I'm fed up of implementing per-field formatter limitation custom code on a project basis... :-)

Time to fix this!

I had a client that wanted to have "styles in titles" (i.e. only bold and italics). They had other fields on the same page that had different style requirements.

Here's a brief recipe:

• Install cck (I mean, you already have cck, right? ;^) create a cck field "fancy_title" or "faux_title" or whatever.
• Install wysiwyg (I used ckeditor library), create all required input formats (I had a "main body" and "title") ensuring that they have the proper buttons enabled and permissions set.
• Install auto_nodetitle and set it to create titles based on the "fancy_title" cck field
• Install better_formats (patch per #59) follow the directions in #79 and apply the "bold and italics only" input format to the "fancy_title" cck field. (and any other input formats to any other cck text fields you want)

Sweet, eh? Well I thought the gigantor field for "title" seemed odd, so I shrunk it down with:

#cke_contents_edit-field-presentation-title-0-value.cke_contents {
 height: 50px !important;
}

Of course, you'll have to find your own css id (for me, it was the one right above the

subscribing
not other module or something easy to implement gives this feature.
thanks a lot to everybody that contributed to this module and this patch :)

Thanks for this - patch #59 solved my problem

I have posted a Drupal 7 version of this functionality here: #1295248: Allow per-field-instance configuration of allowed formats

I'd like to subscribe, too.
The patch posted in #59
works like a charm.
This has been the first patch I had to apply, ever.
After more than two year this patch is around - I think this should really be part of the stable release.

If you're an impatient developer that stumbled upon this issue looking for instant gratification, try this:

Just use a hook_form_alter with a custom after_build function.

function mymodule_form_alter(&$form, &$form_state, $form_id){
  $form['#after_build'][] = "mymodule_after_build";
}

function mymodule_after_build($form, &$form_state){
  
  //Set the default input format to 5 for "my cck field" in the fieldset "my fieldset"
  $form['my_fieldset']['my_cck_field'][0]['format'][5]['#value'] = 5;
  
  //Don't forget to return, $form is not passed by reference here.
  return $form;
}

If you're doing this in conjunction with better formats, you'll need to use hook_elements instead. Make sure your module weight is higher than BF in the system table so your hook runs after

function mymodule_elements() {
  return array(
    'text_textfield' => array(
      '#process' => array('mymodule_text_process'),
    ),
    'text_textarea' => array(
      '#process' => array('mymodule_text_process'),
    ),
  );
}



function mymodule_text_process($element, $edit, $form_state, $form) {

	
	if($element['#field_name'] == "my_cck_field"){
		$field = $form['#field_info'][$element['#field_name']];

		if (!empty($field['text_processing'])) {
	    	// Get core default for new or selected format for existing.
	    	$filter_key = (count($element['#columns']) == 2) ? $element['#columns'][1] : 'format';
	    	$parents    = array_merge($element['#parents'] , array($filter_key));
	    	$default    = better_formats_get_default_format('node', $form['type']['#value']);
	
	    	//Force the default the format ID
	    	$format = 7;
	    
	    	$element['#value'][$filter_key] = $format;
	    	$element[$filter_key] = better_formats_filter_form($format, 7, 'node', $form['type']['#value'], 1, $parents);
	    }				 
	}
	
	return $element;
}

Years later...it would still be great to see this committed to the D6 module. The code in #120 has been working for me. Since the 2.x branch of the D6 module clearly never happened (it's not even listed anymore) it sure would be nice to have this patch applied, at the very least in a 6.x-1.x-dev version. Pretty please? We've all waited patiently for four years...

(Aside: Did this functionality make it into the D7 branch? I haven't had reason yet to test that out.)

6.x is now unsupported. PS. This feature is in D7 and D8.