Thank you for this module! Looking forward to using it.

Just installed on a site in development and when I save, I'm receiving warnings like:

in_array() expects parameter 2 to be array, string given in textcleaner_clean_input() (line 65..

This is on a custom taxonomy term field (long text). I can try and dig deeper when I get some breathing room, but I'm hoping it's an obvious fix.

..jon

Comments

kevinquillen’s picture

kevinquillen CreditAttribution: kevinquillen commented

Hm. I think it may be because you have not selected which fields yet to act on in the TextCleaner config?

kevinquillen’s picture

kevinquillen CreditAttribution: kevinquillen commented
Version: 7.x-1.1 » 7.x-1.x-dev

You're right though, I forgot to set a default for the variable during install or when checking, instead it sets a ''.

I should set at least a default of long text so it works prior to changing config.

JonMcL’s picture

JonMcL CreditAttribution: JonMcL commented

Doh!

My bad for not checking for a config screen. I just assumed it worked on all text fields. Maybe a message with link after module activation would be a good idea? Or a 'configuration' link in the module list.

Unfortunately, once I did enable the "long text and summary" fields, I hit some more errors. If you want, I'll try and submit new issues, but a quick summary from what I saw:

  • The $clean_string variable in the textcleaner_strip function does not appear to be initialized before it gets appended-to on line 105.
  • The $textcleaner_fields variable in the textcleaner_clean_input function appears to get an array of ALL fields. Even the ones I didn't configure to be processed. The other fields seem to be array elements with an integer value of 0. But this causes the function to give errors like: "Undefined index: value in textcleaner_clean_input() (line 67 ..".

For that second one, I'm guessing this is when it reaches a field that doesn't have a 'value' component. So it might be a good idea to check for a 'value' element before processing on it since operator error will probably lead to fields being enabled that won't work. But then also check your configuration form save to make sure the variable is setup the way you're expect. Here's what mine looks like:

a:17:{s:17:"text_with_summary";s:17:"text_with_summary";s:8:"datetime";i:0;s:4:"date";i:0;s:9:"datestamp";i:0; s:4:"file";i:0;s:5:"image";i:0;s:12:"list_integer";i:0;s:10:"list_float";i:0;s:9:"list_text";i:0;s:12:"list_boolean";i:0; s:14:"node_reference";i:0;s:14:"number_integer";i:0; s:14:"number_decimal";i:0;s:12:"number_float";i:0;s:23:"taxonomy_term_reference";i:0;s:4:"text";i:0;s:9:"text_long";i:0;}

I would contribute with some patches, but I have to stay focused on my project right now :(

..jon

kevinquillen’s picture

kevinquillen CreditAttribution: kevinquillen commented

I see that, I used drupal_map_assoc() from the documentation to map default values to a multicheckbox form field. The result winds up saving like that, unless there is another way to do it.

kevinquillen’s picture

kevinquillen CreditAttribution: kevinquillen commented

Sorry for the delay, I began poking away at these issues last night.

The drupal_map_assoc is bugging me. I would not like to store the data the way it is, but I also want to ensure options are checked off on the settings page. Is there a better way to do it without mucking up the stored data?