sift.js missing (404 errors)
-
Having updated the WooCommerce Tax plugin (folder name woocommerce-services) to v3.4.1 earlier today, I’m now getting many Apache error log lines like with a 404 for the file /wp-content/plugins/woocommerce-services/assets/javascript/sift.js?ver=3.4.1
I’ve had a closer look, and there is no assets folder, let alone a javascript subfolder, nor a sift.js file.-
This topic was modified 2 months ago by
Erik Geurts.
-
This topic was modified 2 months ago by
-
That’s a frustrating issue! It sounds like the WooCommerce Tax plugin update didn’t complete properly, leaving behind references to JavaScript files that weren’t actually included in the new version. Are you seeing any functional issues with the tax calculations, or is it just the Apache error logs that are concerning?
Here are a few steps to try:
- If you’re using caching or optimization plugins, clear all caches and temporarily disable them to see if that resolves the 404 errors.
- Try deactivating and reactivating the WooCommerce Tax plugin, or delete and reinstall it fresh from your account area and manually reinstall it.
- If the issue persists, try a conflict test by temporarily disabling other plugins to see if something else is interfering.
I hope that helps. Let us know how that goes.
Regarding the steps you suggested:
- I encountered this issue on a staging site, with no caching or optimization plugins present, so that can’t be the cause.
- I’ve downloaded the .zip file of the latest incarnation of the plugin, and there is no assets folder in there either. It appears to be a build problem by the developers.
- It’s not a conflict with other plugins, the affected file literally doesn’t exist.
It’s not an incomplete or faulty updated either, as mentioned above, the most recent incarnation of the plugin simply doesn’t ship with the file that’s being requested.
I don’t see any functional problems in the site, it’s purely about large numbers of 404 errors. This does cause issues, because we’ve built an in-house system that will block any IP address from accessing the server once a larger-than-acceptable number of 404/500/503 log entries has been created by that IP address.
Is there a Github repository where I can report this issue?
Thanks so much for the update, really appreciate you taking the time to dig into it.
I also checked the plugin files on my end, going all the way back to version 3.2.2, and I can confirm the same thing you’re seeing: the
assets/javascript/sift.jsfile (and even the parent folders) have never existed in any of the releases. I also set up a tax rate, ran through checkout, and monitored for PHP or server‑side errors, but I wasn’t able to reproduce the 404s you’re encountering.For reference, the plugin repository is here:
https://github.com/Automattic/woocommerce-services
…but based on what we’re seeing so far, we haven’t been able to trigger the issue yet.Out of curiosity, does this missing file actually break anything on your site, or affect how taxes are calculated or displayed? Also, do you recall which version you were on before noticing the 404s? If you roll back to that version, does the request for
sift.jsstill appear? And roughly when did you first notice the errors? That timeline might help us pinpoint where the change was introduced.Looking forward to your findings.
Along with woocommerce-services, I updated a bunch of other WooCommerce plugins around the same time, and after that, I looked at various settings pages and other pages to have a look at the changes, additions and fixes in all of these plugins, following along the change logs.
My guess is that one of these other plugins may still contain references to sift.js. That might also explain why I haven’t seen those 404s for sift.js before, I may simply never have opened a settings page that calls it.
I’m going to revisit this, trying to mimic what I did last week, and see if I can figure out from which settings page (and ideally also from which plugin) the calls to sift.js originate.
That makes a lot of sense, and I appreciate the methodical approach you are taking to trace this back. If another WooCommerce extension is still enqueueing sift.js, that would definitely explain why the file is being requested even though it is not part of the WooCommerce Tax plugin itself.
A good next step would be to open your browser’s developer tools, check the Network tab, and inspect the 404 request for sift.js to see which script or page is initiating it. You could also temporarily activate the Query Monitor plugin to review enqueued scripts on the affected settings pages, which may help pinpoint the plugin responsible.
Once you identify the source, sharing that detail here or on the relevant plugin’s GitHub repository would help move things forward quickly.
Looking forward to what you uncover.
I was a bit surprised to find that immediately following login, I saw the first call to sift.js happening right at /wp-admin/ . On the same page (a bit higher up in the network list, I see a call to https://cdn.sift.com/s.js, which must be related. Having it happen at /wp-admin/ of course makes it hard to point to which of the other plugins exactly is causing this.
There is a snippet of code towards the end of the page’s HTML like this:
<script src="https://cdn.sift.com/s.js" id="sift-science-js" data-wp-strategy="defer"></script>
<script id="wc-services-sift-js-before">
var wcServicesSiftConfig = {"beacon_key":"{redacted}","user_id":{redacted}};
//# sourceURL=wc-services-sift-js-before
</script>
<script src="https://{redacted}/wp-content/plugins/woocommerce-services/assets/javascript/sift.js?ver=3.4.1" id="wc-services-sift-js"></script>As mentioned last week, the odd calls to sift.js occured on our staging site after I updated various WooCommerce related plugins. I also just checked one of our production sites that I haven’t updated yet, and there I still see the call to https://cdn.sift.com/s.js but no call to https://{redacted}/wp-content/plugins/woocommerce-services/assets/javascript/sift.js?ver=3.4.1 .
This appears to demonstrate that the new behavior in the staging site is related to one of those updated plugins on my staging site. I’ll continue digging to see if I can figure out which one it is. But I have a slight suspicion it might be the “WooCommerce Stripe Gateway” plugin…
I have updated all plugins that had a new version available in one of our production sites, one after the other. Before I started, I saw calls to https://cdn.sift.com/s.js happening in /wp-admin/ and also on the plugin list and all other backend pages.
However, after I updated WooCommerce Tax (previously WooCommerce Shipping & Tax) from 3.3.1 to 3.4.1, all calls to https://cdn.sift.com/s.js stopped appearing, and no call to sift.js was added either.
This seems to indicate that something went wrong updating WooCommerce Tax in my staging site, when I ran that update last week. So I reuploaded WooCommerce Tax there, and the plugin manager offered to replace it, but afterwards, there were still calls to sift.js and to https://cdn.sift.com/s.js
I can’t really explain this. I’ll continue digging. The good news is that this issue isn’t occurring in the production site.
In the relevant Github repo, there was a commit last week that was related exactly to this matter:
https://github.com/Automattic/woocommerce-services/commit/8a9e8ce9593283bd6eb106c061d63070413640c5
https://github.com/Automattic/woocommerce-services/pull/2922
Thank you for the detailed follow up and for linking the specific GitHub pull request related to this. I really appreciate the time you have invested in tracking this down so thoroughly.
I have taken a look at the pull request you shared, and I can confirm that it directly addresses the exact behavior you are seeing, namely the
wc-services-sift-jsreference that results in the 404 forassets/javascript/sift.js. That aligns perfectly with the errors you are encountering in your staging environment.Since there is already an open pull request that resolves this, it means the fix has been identified and merged into the development workflow. Once the next release of WooCommerce Tax is published, this incorrect script reference should no longer be enqueued, and the 404 errors should stop occurring.
In the meantime, as this is only affecting the staging site and not production, you may choose to temporarily ignore the 404s there, or monitor the plugin changelog for the upcoming release here:
https://wordpress.org/plugins/woocommerce-services/#developersThanks again for digging into this and sharing the commit and PR links, that was extremely helpful in narrowing it down.
There appears to have been some caching at work, because after a while the production site also started to call the sift.js file that’s missing. As a work around I’ve created an empty file in that exact spot so that at least the browser has something to retrieve (albeit 0 bytes).
That PR https://github.com/Automattic/woocommerce-services/pull/2922 I found has been merged on February 10th, so 1 day after the most recent release 3.4.1. I guess it’s a matter of patiently waiting for the next bug fix release to be published….
You have done a really thorough job tracing this down, and creating the empty file as a temporary mitigation makes sense given your 404 monitoring rules.
You are correct. The fix was merged after the 3.4.1 release, so that version still contains the incorrect
wc-services-sift-jsreference. The next bug fix release of WooCommerce Tax should remove the stray enqueue and stop the 404s.For now, your empty placeholder file is a reasonable temporary workaround to prevent log noise and IP blocking.
I’ve set a ‘watch’ on the Github repository so that I get informed straight away when the next release is posted.
That sounds like a solid plan, and it is great that you have set up notifications on the repository to stay informed.
Once the next WooCommerce Tax release is published, please go ahead and update and let us know whether the stray sift.js enqueue is fully resolved on your end. Keeping the thread updated will definitely help others who might encounter the same behavior.
We will also keep an eye on the release notes or subscribe to receive notification about plugin update:
https://wordpress.org/plugins/woocommerce-services/#developers. Looking forward to your update after the next release.I can confirm that version 3.5.0 of this plugin fixes this issue. There is still a call to the external https://cdn.sift.com/s.js
That is great to hear, and I really appreciate you coming back to confirm that updating to version 3.5.0 resolved the missing
sift.js404 issue on your end. Thank you as well for the thorough investigation throughout this thread, it was incredibly helpful.Regarding the remaining call to
https://cdn.sift.com/s.js, that is expected behavior. A script tag for Sift was introduced in the previous update, however the local assetassets/javascript/sift.jswas not included in the build at the time, which is what led to the 404 error you were seeing. As outlined in the pull request you referenced, the issue was specifically about the missing local file in the packaged release, not the external Sift script itself: https://github.com/Automattic/woocommerce-services/pull/2922Now that the incorrect local enqueue has been removed in 3.5.0, the 404s should no longer occur, while the external Sift script can still load as intended.
Since everything is now working as expected, I will go ahead and consider this fully resolved. If WooCommerce has been helpful in your workflow, we would truly appreciate a 5 star review here, it helps a great deal and supports continued improvements: https://wordpress.org/support/plugin/woocommerce-services/reviews/#new-post. Thanks again for your detailed follow up and collaboration on this one.
You must be logged in to reply to this topic.
