Make WordPress Core

Opened 7 years ago

Last modified 7 weeks ago

#19572 reopened enhancement

switch_to_post() stack implementation (similar to switch_to_blog())

Reported by: alexkingorg Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 3.3
Component: Posts, Post Types Keywords: needs-refresh, bulk-reopened
Focuses: Cc:


One of the challenges themes and plugins have is the balance between utilizing the core APIs that rely on global variables, while leaving things in a "clean" state for the next worker in the chain.

For example, I might have a shortcode that pulls content from another post, outputs a title or some other data, then needs to restore the previous post environment. The attached patch provides APIs for doing just this - using the same stack approach that switch_to_blog() takes in a multi-site instance.

To set up a post context, call: switch_to_post($post_id);

This can be called multiple times, diving deeper into the stack. Then each process is responsible for restoring the $post context by calling: restore_post();

This goes back to the stack, bumps out the current post and restores the previous post's context.

There is some test code for demonstration here:


Attachments (1)

patch.diff (919 bytes) - added by alexkingorg 7 years ago.
switch_to_post implementation

Download all attachments as: .zip

Change History (15)

7 years ago

switch_to_post implementation

#1 @scribu
7 years ago

This would definitely come in handy. +1

#2 @scribu
7 years ago

But what about in_the_loop()? Shouldn't it return false when switch_to_post() is called?

#3 @nacin
7 years ago

I think this is interesting. It may be better (in terms of long-term architecture) to come up with something less procedural and more object-oriented (though also much more complicated), such as WP_Post coming back from the DB and get_post()/WP_Query, thus the ability to do $post->content(), $post->title(), etc. The various template tags would then need to be reworked to rely on the current $post global. It would be similar to how is_* methods work against WP_Query.

#4 @scribu
7 years ago

Right, so then you wouldn't need to call switch_to_blog() at all. You could just call $whatever_post->content() directly. Relevant ticket: #12267

#5 @alexkingorg
7 years ago

I'd say that as long as we have template functions for themes that rely on globals, something like this is needed.

#6 @scribu
7 years ago

That's just the thing. You wouldn't need to use the template tags. They would be simple wrappers for the global. Think is_single() and $wp_query->is_single().

You don't need switch_to_post() when you have access to all the posts at the same time:

$post_a = get_post( 1 );

$post_b = get_post( 2 );



But, since some of the filters on these template tags, such as 'the_content', do not pass the post id as a parameter, it's not that easy.

#7 @bigdawggi
7 years ago

  • Cc matt@… added

#8 @bigdawggi
7 years ago

I agree that when WordPress has posts that are meaningful objects with proper methods, etc (as proposed in #12267) that we should be able to use those methods. For now though, I think a switch_to_post stack would be helpful.

#9 @chriscct7
4 years ago

  • Keywords needs-refresh added; has-patch removed

#10 @DrewAPicture
4 years ago

  • Component changed from General to Posts, Post Types

This ticket was mentioned in Slack in #core-multisite by jjj. View the logs.

3 years ago

#12 @swissspidy
3 years ago

Why introduce a temporary solution using switch_to_post() when the goal is to have proper methods as suggested in #12267?

#13 @iseulde
3 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

This ticket has not seen any activity in over *two* years, so I'm closing it as "wontfix".

The ticket may lack decisiveness, may have become irrelevant, or may not have gathered enough interest.

If you think this ticket does deserve some attention again, feel free to reopen.

For bugs, it would be great if you could provide updated steps to reproduce against the latest version of WordPress (5.0.2 at the time of writing). Remember images or a video can be superior to explain a problem. At the very least, quickly test again to make sure the bug still exists.

If it’s an enhancement or feature, some extra motivation may help.

Thank you for your contributions to WordPress! <3

#14 @JeffPaul
7 weeks ago

  • Keywords bulk-reopened added
  • Milestone set to Awaiting Review
  • Resolution wontfix deleted
  • Status changed from closed to reopened

A decision was made to reopen tickets that were closed in the bulk edit that this ticket was affected by. This ticket is being placed back into the Awaiting Review milestone so it can be individually evaluated and verified to determine if it is still relevant/valid or reproducible.

Note: See TracTickets for help on using tickets.