Hacks, Tutorials

Fix-It-Yourself Extensions, or The Field Formatting Fiasco

January 8, 2009
by Tim Kelty

ExpressionEngine 1.6.5+ made a significant change to the typography class so that many custom field extensions broke. Here are some simple instructions that can help you avoid broken templates.

If you’ve heard or uttered any of the following, this article is for you:

When publishing entries, they get put in the DB as NULL
The formatting for 3rd Party custom field extensions is being set to NULL?
Custom fields without format are being formatted with <p>?

With the 1.6.5 release of ExpressionEngine came a change to the way formatting works for extensions that define a custom field type. If the formatting for an entry is not explicitly set, it gets entered as NULL in the database. When EE encounters no formatting, it defaults to XHTML. If you are using any extensions that create a new field type, you may start to notice template irregularities or disconcerting errors in the CP.

Some well-known extensions affected:

DC URL Field (a custom field that checks for a properly formatted URL) was affected, but they fixed theirs already. Thanks, guys!

Brandon Kelly’s Playa (devot:ee’s pick as the 2008 Extension of the Year) has also been updated and no longer requires any formatting fix.

A Small Hack Gets Your Formatting Back

Luckily, the fix is pretty easy across the board. What we need is a hidden field that submits our formatting, as suggested by Derek on the EE Forums. Here’s the code:

// add formatting
$r .= $DSP->input_hidden('field_ft_' . $row['field_id'], $row['field_fmt']);

What to do with it? We need to to add this to the publish_form_field_unique hook in the affected extensions. Let’s look at a real example. We’ll open LG File Manager and see exactly where to place this (we’ll be referencing version 1.2.0).

Open the ext.lg_file_manager.php file, and find the publish_form_field_unique function at line 292 and the lines with the if ($row['field_type'] == $this->type) conditional. Find this area towards the end of the function:

$r .= "\n";
  // make sure we add the initialisation scripts in show_full_control_panel_end
  $SESS->cache['Lg_file_manager']['require_scripts'] = TRUE;
 }
 return $r;
}

Add the line like below (we’re putting it above the bracket that precedes the return $r because we want it included inside the if($row["field_type"] == $this->type) statement)

  $r .= "\n";
  // make sure we add the initialisation scripts in show_full_control_panel_end
  $SESS->cache['Lg_file_manager']['require_scripts'] = TRUE;
  // add formatting
  $r .= $DSP->input_hidden('field_ft_' . $row['field_id'], $row['field_fmt']);
 }
 return $r;
}

If you have other extensions suffering the same fate, a similar fix is probably in order.

One More Thing

Reformatting an EE Custom FieldReformatting existing fields that were affected.

If you had existing entries that were affected by this, you may need to go in and edit the custom field by setting the field formatting to ‘XHTML’ (or any other formatting type that is NOT the one you ultimately want) and updating all existing entries with that new formatting by checking the box that will show up right above the “Update” button. Then you need to go back in and edit the field again, setting the formatting back to ‘None’ and updating all the fields with the formatting choice again. That should reset all your existing fields, explicitly setting them to “None”. Now that you have tweaked your custom field extensions to play nice with your up-to-date ExpressionEngine installation, you shouldn’t run into odd output wrapped in extra <p> tags or entirely broken templates.

9 Comments:

Adrian Long 01.08.09

This is an incredibly timely post…  I got hit by this bug at work just yesterday afternoon!

Tim Kelty 01.08.09

Tim Kelty

Hope it helps. I know it brought me to a screeching halt before I figured out what was going on.

Peter 01.08.09

Nice writeup, thanks for gathering all the information. Would have made our life a bit easier before the fix ;)

Ben 01.09.09

Indeed, a timely post.  Another option is to wrap output in the {exp:strip_html} tag after installing this module.  I chose this option because I dislike hacking extensions.

Ryan Masuga 01.09.09

Ryan Masuga

Thanks, Ben. I hadn’t thought of the strip_html solution. In some ways, that is a better solution because you do leave the add-ons alone.

The ideal solution is to make the add-on developers aware of the situation and have them update their work!

Ben 01.09.09

Indeed.  I hope the 2.0 codebase will be more stable and consistent in minor revisions.

P.S. Did you get my msg re: sharing content & crosslinking between your site and http://ee-developer.com? Let me know.

Tim Kelty 01.10.09

Tim Kelty

I seem to recall trying strip_html, but it broke inside of Lumis’ Image Sizer)’ plugin so I had to find another way.

Ryan Masuga 01.10.09

Ryan Masuga

@Ben: I did get your message about that, but we’ll take that off the air and out of the comments for this post as it doesn’t have much to do with custom field extensions.

fabio Marchi 01.23.09

You saved my life. Thanks !!!!!!!

You must be registered member to comment. If you're already a member, log in now, and if not go register (it's free and easy!).