stripslashes_from_options() prevents plugins from storing a site name with a slash?

[Denis-de-Bernardy]

stripslashes_from_options() looks extremely fishy.

doesn't it prevent a site from being called, say, "My dog's blog"?

see #11779

The stripslashes_from_options was added because saving "My dog's blog" as a site name resulted in a site name of "My dog\'s blog".

In this case we should fix the origin of the symptom, rather than add band-aids.

See also #12416

Here is the original MU ticket: ​http://trac.mu.wordpress.org/ticket/974. The patch noted on the ticket addressed the issue as far as ms-options.php & ms-edit.php is concerned. The stripslashes_from options function was added so that on upgrade any residual ones would be removed.

Replying to wpmuguru:

Here is the original MU ticket: ​http://trac.mu.wordpress.org/ticket/974. The patch noted on the ticket addressed the issue as far as ms-options.php & ms-edit.php is concerned. The stripslashes_from options function was added so that on upgrade any residual ones would be removed.

As far as SVN blame is concerned, it got introduced here:

​http://trac.mu.wordpress.org/changeset/2005

If you WPMU truly was inserting extra slashes at one point, either:

• we decide it's old enough (I take it that 9 months is old, for a well-maintained WPMU site?), and the rare users who might have (unknowingly?) run into it have upgraded by now, so it's safe to remove it entirely; or
• we want to keep it around for the same, rare, old-time WPMU users, in which case it should be conditionally applied -- if and only if db_version is below a certain number, etc.

Either way, this should not be left into WP as is.

also, based on the ticket you point to, this only affected the screen that the site administrator can access. in other words, end-users would never be affected by this.

the code should be removed entirely, and seen as a bug that slipped into mu changeset 2005.

we want to keep it around for the same, rare, old-time WPMU users, in which case it should be conditionally applied -- if and only if db_version is below a certain number, etc.

We should be able to just add that to upgrade_28() if is_multisite() i would assume?

Code reference for stripslashes_from_options()

We should be able to just add that to upgrade_28() if is_multisite() i would assume?

Looks like it. But considering that this bug only ever affected site admins who would edit, say, a site's name in the sites management screen rather than under the individual site's settings / general screen, should we even bother doing so? I'd give this function much greater odds at breaking an end-user's strings than repairing them.

should we even bother doing so?

I do tend of agree with you there, Anyone who was affected/is affected will probably have changed the name or would manually remove the \'s once they notice them.

Replying to dd32:

should we even bother doing so?

I do tend of agree with you there, Anyone who was affected/is affected will probably have changed the name or would manually remove the \'s once they notice them.

Exactly. Let's remove this function entirely.

Replying to Denis-de-Bernardy:

We should be able to just add that to upgrade_28() if is_multisite() i would assume?

Looks like it. But considering that this bug only ever affected site admins who would edit, say, a site's name in the sites management screen rather than under the individual site's settings / general screen, should we even bother doing so?

It did affect other settings on the site/network options as well. Adding to one of the upgrade functions seems like an appropriate solution.

(In [13618]) move multisite upgrade functions to upgrade.php, see #11771