Recently, we had a user request that their backslashes be preserved when saving their CMB2 fields. Typically, when a user wants non-standard sanitization, our canned response is to use the provided field parameter sanitization override, 'sanitization_cb'. If you’re not aware of this field parameter (and it’s cousin, 'escape_cb'), let me explain a bit.

By default, CMB2 does quite a bit of heavy-lifting for you when it comes to sanitizing your users’ input, as well as escaping that value for proper display. This is just one of the aspects of CMB2 that I appreciate; that I don’t have to “think” about the sanitization/escaping of my fields.

“It just works.”

Except, of course, when it doesn’t.

There is no way CMB2 can adapt to every scenario developers may use it for, and until AI has fully commandeered our society, I don’t foresee that happening. In the meantime, we built a way to handle those edge-case scenarios on your own.

Enter the humble 'sanitization_cb'.

Yep, that handy override has existed in CMB2 for over four (!) years, but it is a bit obscure, because, fortunately, you’ll almost never need it.

Back to the issue at hand. As I mentioned, this particular developer (that forum post is basically the TL;DR for this post) needed to allow users to add backslashes to their field. My first suggestion was to add this one-liner to their field config:

This avoids CMB2’s default call to stripslashes_deep(), but still has the benefits of the sanitization.¹

Unfortunately, as simple as it seemed, this was not the solution, as the backslashes were still being stripped from the content. So I started testing by doing some simple update_post_meta() calls, like:
update_post_meta( get_the_ID(), 'test_slashes', 'keep\my\slashes' );

Looking in the database, I found that the backslashes were still being removed. Huh.

Knowing that, I dove into the guts of update_metadata(), the update_post_meta() parent function. As you may have guessed, it turns out, WordPress itself removes the slashes, because it expects the data to be “slashed.” I’ll leave an explanation for why that is to someone else (read: I have no idea why, but probably has a good reason), but if you explicitly WANT the slashes, then you need to extra-slash it before it saves.

Armed with that knowledge, we can create a sanitization function that sanitizes and slashes:

As you see, this is simply a mashup of the  sanitize_text_field() and wp_slash() functions, but it will serve us nicely for our sanitization_cb parameter:

At this point, we’ve allowed this field to accept, save, and display the backslashes properly, and now you can too.

Thank you for following along. Like this parameter, there are many many useful, yet obscure, features in CMB2, and I hope to leverage future support requests and this space to add exposure for those features².