The patch I posted about previously to improve the slash handling within WordPress for 3.5 (which fixes some core bugs and fixes tons of developer custom code bugs) is still looking promising. After setting up my unit testing environment a few days back and talking with a colleague to verify the proper approach, I began actually writing the tests today.

Nacin quite reasonably stated:

This can’t go near core without tests, and it is going to be difficult to even understand many of the issues presented here without tests.

He’s right. There’s no way the core team should take my word for it that I tested the changes thoroughly. A set of changes this big, while very important fixes, also run the risk of introducing bugs that would affect literally millions of sites. Unit tests are a necessity here.

I’ve opened a ticket for the unit test changes and am tracking the general test coverage to give better visibility into what is being tested. The good news is the tests all pass so far with the new core patch applied and fail on trunk (without the patch). Exactly what should be happening.

I’d love additional help creating tests as well as testing the overall core patch to help make sure edge cases aren’t getting missed. The sooner this can land in trunk the sooner it gets widespread testing. Getting it in early in the release cycle is definitely a good idea.

---

A quick summary of the issue: without this patch, developers that are making calls to “model” functions such as wp_insert_post() (comment, term, user, meta, etc.) without manually adding slashes to the data they pass in are losing data in certain situations. These functions all expect slashed data – this patch reverses this and moves the “stripslashes” actions to the “controller” functions instead.

This post is part of the thread: WordPress Slashes – an ongoing story on this site. View the thread timeline for more context on this post.