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"?

[Denis-de-Bernardy]

see #11779

[wpmuguru]

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".

[Denis-de-Bernardy]

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

[Denis-de-Bernardy]

See also #12416

[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.

[Denis-de-Bernardy]

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.

[Denis-de-Bernardy]

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.

[dd32]

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()

[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? I'd give this function much greater odds at breaking an end-user's strings than repairing them.

[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.

[Denis-de-Bernardy]

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.

[wpmuguru]

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.

[wpmuguru]

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