Design proposal: Support for transparently switching between sites in a network

[acobster]

Is your feature request related to a problem? Please describe.

The core issue is described in #1434 - that issue provides a workaround but does not opt to fix it in Timber itself for performance reasons:

Now, I think we won’t change Timber to work around that. We would have to prepare all the data for posts in advance, but that would be a performance hit. The way it works now is that we fetch some of the data only when needed.

I think that's perfectly reasonable and valid, but I suspect it's possible to do this transparently and lazily.

Describe the solution you’d like

First, in Post::init(), we could detect that we're in multisite and store the site info:

/* Post.php */
protected function init($pid = null) {
  // ...standard stuff...
  $post_info = $this->get_info($pid);
  $this->import(apply_filters('timber/post/import_data', $post_info));
}


/* Meanwhile, off in some Timber multisite component: */
if (is_multisite()) {
  add_filter('timber/post/import_data', function($info) {
    return array_merge($info, [
      'current_site' => get_current_site(),
    ]);
  }));
}

Later, when we look up the permalink or similar functionality, we can detect that we're doing something site-dependent and make the switch transparently:

/* Post.php */
public function link() {
  if ( isset($this->_permalink) ) {
    return $this->_permalink;
  }

  $this->_permalink = Timber\Helper::on_multisite($this->current_site->id ?? 0, function() {
    return get_permalink($this->ID);
  });

  return $this->_permalink;
}


/* Helper.php */
public static function on_multisite(int $site_id, callable $callback) {
  if (!is_multisite() || empty($site_id)) {
    return $callback();
  }

  // Multisite detected.
  switch_to_blog($site_id);
  $result = $callback();
  restore_current_blog();

  return $result;
}

The Helper::on_multisite() method provides a generic wrapper function for doing arbitrary site-dependent stuff. Note that if we're not a multisite install, there is virtually no overhead.

Other site-dependent behavior can be implemented as needed.

Describe alternatives you’ve considered

Just not doing this, and providing good multisite docs. :)

Additional context

There is an open issue for creating a multisite guide here: #2207

[jarednova]

Agreed! We're doing a ton more Multisite work at our company. Having this handled in a really robust way would be a 🌟 to a lot of things we're actively doing (and then being like "wait, how come this is acting all funky????")

[acobster]

Rad! I haven't done much multisite dev at all, but I will need to as part of my next big client project. I definitely could use some help identifying the funky parts!

[gchtr]

I think this is definitely worth exploring, though I have no idea how deep we have to go down the rabbit hole here.

Just not doing this, and providing good multisite docs. :)

I think we should have documentation about Timber + Multisite anyways.

[acobster]

no idea how deep we have to go down the rabbit hole here

Me neither. I imagine it'll be quite a bit of trial and error.

I think we should have documentation about Timber + Multisite anyways.

💯