Make WordPress Core

Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#25328 closed defect (bug) (fixed)

switch_to_blog() doesn't fail on validation

Reported by: markoheijnen's profile markoheijnen Owned by: drewapicture's profile DrewAPicture
Milestone: 3.9 Priority: low
Severity: minor Version: 3.0
Component: Networks and Sites Keywords: has-patch commit
Focuses: docs, multisite Cc:

Description

Currently you can pass in a non existing blog id. It will always return true since there is no validation in switch_to_blog(). Even if the PHPDocs says it does do that.

The best place to add a check is wpdb::set_blog_id() but I'm not sure if we want to add an extra database on the init of a site.

Attachments (1)

25328.diff (558 bytes) - added by jeremyfelt 10 years ago.

Download all attachments as: .zip

Change History (12)

#1 in reply to: ↑ description @nacin
10 years ago

Replying to markoheijnen:

The best place to add a check is wpdb::set_blog_id() but I'm not sure if we want to add an extra database on the init of a site.

We don't. This seems like a wontfix.

#2 @markoheijnen
10 years ago

So that would mean fixing the PHPDocs.

#4 @DrewAPicture
10 years ago

  • Keywords needs-docs added

@jeremyfelt
10 years ago

#5 @jeremyfelt
10 years ago

  • Keywords has-patch added; dev-feedback needs-docs removed
  • Milestone changed from Awaiting Review to 3.9
  • Priority changed from normal to low
  • Severity changed from normal to minor

25328.diff modifies docs to show that switch_to_blog() always returns true.

#6 @jeremyfelt
10 years ago

  • Component changed from Multisite to Networks and Sites
  • Focuses multisite added

#7 @jeremyfelt
10 years ago

  • Keywords commit added

Doc change in 25328.diff still applies cleanly to trunk.

#8 @DrewAPicture
10 years ago

  • Focuses docs added

#9 @DrewAPicture
10 years ago

  • Owner set to DrewAPicture
  • Resolution set to fixed
  • Status changed from new to closed

In 27347:

Fix the return description for switch_to_blog() to reflect that it always returns true.

Props jeremyfelt.
Fixes #25328.

#10 follow-up: @nacin
10 years ago

Devil's advocate for [27347]: The docs weren't actually wrong — there was just no validation for which we would return false. We may want to add a falsely return value later. What do we think about making it say "always returns true. Could return false on failure in the future."

#11 in reply to: ↑ 10 @DrewAPicture
10 years ago

Replying to nacin:

Devil's advocate for [27347]: The docs weren't actually wrong — there was just no validation for which we would return false. We may want to add a falsely return value later. What do we think about making it say "always returns true. Could return false on failure in the future."

I'm not a big fan of conjecture when it comes to documentation — it either does or it doesn't. That said, I could get behind a @todo specifying a need for future clarification.

Note: See TracTickets for help on using tickets.