Bad replacement of URLs in CSS

The CDN url is https://static.clearpathaction.org/
It is not https://static.clearpathaction.org/wp-content/uploads/

I’ll upload a screenshot of the configuration shortly.

I’m purging the cache and re-applying my changes so the site works for now.

Screenshot: https://pasteboard.co/Jh1jf0d.png

If you want a different path on the cdn than the one on the live site, then the plugin doesn’t support that. I don’t think also, any (or the majority at least) of cdn /cache rewriting plugins will support that either.

According to the configuration, the default path that would be used is;
https://static.clearpathaction.org/wp-content/uploads

Yet I specified;
https://static.clearpathaction.org/

If I chose https://static.clearpathaction.org/wp-content/uploads would the resulting URL be https://static.clearpathaction.org/wp-content/uploads/wp-content/uploads?

• This reply was modified 4 years, 4 months ago by youngcp.

If $domain or site_url(); return https://clearpathaction.org and the cdn url is correct as static.clearpathaction.org, replacing clearpathaction.org with static.clearpathaction.org would do just that, so the issue is not there but rather somewhere else.

Do you have any static.clearpathaction.org urls hardcoded on your css/js files?
Look at the ones listed on the logs via the tatus page on FVM.

Also leave the cache path url empty, because you are telling wordpress that your site IS static.clearpathaction.org instead of the actual website.

Do you have any static.clearpathaction.org urls hardcoded on your css/js files?

Yes, there are lots of images and other content that was moved directly to the CDN and many of those URLs were in a previous WordPress instance or are mirrored from the current uploads directory.

Much of the CSS likely has static.clearpathaction.org as a base URL.

If you’re replacing those clearpathaction.org -> static.clearpathaction.org (static.clearpathaction.org -> static.static.clearpathaction.org) and using fvm_get_protocol to generate the URL, I can see how that’d be a problem, but that’s also a bug. You probably want to check for a ‘//’ prefix on the path, or barring that, check do a preg negative lookback or something to prevent replacing a subset of the domain.

• This reply was modified 4 years, 4 months ago by youngcp.

For best practice, I suggest changing your urls inside the css files to relative paths. What will you do if someday you need to change the cdn subdomain for whatever reason, or decide to move to cloudflare or other similar service, and stop using the cdn?

If you use relative paths, as long as your css /js files are pointed to the cdn and being served from there, all relative files will also be served directly from the same subdomain, and your code is portable to any staging / cdn, etc of your choice.

I know that some developers just hardcode urls inside css files, but this is not good practice. All WordPress plugins and themes on wordpress, use relative paths (to the css file), not absolute paths.

I can agree when you say that FVM should try to guess when developers are wrongly hardcoding urls (just because it works, it doesn’t need it’s right)… but this is more of an extra compatibility step, rather than a bug. Under normal circumstances with any free or paid plugin, it doesn’t happen.

Yes, I will still add an extra check sometime in the future to try to avoid that situation, but until then and for the sake of portability, I suggest doing a sed replace on your files and either make them relative to the root, or to each css file.

Something like this below, in that order… followed by a cache purge should work:

find . -type f \( -iname \*.js -o -iname \*.css \) -exec sed -i "s#https://static.clearpathaction.org/wp-content/#/wp-content/#g" {} \;
find . -type f \( -iname \*.js -o -iname \*.css \) -exec sed -i "s#https://static.clearpathaction.org/wp-content/#/wp-content/#g" {} \;
find . -type f \( -iname \*.js -o -iname \*.css \) -exec sed -i "s#//static.clearpathaction.org/wp-content/#/wp-content/#g" {} \;
find . -type f \( -iname \*.js -o -iname \*.css \) -exec sed -i "s#static.clearpathaction.org#clearpathaction.org#g" {} \;

But I take no responsability… so please test it and take a backup.
The last command will simply normalize the domain for any leftover url… then FVM can do the replacements as needed.

If you use relative paths, as long as your css /js files are pointed to the cdn and being served from there

I shouldn’t have to use relative urls, especially in the cases where the content doesn’t exist nearby, just on the CDN.

I’m not going to ‘fix’ the existing absolute urls; if the plugin fails or is disabled I don’t want the client falling back to the PHP host, the load during an election season would tank the response of the site, and some of the content would just not exist.

If CloudFront fails we can deploy a fallback static content local instance from backups by updating the DNS records.

• This reply was modified 4 years, 4 months ago by youngcp.

I shouldn’t have to use relative urls, especially in the cases where the content doesn’t exist nearby, just on the CDN.

Most sites don’t usually delete the local copy from the server and just mirror it to the cdn, so it’s usually always available.

But I completely agree on that (sorry), especially for video or large files where this may not always be true.

I’ll add that extra check in the future, so thanks for reporting.

Most sites don’t usually delete the local copy from the server and just mirror it to the cdn, so it’s usually always available.

There were previous servers, the content was mirrored to the CDN but not downloaded back to the new server. The EC2 instances that host the WordPress are allocated with very thin storage provisions. Most of the storage is dealing with cache for the S3 mirrored/exported content already. Not gonna fork out for a lot of local storage, S3 is cheap.

Yes of course… though, if you have control over the server, mounting the S3 Bucket would be an option as well (though a bit slow).

Thanks