WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 3 years ago

Last modified 3 years ago

#14418 closed enhancement (wontfix)

Introduce restore_original_blog()

Reported by: nacin Owned by:
Milestone: Priority: lowest
Severity: normal Version:
Component: Multisite Keywords: has-patch needs-testing 3.2-early
Focuses: Cc:

Description

While working on a multisite install, I saved a number of queries by switching from one blog to the next using switch_to_blog() without calling restore_current_blog() each time. That meant I needed to rewind everything back to the original blog when I was done.

This seems like a candidate worthy for core. It is only a few lines of code, but it prevents users from mucking with one of the globals in switch_to_blog() and restore_current_blog().

function restore_original_blog() {
	global $switched;
	while ( $switched )
		restore_current_blog();
}

Alternatively, we could simply add a parameter to restore_current_blog() (which really should be called restore_previous_blog(), no?) that allows for a complete rewind, or perhaps steps.

Attachments (2)

restore_original_blog.patch (538 bytes) - added by deepak.seth 4 years ago.
restore_current_blog-switchback.diff (1.4 KB) - added by cgrymala 4 years ago.
Modifies restore_current_blog to allow rollback all the way to original blog

Download all attachments as: .zip

Change History (14)

comment:2 @jane4 years ago

  • Keywords needs-patch added

If someone wants to get this in for 3.1, please post a patch now, as freeze is right around the corner.

comment:3 @jane4 years ago

  • Type changed from defect (bug) to enhancement

comment:4 @deepak.seth4 years ago

  • Cc deepak.seth added
  • Keywords has-patch needs-testing added; needs-patch removed

comment:5 @westi4 years ago

  • Keywords 3.2-early added
  • Milestone changed from 3.1 to Future Release

This should be done early in the cycle

@cgrymala4 years ago

Modifies restore_current_blog to allow rollback all the way to original blog

comment:6 @cgrymala4 years ago

If you really are rolling all the way back to the original blog, I don't see any reason to loop through the $switched_stack. Instead, you could just use array_shift() on the $switched_stack instead of array_pop() within the restore_current_blog() function and empty out the $switched_stack var at the end of the function to accomplish the same end result.

I just added a patch that shows that approach. It adds an optional parameter to the restore_current_blog() function, and then makes the changes I mentioned above if that switch is set to true.

Duh. Just re-read Nacin's original post and realized that was sort of what he initially suggested.

Last edited 4 years ago by cgrymala (previous) (diff)

comment:7 @Viper007Bond3 years ago

I made a ticket for restore_previous_blog() here: #18797

comment:8 @TechDagan3 years ago

  • Cc dagan.henderson@… added

comment:9 @westi3 years ago

I am bit wary of this function because of the following scenario:

  1. Request runs on blog 23
  2. Code A calls switch_to_blog( 123 );
  3. Code A calls function b();
  4. function b() calls function c();
  5. function c() calls switch_to_blog( 456 ); and switch_to_blog( 768 ); and restore_original_blog();
  6. core returns to function b();
  7. Code returns to Code A which thinks it is switched to blog 123 but is now running on blog 23 and does nasty things to the blog.

This could be something which never happens in testing but does happen when the code is used or modified over time and would be hard to prevent in code.

comment:10 @Viper007Bond3 years ago

You've certainly changed my mind. I'm voting wontfix.

comment:11 @nacin3 years ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from new to closed

comment:12 @nacin3 years ago

One could also do something like this for the edge case, and avoid the global:

while( restore_current_blog() );

Note: See TracTickets for help on using tickets.