By Farreres on

We are having a problem in moneysuite module https://www.drupal.org/project/moneysuite with ppv submodule and I need some expert help. The issue originating the problem is https://www.drupal.org/node/2616012. I know which is the problem but I don't know how to solve it. I am quite new in maintaining drupal modules and I have a lot to learn. I have stepped as maintainer of moneysuite, a big module with a lot of options and it is being quite difficult in some cases. The code in moneysuite is not mine, so I am doing my best to understand its internal working, and up to now I could manage it.

Our problem is that: moneysuite ppv allows developers to sell nodes in a pay per view formula. One way it accomplishes this is by defining a formatter for a field. If you use this formatter you can define a protected message that will show instead of the field if the user hasn't paid to access the node.

The protected message was a textarea but I changed it into a text_format as I needed to apply text filters to it. This change is working nicely. But, moving from textarea into text_format alters the structure of information, now field content is not plain text, it's an array with content and format.

Now, our problem was detected in views, but I am sure there will be more. In views we get a lot of errors which are related to field containing a table instead of a string.

Before I understood what the problem was I tried a solution I found here: http://stackoverflow.com/questions/6241710/wysiwyg-in-custom-field-in-dr... and via #entity_validate and a validate function, if I flatten the form field content views generate no error, but the form field looses its contents. Then I noticed our problem doesn't come from a field but from a formatter.

How can I make the formatter to flatten the text_format message so that views don't generate errors?

If you need any more info, please, ask me and I will try to clarify.

⋅ Categories: Drupal 7.x

Comments

Farreres’s picture

Farreres commented

I have found this comment https://api.drupal.org/comment/48048#comment-48048 which maybe gives a hint as to where to go. I am now trying it. Until someone replies I will try with this approach.

Farreres’s picture

Farreres commented

There is this other comment talking about another approach, but I think it's an approach for fields, not for formatters with text_format fields: https://api.drupal.org/comment/30738#comment-30738

Farreres’s picture

Farreres commented

ok, I think I solved the problem. In case someone needs to implement a text_format in a field formatter, this is what you should do:

in function hook_field_formatter_settings_form:

  $element['message'] = array(
    '#type' => 'text_format', // text_format field
    '#title' => t('field title'),
    '#description' => t("field description."),
    '#default_value' => isset($settings['message'])?$settings['message']:'', // default field value
    '#format' => isset($settings['format'])?$settings['format']:NULL, // field format
    '#element_validate' => array('_text_format_validate'), // this is going to flatten the field
  );

function _text_format_validate($element, &$form_state) {
	if($element['#type']=='text_format') { // validate only text_format fields
		$field_name = $element['#parents'][1]; // get the name of the field
		$values = $form_state['values']['fields'][$field_name]['settings_edit_form']['settings'];
		$form_state['values']['fields'][$field_name]['settings_edit_form']['settings']['format'] = $values['message']['format']; // the field format is taken from the text_format field format
		$form_state['values']['fields'][$field_name]['settings_edit_form']['settings']['message'] = $values['message']['value']; // the field value is taken from the text_format value
	}
}

Then, within hook_field_formatter_view:

$html = check_markup(token_replace($settings['message'],
                                    array('ms_ppv_field' => $ms_ppv_field,
                                          'user' => $user,)),
                     $settings['format']);

Using this set of code, text_format fields are being stored in a flat way.