This is sorta "by design", although I do agree that this is a valid feature request/bug report.

In /extensions/GlobalUserPage/includes/Hooks.php we have an ArticleFromTitle hook subscriber, the same hook that SocialProfile uses to implement its customizations to the User: pages; as per the comment on line 35, If another extension's hook has already run, don't override it. That's where the problem lies.

I suspect that with SocialProfile installed, $page is always an instance of UserProfilePage (due to UserProfileHooks#onArticleFromTitle, in /extensions/SocialProfile/UserProfile/includes/UserProfileHooks.php). The code in UserProfilePage calls parent::view() (where parent = Article) when the user does not want to use a social user profile (see L130 onwards, User does not want social profile for User:user_name, so we just show header + page content).

I'm not sure what'd be the best way to approach this problem. cc @Legoktm for input.

In T250033#6051477, @ashley wrote:

This is sorta "by design", although I do agree that this is a valid feature request/bug report.

We expected that it would be by design but were debating whether this use case was not considered.

Some of this already mentioned by @ashley above, but just reiterating with some other ideas and how this can potentially be done.

So I did some (untested) digging on this. It appears it is caused by one of two things:

1. UserProfileHooks::onArticleFromTitle() overwrites the article page set on MediaWiki\GlobalUserPage\Hooks::onArticleFromTitle()
2. MediaWiki\GlobalUserPage\Hooks::onArticleFromTitle() prevents overwriting the article page set on UserProfileHooks::onArticleFromTitle()

Regardless of user_page_type, UserProfile overrides it with the UserProfilePage, and then goes from there in deciding if it continues on, or if it does:

parent::view();
return '';

This means that regardless, it always uses UserProfilePage, and then the default Article class if it is not displaying the UserProfile. By making the decision if the UserProfilePage should actually show SocialProfile information in the ArticleFromTitle hook itself, not ever overwriting $article with UserProfilePage, and support returning whatever should besides an Article instance, we could probably make these two extensions at least semi-compatible.

And looking even further, the ArticleFromTitle is called from Article::newFromTitle(), if we used that instead of Article directly for the construct, it might work. Alternatively, if that doesn't work (which might not at all), the hook used in UserProfilePage could also check if UserProfilePage::view is actually returning an empty string, and not set $article to UserProfilePage if so (building the profile header and everything this is always needed from within the hook). Support does seem feasable, at least from initially looking.

Either way, it seems that the GlobalUserPage hook is not being used or is overwriten by UserProfile. With the article page always being called as UserProfilePage rather than supporting another hook changing that to be GlobalUserPage class defined in GlobalUserPage hooks.

That at least explains why it doesn't work on the actual User namespace, when using that but when using UserWiki that does appear to be caused by it not being NS_USER, instead being NS_USER_WIKI which is not what GlobalUserPage is expecting, as it checks only NS_USER when deciding when the GlobalUserPage can be displayed.