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

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?

Here is a d6 version in case anyone is interested. In response to #15 about sanitized text, I was considering this a module in the same realm as computed field...where it was understood that dangerous code could be put into the markup field and to handle permissions accordingly. I know I've needed to include javascript into my markup fields in the past and wouldn't want to lose that ability.

Hmm...attachments to not appear to have attached. Trying again.

Also needs an install file.

This is great. Simple. Light. Exactly what I needed. Thanks!

Great little thingy :)
I agree with KarenS that these lightweight stuff should be added to core.
And about #11 + #16 i think the name "content_utility" is appropriate.

thanks Joshk

I'm glad to find this - it would be great to see this as a widget in cck core.

One thing I noticed is that the markup field currently allows a 'Number of values' option, which seems unintended.

If I change the number of values from 1 to 2 and save the field settings, the markup displays multiple times within an ajax sortable table on the form. After saving the field settings, I also get the following error:
user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') SELECT vid, nid, 0, FROM drupal_content_type_mytype' at line 1 query: INSERT INTO drupal_content_field_markup_test (vid, nid, delta, ) SELECT vid, nid, 0, FROM drupal_content_type_mytype in /mysite/sites/all/modules/cck/includes/content.admin.inc on line 1506.

@scottrigby #27: I believe this is because there are some pieces in CCK that does not take into account that a CCK field could not have any DB fields, as in this case.

IMHO, CCK would not have to create DB fields nor field tables for fields that do not expose DB fields. In fact, I would say this is a bug.

Another method to add stuff to the node edit form is by using hook_form_alter() directly. If you wish to expose this stuff to CCK so it can be reordered from the 'Manage fields' panel is using hook_content_extra_fields(). There's an example in content.module itself. However, with this method it is not possible to move these items into fieldgroups. Maybe this could be a feature request for fieldgroup module?

Thank you, cYu, for porting this to D6, and thanks to everyone else who's had a hand in this.

I agree that it'd be handy to put this in CCK core, but in the meantime, why not open up a project for this? We've got D5 and D6 versions, and this'd make it easier to find (for those of us who are *finally* porting our sites to D6, anyway). It'd also make it visible to the system update process.

Unless this has already been set up already under another name, perhaps?

Thanks again, folks ... we get good use out of this.

I needed this just the other day. Would be great to get it added.

@KarenS: back to your idea in #15:

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.

Personally I'd really like to see that feature. Currently this only works in the edit form, but I'd also like to see a way (other than computed field) to add markup on the node view without having to keep modifying node templates just for this. Maybe checkboxes in the field's configure screen like:
Display on:
[ ] Edit form
[ ] Node display

I'm trying to use this with the new multigroup feature in CCK's 6-3 branch and it works fine except that when I save the node it tries to save values for markup and ends up giving a warning about duplicate keys. Is there a way, in the definition of a cck field, to mark it to not be stored in the db? This seemed to work ok until I made it "multiple" by putting in in a multigroup fieldset.

@cYu: would you mind creating a contrib module for this? That way it would be easier to deal with any issue it may have.

If you do, then I would be happy to have it on my system, and that would make it easy for me to guess how it works in multigroups.

Ack, was going to create the contrib but see that somebody already started to do that 3 months ago by adding an older version of this module to cvs but never creating a project for it. http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/markup/

I will try contacting that user to see what his intentions are.

Talked to ebeyrent and the project now exists.

Good news. Now, it would be perfect if a dev snapshot was available, so that it can be monitored with update status. See you by then, and I'll see what happens with multigroups. :)

Ok, installed the markup field and testing now.

BTW, when I moved to markup widget, I got an SQL error when CCK tried to migrate data from per type table to per field table. This is a CCK issue. For reference, see: #524314: Ignore fields with no exposed column in content schemas

user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') SELECT vid, nid, 0, FROM drupal_content_type_test_multigroups_1' at line 1 query: INSERT INTO drupal_content_field_test_markup_1 (vid, nid, delta, ) SELECT vid, nid, 0, FROM drupal_content_type_test_multigroups_1 in /data/sandbox/drupal/drupal-6.x-modules/cck/includes/content.admin.inc on line 1537.

Yeah, I have also seen the error in multigroup when saving the node form.

warning: array_merge(): Argument #1 is not an array in cck/modules/content_multigroup/content_multigroup.node_form.inc on line 432.

Is this what you have?

I have to investigate a bit more...

I'll come back with more information as soon as I find anything useful.

Ok, I fixed the PHP warning on multigroup module:

http://drupal.org/cvs?commit=240610

It should be available with the next dev snapshot of CCK3.

Aside from the other error when CCK tries to migrate data to per field table. I don't see any other problem when saving nodes with markup widgets on multigroups. So I think this is fixed here. The other error depends on CCK issue: #524314: Ignore fields with no exposed column in content schemas