patrickposner

Hey @erikmolenaar,

thanks for your report!

They should definitely be included by default – the problem often is related to file permissions.
We try to include the wp-includes files automatically (JS/CSS/images), but often we are getting blocked by the server itself.

This is often done as a “security mechanism” at the hosting level or as part of a caching mechanism to artificially boost performance (like on InstaWP).

There isn’t a whole lot we can do here, but you should see the result of our copy process in the debug log (it will tell you which files we haven’t been able to copy!)

@muraokashotaro great catch!

I’m getting this fixed right away and including it in the next update!

Much appreciated!

@revixi5 Try again now with 3.6.8 – looks like I’ve missed parts of the SVG problem on the last version, but it should handle both cases now!

@revixi5 fixed now in today’s update!

We are going to improve that with the next update to avoid that – you probably have some old constants in your wp-config.php file flagging this even though the plugin isn’t active.

Hey @johnwuser1245,

thanks for reaching out!

Simply Static replaces URLs by looking for your WordPress Site URL (Settings → General → Site Address) in the generated HTML/CSS/JS files and swapping it with the destination URL (or converting to relative paths).

Your WordPress staging site’s Site URL is set to http://10.16.205.66. When Elementor and other plugins generate CSS/JS, they embed that internal IP as the base URL. Simply Static then:

1.Fetches all pages from http://10.16.205.66
2.Looks for http://10.16.205.66 in the output files to replace it
3.Replaces it with relative paths (if you chose “relative URLs”) or your destination URL

If URLs in the generated files don’t match the Site URL exactly (e.g., protocol mismatch http vs https, trailing slash differences, or the URL was hardcoded differently), they won’t be replaced. The CORS error you’re seeing confirms that http://10.16.205.66 URLs are leaking through into the static output served on https://arbitcds.com.

What To Do

1. Your staging site’s Site URL should be your staging site’s actual URL (the internal IP or local domain). Don’t change it to the production domain — that would break WordPress admin and routing.
2. Enable “Force URL Replacement”
   This is in Simply Static → Settings → General. It does a final string replacement pass on all files.
3. Check the “Origin URL” and “Destination URL” in Simply Static Settings
   Go to Simply Static → Settings → General and verify:
   • Origin URL: Should be http://10.16.205.66 (matching your WP Site URL exactly, including protocol and no trailing slash
   • Destination URL: Should be https://arbitcds.com (your production domain)
   If these don’t match what’s in your files, replacement will silently fail.
4. Check for protocol mismatches
   The most common reason “force replace” doesn’t work is a protocol mismatch. Your staging uses http:// but if any plugin generates https://10.16.205.66 URLs (or vice versa), those won’t match the origin pattern. You can add a filter to handle both:
   
   add_filter( 'ss_origin_url', function( $origin_url ) {
// Ensure both http and https variants are covered
return $origin_url;
} );
   
   Or better yet, add custom force-replace entries. In Simply Static → Settings → General, under “Force URL Replacement”, add entries for both protocols:
   
   • http://10.16.205.66 → https://arbitcds.com
   • https://10.16.205.66 → https://arbitcds.co
5. Check for hardcoded URLs in Elementor data
   Elementor stores URLs in postmeta as serialized data. Sometimes URLs are hardcoded with the full domain. After export, grep your static output:
   
   grep -r "10.16.205.66" /path/to/static/output/
   
   This will show you exactly which files still contain the unreplaced IP. Share the file types (.html, .css, .js) — this helps narrow down where replacement is failing.
6. Try absolute URL mode first
   
   Try absolute URL replacement first instead of relative. Set the Destination URL to https://arbitcds.com and disable relative URLs temporarily. This is easier to debug because you can grep the output for the old IP address. Once that works, you can switch back to relative if needed.

Hey @awaisaltafwds,

we are not allowed to do support for the pro version in the forum – please reach out via our dedicated pro support on our website, and we are happy to help you, thanks!

Hey @maddogtannen,

this has been already fixed in our latest dev version – please use our official support channel to get a link to it as we are not allowed to do support for the pro version here.