loboyle

Hi,

Sorry for the delay, went on holiday just after asking this 🙂

I had dived in to the W3TC code and what it’s doing is just mirroring the local filesystem structure up in to S3; because the files are located on the server under /wp/whatever, it gets put up to S3 as /wp/whatever. It’s not checking the siteurl or home parameters at all (it generally wouldn’t need to). Makes sense and W3TC has no way of knowing that I’m rewriting the requests.

A fix could be made to to W3TC to try to incorporate some logic there, but I haven’t had much luck asking for some badly needed fixes in the past so won’t hold out much hope 🙂

I’d seen the gist that you point to, but it’s doing the exact opposite of what I actually want. I’m trying to hide the /wp/ subdirectory, not force it back in again!

However, I did find a reasonably straightforward workaround when I looked at again after a month of rest. Let W3TC push the upload into S3 under the subdirectory /wp/, then just move the files in S3 to remove the subdirectory prefix. All of the rest of the rewriting then works fine, you just need to remember to do this any time you upgrade your WP version and have W3TC push up the includes to S3.

To illustrate this new flow (changes to the above in bold)

1. in my root, I have the file /wp/wp-includes/js/heartbeat.js
2. W3TC uploads this to the CDN at /wp/wp-includes/js/heartbeat.js
3. In S3 manually move /wp/* to /
4. WP enqueues the script as /wp-includes/js/heartbeat.js because the /wp/ is not in the siteurl (deliberately, because we’re rewriting this)
5. W3TC scans the output from WP and rewrites the link to the CDN at /wp-includes/js/heartbeat.js which now works because we’ve moved the synced files