xlink:href changes when plugin used with domain mapping

You could either:

1. Ask your web host for help creating a Cross Origin Resource Sharing Policy that allows your subsites to load the icon file from your main shspestcontrol.com domain.

2. Ask the “Multiple Domain Mapping on Single Site” plugin developer to consider rewriting asset URLs for any page that is using a different domain. That way, the request for the icon file on https://www.pestcontrolri.com/ would be:

https://www.pestcontrolri.com/shs/wp-content/plugins/simple-social-icons/symbol-defs.svg

…instead of:

https://shspestcontrol.com/shs/wp-content/plugins/simple-social-icons/symbol-defs.svg

And your icons would load on all domains.

Personally I would choose option 1.

To be sure I am understanding correctly,

The request for the icon image file from any Page or Post that uses https://www.pestcontrolri.com/ is only using the path
<use xlink:href=”#social-email”></use>
It does not include the full path.

Where as, from any Page using https://shspestcontrol.com the image file request uses the full path
<use xlink:href=”https://shspestcontrol.com/shs/wp-content/plugins/simple-social-icons/symbol-defs.svg#social-email”></use>

So creating a redirect from the full path (A) https://www.pestcontrolri.com/shs/wp-content/plugins/simple-social-icons/symbol-defs.svg
to (B)
https://shspestcontrol.com/shs/wp-content/plugins/simple-social-icons/symbol-defs.svg
would not work, as (A) does not exist.
Correct?

I have sent your suggestion to the plugin developer for Domain Mapping.

Thanks

I have the same problem. Just flagged it on Github at https://github.com/copyblogger/simple-social-icons/issues/48

This affects WPML when domain masking is used, too. The <use .*> code is not being written into the source code of the masked domain.

As a quick fix:

1) Download the development version from GitHub at https://github.com/copyblogger/simple-social-icons

2) Upload the dev version to your site using cPanel (don’t unzip yet)

3) Use cPanel to delete the directory named simple-social-icons

4) Unzip the dev version. Change the directory name to simple-social-icons (i.e. remove the -development suffix)

5) Browse the simple-social-icons directory and edit the file simple-social-icons.php.

6) Scroll toward the bottom of the file.

Replace:

$markup .= '<use xlink:href="' . esc_url( plugin_dir_url( __FILE__ ) . 'symbol-defs.svg#social-' . $icon ) . '"></use>';

With

$markup .= '<use xlink:href="' . '/wp-content/plugins/simple-social-icons/symbol-defs.svg#social-' . $icon . '"></use>';

7) Save the file and clear your caches.

All we have done is hard-code the directory for the font file.

I looked into removing just esc_url() and setting a variable for plugin_dir_url( __FILE__ ) but neither worked, or maybe my cache interfered.

As I say, it is a dirty quick fix but it works.

Another fix would be to dynamically build the directory location differently but I’ll leave that to the developers of Simple Social Icons to do.

@tonim07

The request for the icon image file from any Page or Post that uses https://www.pestcontrolri.com/ is only using the path
<use xlink:href="#social-email"></use>
It does not include the full path.

The path used on https://www.pestcontrolri.com/ looks like this in the raw source to me:

<use xlink:href="https://shspestcontrol.com/shs/wp-content/plugins/simple-social-icons/symbol-defs.svg#social-linkedin">

(This is being rewritten by the svgxuse.js JavaScript, which is why you see <use xlink:href="#social-linkedin"> in dev tools.)

The file is failing to load because it’s requesting the SVG from another domain. I originally said that a CORS policy could help with this, but that doesn’t seem to be the case after more research – it looks like CORS doesn’t currently work for SVG due to a bug that affects Chrome and other browsers.

The solution from @leehodson works around this by using a relative path instead of a full one, so you’d end up with this:

<use xlink:href="/wp-content/plugins/simple-social-icons/symbol-defs.svg#social-linkedin">

But it requires hard-coding the path into the plugin. I’ll look into some alternative solutions to see what can be done here.

@tonim07 Are you willing to try adding a CORS policy to your main site at https://shspestcontrol.com/ ? I believe doing so will solve this for you.

I found that the svgxuse.js script attempts to load the icons dynamically if they’re served from another domain. This will work around the browser bug I mentioned before and allow the icons to load if your CORS policy is in place.

You could set your CORS policy on shspestcontrol.com to allow access for all domains (like this: https://enable-cors.org/server_apache.html ), or only on the domains you’re using. Please feel free to report back to let me know if this resolves things for you.

@leehodson I replied in the GitHub issue you kindly shared, but the same solution applies – a CORS policy will allow your alternative-language domains to load the SVG file from the main domain with AJAX, without hardcoding changes to the plugin.

• This reply was modified 8 years, 1 month ago by Nick C.

Thank you, Nick.

Thanks for all the replies and info…

I added to .htaccess file in root directory

Header set Access-Control-Allow-Origin “https://www.pestcontrolri.com&#8221;

and the images are now showing on pestcontrolri.com page and posts.

Question — does this open any doors to potential hackers or malicious code..?

Thanks

Great to hear this worked for you, @tonim07.

> does this open any doors to potential hackers or malicious code..?

The change allows one site you own to access resources from another site you own; it won’t open it up to hackers.