I’m posting this because after I spent a good while searching for the gremlins that caused the error, I thought of a faster way to find the error. Behold, Googlebait, so someone else can benefit.
I discovered this while working with a Safecracker-style form (specifically, using profile:edit). Because of the nature of all the custom fields contained in my profile channel, it was necessary for me to get ridiculously specific with the form fields, and set them up in tag pairs, and not the { custom_fields } loop. Doing so increased the chances that I made a template boo-boo that resulted in the Disallowed Key Characters error when I attempted to submit the Safecracker form.
Now that I’ve discovered the issue—a stray curly brace inside one of the form elements—I have a strategy for finding those nasty little disallowed keys easier the next time. Here, internets and eecms devs, I offer it to you, in case it helps save you some time.
1. View Source for the rendered template with the Safecracker form in it.
2. Do a search in the view source for curly brackets. { and }
3. If any show up inside the form tags, say, at the beginning or end of the ID or NAME property, you found your culprit.
<textarea id="custom_field_name" name="custom_field_name}">{custom_field_name}</textarea>Hint: if your eyes are glazing over this example, look more closely at the end of the name= property.
This technique beats the heck out of creating a separate template and running the reliable safecracker custom_fields tag pair, especially when the total count of custom fields is something in the dozens.