Form Markup Widget

Handy for creating blocks of extra form information (explanations, help, etc) inside CCK forms.

Good stuff!

pardon the question, but how does this compare to mh86's form_markup.module?

It seems to do the same thing (i have currently installed on a site of mine and it works fine also)

i like it

thanks for making this, i was gonna do it myself, but its nice to not have to

this is advantageous over having prefix and suffix for each field for me, because i use an external module to selectively hide/lock fields based on user/workflow state

its nice to be able to have/hide markup only, without having to hide an associated data entry field

thanks

looks core worthy to me. is small, anyway.

Missing Doxygen and some # for hook_form_alter. And I would name it markup_field.module instead.

unset($form['widget']['description']);
unset($form['field']['required']);
unset($form['field']['multiple']);
unset($form['field']['#description']);

Has this been updated to work with 5.2?

Or, is there a better way to add markup text to CCK forms? I need to be able to put additional help text before the input fields (to build out a survey).

This seems to work with version 5, except that weights don't work -- the markup field always floats to the bottom of the group it's in, and I need control of positioning. I don't understand CCK or forms well enough to fix this on my own; if anyone can suggest a an approach, I'd be happy to do it.

Thanks much --

Shoot ... I figured it out. This works fine in 5. Markup fields are positioned correctly per weight settings. However, if you don't put tags around the markup text, it just floats down to the bottom (at least in Firefox).

Putting ... around the markup text works quite nicely. And with the , I can add CSS to my theme to format this.

I'm noting this here for other newbies like me. Joshk, nice module ... thanks!

Rats, I forgot to put <code> tags in my reply ...

To make this post human readable: putting <div class="description">...</div> around your markup text positions the text correctly per the weight settings.

yep, seems to work fine.

You just have to write a small .info file for Drupal to see the module and list it in the Modules page.

I need this functionality in d5 and will also need it in d6 and am unable to use the existing form_markup.module for reasons similar to what MrTaco mentioned in #3. So to start, I've attached a d5 copy with comments/text cleaned up a bit. I've also renamed it to markup.module to fit with the cck field convention of number, text, etc.

Is this small module useful enough to be considered for cck core or would it be more appropriate to start a project page and then add the d6 version there?

I'm open to adding some simple things like this to CCK core. I'd like to avoid creating dozens of small single-purpose modules, though. One thought I had never followed up on was adding in a module for miscellaneous small but commonly used things like this.

So two questions -- are there other really simple but commonly-needed things that could be incorporated into this? And what's a name we could use that could expand to include other simple fields / widgets?

the module at #10 above conflicts with the other cck contrib FORM_MARKUP.module

attached below is a version that works (D5)

No one responded to #11 -- what name could we use to make this into a generic simple field/widget module? I'd like to get away from one module for every single widget and field. And are there any other simple things that could be incorporated? That part could be done later, but I'm totally open to getting something like this into CCK core.

@marcoBauli: good catch. I'd prefer to see form_markup.module creating a 'form_markup' field and markup.module creating a 'markup' field though. Using 'text_markup' in the markup module means that it is stepping on a new namespace because a module has stepped on it's namespace. I've posted an issue at http://drupal.org/node/272039

@KarenS: Something like basic, common, standard, or utility? What other fields/widgets were you considering bundling together? I don't see the harm in one module per field if the size and simplicity of this module is more of an exception than the rule for cck fields.

We have too many tiny, single-purpose field modules already, it's time to consolidate where we can.

We need to be sure to sanitize the markup value, per http://drupal.org/node/271577.

Also, we could offer a way to show markup on the form only, in the view only, or both, to handle a variety of places you might want to add some fixed text or html entities to either the form or the node.

Another utility widget we could add here is a hidden field widget that could be used with any field. The idea being that the field needs to be displayed but is getting its value from somewhere else (maybe a script). The computed field widget does this, but in a much more complex way. The permissions module hides the value, too, so maybe it's not needed, but if you just want to have a hidden field (on either the form or the view or both) it might be nice to have a really simple way to do it.

I think 'Utility' is nice module name -- content_utility, maybe.

umm..'common' field features other than this that come to my mind are:

. Form Markup (adds prefix/suffix to node form fields)
. CCK field permissions (name says pretty much it all)

Utility seems appropriate to me. Maybe "CCK Utilities"?

Found this thread after some digging. I am absolutely surprised that this module never came to light. it's such a simple widget. I would think that a hidden form element would be easy as well.

I'm happy to report that this widget works with CCK 1.7 on Drupal 5.8.

The only added feature that I think could be added to this is the ability to a choose a filter type.

Another simple widget that would be nice for content_utility would be a Boolean Checkbox. I know integer or text can be used here as Single on/off checkbox, but the setup of the label and allowed values can make that a little bit confusing when all you want is a boolean.

I noticed that My comment changed the version down to 5.x 1.7, sorry about that, just correcting my mistake to the thread.

It this going to be ported over to D6 at some point?