WPML Incompatibility

[VR51]

The SVG icons do not show when the Simple Social Icons widget is used with WPML when WPML is configured to show alternate site language versions under masked domains. E.g. Spanish under example-spanish.com and English under example-english.com.

The fault is due to the following code not being added to the under the <li> tag of the page source of the masked domain:

<use xlink:href="http://www.example-english.com/wp-content/plugins/simple-social-icons/symbol-defs.svg#social-bloglovin"></use>

Will look through the code to see whether I can find a quick fix. Just making you aware of the bug for now.

[VR51]

As a quick fix:

1) Download the development version from https://github.com/copyblogger/simple-social-icons (less editing required with the development version)

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 with the result.

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

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. You could store the plugin directory location in an wp options for each language version of the site then load the relevant location as necessary.

[nickcernis]

You should be able to solve this by adding a Cross-Origin Resource Sharing policy to your main domain.

When the SVG asset is served from a different domain to the current site, svgxuse.js rewrites the use href attribute to the fragment identifier only (for example: <use xlink:href="#social-email"></use>). It will then make an XMLHttpRequest for the SVG file. If you have a CORS policy on your main domain that allows your other language domains to access resources there, the icons will then load. If you have no CORS policy, the request will fail and you'll have blank icons on your other language sites.

The WPML team could alternatively look into filtering plugin_dir_url to correct the domain to match the alternative language sites if they're able to.

Using a relative path for the URL as you've done is another option, but I'm wary of seeing that applied to the plugin as a permanent solution; there may be side-effects for sites that move assets off of the main domain with a CDN or similar.

[VR51]

I've added the following to .htaccess (CORS):

<IfModule mod_headers.c>
  <FilesMatch "\.(ttf|ttc|otf|eot|woff|woff2|font.css|css|svg)$">
    Header set Access-Control-Allow-Origin "*"
  </FilesMatch>
</IfModule>

Will see what happens when the plugin next updates.

For now the temp measure of hardcoding the URL works so will leave it until the plugin next updates. Not ideal to be done in a plugin, as you note, because not all sites use the same paths.

As much as I like WPML it has odd quirks that need to be fixed.

Thanks Nick. Appreciate your advice.

[nickcernis]

You're welcome! Thanks for the update, Lee, and do let us know if the CORS header doesn't solve this for you.