Today I can’t download extras. Is there a problem?
Where can’t you download the extras? In the MODX manager under “Extras” → “Installer”?
Can you access the site https://extras.modx.com/ and download the extras manually? Does that work?
Are there any (related) error messages that get generated in the MODX error log?
Did it work before (with the same MODX version on the same server) to connect to the extras provider?
Do you use the default provider https://rest.modx.com/extras/?
If the error is related to an SSL certificate problem, maybe take a look at this thread:
thank you @halftrainedharry i see in log :
PHP warning: simplexml_load_string(): Entity: line 1: parser error : StartTag: invalid element name
in all my modx website, https://rest.modx.com/extras/
<error>
<status>404</status>
<success>false</success>
<message>404 Not Found</message>
<description>Not found.</description>
<object/>
</error>
This response is normal, when you call the URL like this without any parameters.
What is the result if you request something more specific like this
https://rest.modx.com/extras/package?&database=mysql&revolution_version=Revolution-3.1.2-pl&supports=Revolution-3.1.2-pl&language=en&query=test&action=Workspace%2FPackages%2FRest%2FGetList
(which is a request for the list of extras with the search term = “test”)
The same problem here for several MODX 3.0.x, but all 3.1.x on same server works fine. Both Updates widget and Installer throws errors.
Seem that call to package REST API from MODX itself returns some kind of firewall or CDN challenge HTML page, not resulting XML that can be parsed, thus throwing xml parser errors. The same link called from my browser works fine:
https://rest.modx.com/extras/package?&database=mysql&revolution_version=Revolution-3.0.2-pl&supports=Revolution-3.0.2-pl&language=en&query=test&action=Workspace%2FPackages%2FRest%2FGetList
3.0 calls to MODX package REST API are now suspicious to CDN. 3.1 probably changed the way API is called (more specific client string, cookies, headers?).
I can’t see anything that has changed between MODX 3.0 and MODX 3.1 in this regard.
This is very weird.
Does this issue only happen on a specific hosting provider?
It’s possible some recent rule changes due to some malicious traffic got inadvertently applied to the package provider subdomain resulting in these challenges in certain locales. Exceptions have been implemented. Can you let us know if this is still a problem?
Right now, all our MODx sites affected today are loading without errors in package installer, though some of them take extra time to check for package updates. Weird thing is that when first reported today, all 3.0.x instances reported error while all 3.1.x were fine, all of them separate vhosts from the same apache server. Maybe just coincidence, not sure. Bot control rules on CDN and firewalls can act differently after rules update or under active ddos attack.
Btw. we have just migrated a lot of MODX instances behind AWS firewall, where Common Rule Set blocks most manager actions, so you need to take extra measures to relax those firewall rules for authenticated modx editors.
still error in modx 3.1.2, and this happened two days ago. Before that, everything was running smoothly, and it happened on both of my servers. It’s very strange. I use RunCloud and Cloudflare.
We are ok today, running on AWS EC2. While cdn firewall rules are dynamically changing, it can be that requessts from some locations or providers are blocked while others are not.
Just to be sure about reason, you can try my test setup to see what is returning from API:
- create test page with emptyy template, content-type text
- put snippet
[[!modx_test]]inside - create snippet modx_test:
<?php
$header = array();
$header[] = 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7';
$header[] = 'Cache-Control: max-age=0';
$header[] = 'Connection: keep-alive';
$header[] = 'Keep-Alive: 300';
$header[] = 'Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7';
$header[] = 'Accept-Language: en-us,en;q=0.5';
$header[] = 'Pragma: no-cache';
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, 'https://rest.modx.com/extras/package?&database=mysql&revolution_version=Revolution-3.0.2-pl&supports=Revolution-3.0.2-pl&language=en&query=test&action=Workspace%2FPackages%2FRest%2FGetList');
curl_setopt($ch, CURLOPT_USERAGENT, 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/144.0.0.0 Safari/537.36');
curl_setopt($ch, CURLOPT_HTTPHEADER, $header);
curl_setopt($ch, CURLOPT_AUTOREFERER, true);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1);
curl_setopt($ch, CURLOPT_ENCODING, '');
curl_setopt($ch, CURLOPT_TIMEOUT, 20);
$result = curl_exec($ch);
curl_close ($ch);
echo $result;
View test page. If you see correct XML result (compare with directly called API from your broser), problem is somewhere else. If you see html with cdn challenge, it’s cdn blocking API request.
1 Like