Home›Support›English Support›[Resolved] 403 error when installing WPML via ffraenz/private-composer-installer
[Resolved] 403 error when installing WPML via ffraenz/private-composer-installer
This thread is resolved. Here is a description of the problem and solution.
Problem: If you're using the ffraenz/private-composer-installer for WPML updates and encountering a 403 Forbidden error during the download process, despite correct credentials, this might be due to how requests are handled. Specifically, requests made with a Composer User-Agent are not following the normal download flow and are instead being blocked, likely at the WAF/CDN level. Solution: Currently, WPML installation and updates via Composer are not officially supported, as indicated here: https://wpml.org/errata/composer-installation-of-wpml-not-officially-supported-yet/. This means that setups like ffraenz/private-composer-installer might behave inconsistently. We recommend checking if explicitly setting a specific plugin version in your Composer config instead of relying on 'latest' helps. Also, verify if the same method still works with other plugins to determine if the issue is WPML-specific or more general.
If this solution does not resolve your issue or seems irrelevant due to updates or changes, we highly recommend checking related known issues at https://wpml.org/known-issues/, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins. If the problem persists, please open a new support ticket at WPML support forum for further assistance.
This is the technical support forum for WPML - the multilingual WordPress plugin.
Everyone can read, but only WPML clients can post here. WPML team is replying on the forum 6 days per week, 22 hours per day.
We’ve been using the ffraenz/private-composer-installer to handle our WPML updates for quite a while now, but we’ve recently run into an issue. Every time we try to run an update, we're hitting a 403 Forbidden error during the download process.
The strange thing is that our credentials are definitely correct. If I take the exact URL that Composer generates and paste it directly into my browser, the download starts immediately without any issues. It only seems to fail when the request is made through the terminal/Composer.
I was wondering if something has changed on your end recently? It feels like the request might be getting flagged by a firewall or a User-Agent block. Also, could you let me know what the status on the official composer package currently is?
Because of that, setups like ffraenz/private-composer-installer can break or behave inconsistently. The difference between browser and Composer requests is likely related to how headers/authentication are handled or filtered. Since it worked in the past, it’s possible something changed either on our side or in the Composer setup, I can not tell at this moment.
To further try to narrow it down, I see in GitHub you need to explicitly set the plugin version in your Composer config. If no version is defined, the download can fail. Have you already tried setting a specific version instead of relying on “latest”?
Also, could you confirm if the same method still works with other plugins? This would help determine if the issue is WPML-specific or more general.
I did some testing and I can now reproduce the issue very clearly. I used the exact same download URL (same download, user_id, subscription_key, version) from the same machine/IP and only changed the User-Agent:
With a browser-like User-Agent, I get HTTP 302 and a redirect to the signed CDN ZIP URL.
With User-Agent: Composer/2.8.0, I get HTTP 403 directly (server: awselb/2.0), no redirect.
So credentials/version don’t seem to be the problem here, because with the same credentials the request works as soon as it looks like a browser request. It looks like non-browser/composer-style requests are being blocked or filtered before the normal download flow.
Could you check if there is currently a WAF/bot rule or any policy that blocks Composer/private-installer requests downloads?
Also, could you please share what the recommended machine-to-machine update path is right now, and if there is any updated timeline for official Composer support?
Thank you for the detailed testing and explanation this is very helpful.
I will check this further with our internal team and systems to better understand what might be causing this behavior. Please note that it may take a day or two before I have a concrete update.
Regarding Composer support, this is currently tracked as a feature request. I’ve added your vote to it, but at the moment we don’t have an estimated timeline for when it might be implemented.
I’ll get back to you as soon as I have more information.
Thank you for your patience while I checked this internally.
After reviewing this with our systems team, I can confirm that WPML installation and updates via Composer (including setups like ffraenz/private-composer-installer) are not officially supported at this time.
What we’re seeing matches your findings:
- Requests with a browser-like User-Agent follow the normal flow (302 → signed CDN URL → download)
- Requests with a Composer User-Agent are returning a 403 before reaching that stage
This indicates that such requests are likely being filtered upstream (WAF/CDN level), based on factors like User-Agent, headers, or automated request patterns.
Since Composer based installations are not part of our officially supported or tested flow, these requests are not currently whitelisted and may be blocked by security rules protecting the download endpoints.
At the moment, this is tracked internally as a feature request, and it will be up to our development team to evaluate if and when this will be supported. Unfortunately, there isn’t anything we can adjust or enable from our side right now to change this behavior.
Please let me know if you have any further questions.
