WP Multisite install - Core in a separate folder, using Subdomains, on Nginx- broken links issues

[ilibilibom]

HI
I've been trying for a while to install WP Multisite in its separate folder, and run into many issues with links and rewrites.

My root project look like this:

     - wp 
     - wp-content
     index.php 
     wp-config.php

The first issue was the the Multisite network link in admin panel would be missing the /wp/ within the URL - For example:
All network admin links in admin where:
wp-admin/network/
instead of being:
wp/wp-admin/network (this link did work when typing it in the browser).
I couldn't find an Nginx rewrite rule solution that would fix this, instead I found a WP filter function workaround that seems to work fine on the main site (was added to functions.php in activated theme).:

add_filter( "network_site_url", function( $url, $path, $scheme ){

    $urls_to_fix = array(
        "/wp-admin/network/",
        "/wp-login.php",
        "/wp-activate.php",
        "/wp-signup.php",
    );
    foreach( $urls_to_fix as $maybe_fix_url ) {
        $fixed_wp_url = "/wp" . $maybe_fix_url;
        if ( false !== stripos( $url, $maybe_fix_url )
            && false === stripos( $url, $fixed_wp_url ) ) {
            $url = str_replace( $maybe_fix_url, $fixed_wp_url, $url );
        }
    }
    return $url;
}, 10, 3 );

The issue is that on the subdomain site admin this function is not working (although it shares the same theme), all link are calling wp-admin & wp-includes instead of wp/wp-admin & wp/wp-includes

My nginx-wp-common.conf file located in -
/Users/myName/vvv/vagrant-local/config/nginx-config looks like this:

# nginx-wp-common.conf
#
# Contains a common configuration for use by nginx on a WordPress
# installation. This file should be included in any WordPress site
# nginx config with the following line:
#
#     include      /etc/nginx/nginx-wp-common.conf;
#
# See local-nginx-example.conf-sample for a full example

location /wp {
        try_files $uri $uri/ /wp/index.php?$args;
}

# Specify a charset
charset utf-8;

# Weird things happened to me when I had gzip on, may need to try
# again in the future as it could have been related to many other
# factors - JF
gzip off;

# Add trailing slash to */wp-admin requests.
rewrite /wp-admin$ $scheme://$host$uri/ permanent;

# this prevents hidden files (beginning with a period) from being served
location ~ /\. {
    access_log off;
    log_not_found off;
    deny all;
}

# Pass uploaded files to wp-includes/ms-files.php.
rewrite /files/$ /index.php last;

if ($uri !~ wp-content/plugins) {
    rewrite /files/(.+)$ /wp-includes/ms-files.php?file=$1 last;
}

# Rewrite multisite in a subdirectory '.../wp-.*' and '.../*.php'.
# Rewrite multisite '.../wp-.*' and '.../*.php'.
if (!-e $request_filename) {
    rewrite /wp-admin$ $scheme://$host$uri/ permanent;
    rewrite ^/[_0-9a-zA-Z-]+(/wp-.*) /wp$1 last;
    rewrite ^/[_0-9a-zA-Z-]+(/.*\.php)$ /wp$1 last;
}

location ~ \.php$ {

    # Try the files specified in order. In our case, try the requested URI and if
    # that fails, try (successfully) to pass a 404 error.
    try_files      $uri =404;

    # Include the fastcgi_params defaults provided by nginx
    include        /etc/nginx/fastcgi_params;

    # The amount of time for upstream to wait for a fastcgi process to send data.
    # We keep this *extremely* high so that one can be lazy when remote debugging.
    fastcgi_read_timeout 3600s;

    # Buffer size for reading the header of the backend FastCGI process.
    # This defaults to the value of a single fastcgi_buffers, so does not
    # need to be specified in our case, but it's good to be explicit.
    fastcgi_buffer_size 128k;

    # The number and size of the buffers into which the reply from the FastCGI
    # process in the backend is read.
    #
    # 4 buffers at 128k means that any reply by FastCGI greater than 512k goes
    # to disk and replies under 512k are handled directly in memory.
    fastcgi_buffers 4 128k;

    # SCRIPT_FILENAME is a required parameter for things to work properly,
    # but was missing in the default fastcgi_params on upgrade to nginx 1.4.
    # We define it here to be sure that it exists.
    fastcgi_param   SCRIPT_FILENAME         $document_root$fastcgi_script_name;

    # Use the upstream defined in the upstream variable.
    fastcgi_pass   $upstream;

    # And get to serving the file!
    fastcgi_index  index.php;
}

I would really be happy to have an Nginx solution for this issue - instead of a theme function solution that anyway doesn't work in subdomains.
Thanks you so much for helping.