wrong permalink structure return by get_permalink() when switching blog in WPMU

[5um17]

I am on blog ID 2 and switch to blog ID 1 then calls get_permalink() without an argument it returns permalink of current post of blog ID 2 and with permalink structure of blog ID 1.

Example:-

add_action('wp_footer', function(){
    switch_to_blog(1);
    echo get_permalink();
    restore_current_blog();
});

The same does not happen with pages but happens with post.

PS: I am also concerned about return value. Why it is returning current post of current blog? It is breaking the other plugins those are storing the post IDs in their custom tables thus making a wrong join with invalid post ID.

[flixos90]

I don't think this is something we should take care of at this point. Using switch_to_blog() switches the currently active site state/scope, that includes the permalink structure. In my opinion, what you're describing is expected. I'm curious what's the use-case for switching to another site for receiving the permalink of the current post.

I don't think we can reliably switch the current post when a site is switched, also it would add (for most cases) unnecessary overhead to the switching site process. Therefore I tend wontfix for this one.

[5um17]

Replying to flixos90:

I don't think this is something we should take care of at this point. Using switch_to_blog() switches the currently active site state/scope, that includes the permalink structure. In my opinion, what you're describing is expected. I'm curious what's the use-case for switching to another site for receiving the permalink of the current post.

I don't think we can reliably switch the current post when a site is switched, also it would add (for most cases) unnecessary overhead to the switching site process. Therefore I tend wontfix for this one.

I am sorry I think I did not explain the problem very well. And you only replied to the post script. Here I am reporting two cases

1. Inconstancy of page and post URLs. (I did not test this with CPT)
2. A better solution when using get_permalink() without ID in MU.

The actual issue for which I marked this ticket as bug is a wrong permalink structure or say wrong permalink. For example subsite has default permalink and main site has %postname% then value is return in subsite is %postname% format which leads to 404. On other hand if I am on single page the URL is correct.
This is inconstancy!

The second one is kind of enhancement while using get_permalink() without ID, WP really don't know what should be the return value. Because global values are set to current blog query not the one I switched to.
So it can be better may be do not return the permalink at all without ID? Because you switched to another blog and query is unknown. Just IMHO.

[nikosnikos]

I have the same problem, I have three sites in my network : Site 1 in french, site 2 in spanish and site 3 in english.

I want to display in french and spanish sites a list of english categories (child of "latest news" english site category).
I modified the category base in permalink settings so in french site it is "actualites", in spanish it is "actualidad", in english it is not modified.

In my template :

<?php
switch_to_blog(3);
$english_news_cat = get_term_by('slug', 'latest-news', 'category');
$english_news_cat_list = wp_list_categories(array('child_of' => $english_news_cat->term_id, 'hide_empty' => false, 'echo' => false, 'title_li' => 'News in english'));
restore_current_blog();

In my functions.php, I have to write a hack to get this work :

<?php
add_filter('category_link', 'ticket38305_category_link_hack');
function ticket38305_category_link_hack( $termlink ) {
  global $switched;
  if ($switched && 3 == get_current_blog_id()) {
    // Ugly preg_replace
    $cat_permalnk = array(1 => 'actualites', 2 => 'actualidad');
    $termlink = preg_replace('#^('.home_url().'/)'.$cat_permalnk[$GLOBALS['_wp_switched_stack'][0]].'(/.*)$#', '$1category$2', $termlink);
  }
  return $termlink;
}

[SergeyBiryukov]

Hi there, thanks for the ticket!

Looks like it's the same issue that was previously reported in #20861. Let's continue the discussion there, if still relevant.