webmetender

Yes these are WP generated links.

As I said, I’ll leave this multisite multi-domain project away for few days and come back after a fresh installation of the whole network.

On the front-end, when I hover a link it looks like “https://main.com/secondary/article”, but after clicking the link the redirection works and the browser shows “https://secondary.com/article”.

Even on the back-end, when I edit an article, the permalink shown on the edit page also looks like “https://main.com/secondary/article”.

Anyway, I feel right now like I’m going to try once again a fresh install to check if I missed something, i’ll share again after that.

ok I tried it, I then only have “Permanent redirect” ticked and the links on secondary.com website still look like “main.com/secondary” when I pass the pointer over them.

I still don’t get if what I’d like to get is in anyway possible or if what I call an “issue” is actually the way domain mapping is intended to work…

Hi Mika,

Did you search/replace post content after mapping to change the old links?

Yes, I created articles and pages, included cross-links in the content, created menu item linking to those pages and articles, all this after the mapping job and all visible links refer to the main site.

As it is a first try for me I don’t know for exemple if secondary domain’s articles and pages permalinks, as shown on edit pages, are meant to refer to the main site or not.

Right now, if I create a post from https://secondary.com/wp-admin/, this post’s permalink looks like https://main.com/secondary/article/.
And if I create a menu item linking to that post, the link shown in the front-end will be https://main.com/secondary/article/ and not https://secondary.com/article/: is that “normal”? How to force permalinks to be generated by WP without refering to the main website?

My domain mapping config is still as described in my initial post.

Thank you for reading,

Adam

Made a mistake in the code above, actually it’s in the child theme functions.php and the 2 files required are in the child theme too, so the code should look like:

function wmt_setup(){
	if ( version_compare( get_bloginfo( 'version' ), '3.4', '<' ) )
		require_once( get_stylesheet_directory() . '/inc/wmt-options.php' );
	else
		require_once( get_stylesheet_directory() . '/inc/wmt-customizer.php' );
}
add_action( 'init', 'wmt_setup' );

Hi jmjf and thank you for your answer.

As I explained in the ‘EDIT’ section of my initial post, I already applied the solution you give but it doesn’t work: theme-customizer.php is included in the functions.php file.

Unlike any other files in child themes, functions.php does not replace the one called in parent theme but both are loaded, and functions.php from child is loaded first.

So, if from the child functions.php is called
remove_action( ‘customize_register’, ‘the_bootstrap_customize_register’ );
it will be uneffective as
add_action( ‘customize_register’, ‘the_bootstrap_customize_register’ );
will be fired again later from parent functions.php!

But i read again the-boostrap’s code and found that theme-customizer.php is included in the the_bootstrap_setup() function which is launched by the ‘after_setup_theme’ action.

Eureka! I know that the ‘init’ action fires after ‘after_setup_theme’ so I included in the functions.php of my child theme the following code

function wmt_setup(){
	if ( version_compare( get_bloginfo( 'version' ), '3.4', '<' ) )
		require_once( get_template_directory() . '/inc/wmt-options.php' );
	else
		require_once( get_template_directory() . '/inc/wmt-customizer.php' );
}
add_action( 'init', 'wmt_setup' );

You see it’s inspired by the original code, I run as well the version check to serve a option page if it’s needed.

And all works fine now with my theme-customizer.php customization!