I am on the Network tab in developer tools.
When clicking “Check for Updates”, the screenshot below is showing the first portion of what shows in the network tab, but I’m not seeing any reference to workspace/packages/update-remote
I apologize for my ignorance on this, but where should I be looking? Should I click on the name of one of these specific items and looking at the “Headers” tab?
When you click the “Check for Updates” button, it should add only one new request at the bottom of the list.
(Maybe delete the list before clicking the button or filter it to only show “XHR” requests).
Then when you click the request in the list, a new window opens (on the right side) with different tabs. You can see the request parameters in the “Request” tab and the JSON-response in the “Response” tab.
In your browser, it probably looks slightly different.
Thanks for the clarification. I switched to Firefox from Chrome, so now we are on the same page.
When I click “Check for Updates”, it did load an additional request with the action you had mentioned, but this request along with a few others are 404. In the Headers tab, it says that it is posting to /connectors/index.php, which has the 404 status, but that file is in place on the server.
Every AJAX-request goes to this “connector”. The action parameter then determines what “processor” gets executed. In this case it’s the file core/model/modx/processors/workspace/packages/update-remote.class.php.
In the processor the code makes a request to the MODX API to check if there are updates.
The URL is something like this https://rest.modx.com/extras/package/update?signature=ace-1.9.3-pl (there are additional parameters). Can you open this URL in the browser?
Understood. Thanks for the explanation.
I didn’t see any URL like that linked or showing up anywhere in the dev tools.
The request to the MODX API happens on the server. You don’t see this in the developer tools, because it doesn’t happen on your computer.
I opened the https://rest.modx.com/extras/package/update?signature=ace-1.9.3-pl in the browser. The result in the browser says “This XML file does not appear to have any style information associated with it. The document tree is shown below.”
So it works correctly in your browser.
To test if it works on your server, can you (temporarily) add some log lines to the code here?
This on line 42
$this->modx->log(modX::LOG_LEVEL_ERROR, 'curl request to ' . $host . $path);
and this one on line 53.
$this->modx->log(modX::LOG_LEVEL_ERROR, 'curl response is ' . $result);
Then click the “Check for Updates” button and check the MODX error log to see if both lines got logged.
There also seems to be no proper error handling in the code above.
So you could try replacing line 52 ($result = trim(curl_exec($ch));) with this code instead:
$result = curl_exec($ch);
if ($result === false) {
$info = curl_getinfo($ch);
$this->modx->log(modX::LOG_LEVEL_ERROR, 'CURL ERROR: ' . print_r($info, 1) );
} else {
$result = trim($result);
}
Maybe this gives more insight into what’s going on.
Here’s what was added to the error log after making your suggested changes, and “checking for updates”. It appears these same errors were happening before as well, as they are showing in the error log as well.
[2023-03-01 21:19:44] (ERROR in xPDO::getService @ /home/mysite/core/xpdo/xpdo.class.php : 1235) modRestClient::__construct is deprecated since version 2.3.0. Use the modRest classes instead.
[2023-03-01 21:19:44] (ERROR in modRestCurlClient::__construct @ /home/mysite/core/model/modx/rest/modrestcurlclient.class.php : 26) modRestClient::__construct is deprecated since version 2.3.0. Use the modRest classes instead.
[2023-03-01 21:19:44] (ERROR @ /home/mysite/core/model/modx/rest/modrestcurlclient.class.php : 42) curl request to https://rest.modx.com/extras/package
[2023-03-01 21:19:44] (ERROR in xPDO::getService @ /home/mysite/core/xpdo/xpdo.class.php : 1235) modRestClient::__construct is deprecated since version 2.3.0. Use the modRest classes instead.
[2023-03-01 21:19:44] (ERROR in modRestCurlClient::__construct @ /home/mysite/core/model/modx/rest/modrestcurlclient.class.php : 26) modRestClient::__construct is deprecated since version 2.3.0. Use the modRest classes instead.
[2023-03-01 21:19:44] (ERROR @ /home/mysite/core/model/modx/rest/modrestcurlclient.class.php : 42) curl request to https://rest.modx.com/extras/package
[2023-03-01 21:19:46] (ERROR in xPDO::getService @ /home/mysite/core/xpdo/xpdo.class.php : 1235) modRestClient::__construct is deprecated since version 2.3.0. Use the modRest classes instead.
[2023-03-01 21:19:46] (ERROR in modRestCurlClient::__construct @ /home/mysite/core/model/modx/rest/modrestcurlclient.class.php : 26) modRestClient::__construct is deprecated since version 2.3.0. Use the modRest classes instead.
[2023-03-01 21:19:46] (ERROR @ /home/mysite/core/model/modx/rest/modrestcurlclient.class.php : 42) curl request to https://rest.modx.com/extras/package/update
[2023-03-01 21:19:50] (ERROR in xPDO::getService @ /home/mysite/core/xpdo/xpdo.class.php : 1235) modRestClient::__construct is deprecated since version 2.3.0. Use the modRest classes instead.
[2023-03-01 21:19:50] (ERROR in modRestCurlClient::__construct @ /home/mysite/core/model/modx/rest/modrestcurlclient.class.php : 26) modRestClient::__construct is deprecated since version 2.3.0. Use the modRest classes instead.
[2023-03-01 21:19:50] (ERROR @ /home/mysite/core/model/modx/rest/modrestcurlclient.class.php : 42) curl request to https://rest.modx.com/extras/package/update
[2023-03-01 21:19:52] (ERROR in xPDO::getService @ /home/mysite/core/xpdo/xpdo.class.php : 1235) modRestClient::__construct is deprecated since version 2.3.0. Use the modRest classes instead.
[2023-03-01 21:19:52] (ERROR in modRestCurlClient::__construct @ /home/mysite/core/model/modx/rest/modrestcurlclient.class.php : 26) modRestClient::__construct is deprecated since version 2.3.0. Use the modRest classes instead.
[2023-03-01 21:19:52] (ERROR @ /home/mysite/core/model/modx/rest/modrestcurlclient.class.php : 42) curl request to https://rest.modx.com/extras/package/update
[2023-03-01 21:19:52] (ERROR in xPDO::getService @ /home/mysite/core/xpdo/xpdo.class.php : 1235) modRestClient::__construct is deprecated since version 2.3.0. Use the modRest classes instead.
[2023-03-01 21:19:52] (ERROR in modRestCurlClient::__construct @ /home/mysite/core/model/modx/rest/modrestcurlclient.class.php : 26) modRestClient::__construct is deprecated since version 2.3.0. Use the modRest classes instead.
[2023-03-01 21:19:52] (ERROR @ /home/mysite/core/model/modx/rest/modrestcurlclient.class.php : 42) curl request to https://rest.modx.com/extras/package/update
So the request happens, but the response never gets logged.
Did you also apply this change?
$result = curl_exec($ch);
if ($result === false) {
$info = curl_getinfo($ch);
$this->modx->log(modX::LOG_LEVEL_ERROR, 'CURL ERROR: ' . print_r($info, 1) );
} else {
$result = trim($result);
}
I did apply that other change mentioned as well. After I made the changes you mentioned to that PHP file, I cleared the cache and refreshed before trying the Installer page again.
Something with this cURL request doesn’t seem to work.
Can you create a snippet with a simple cURL request like this and call it on a page to see if there is a general problem with cURL?
<?php
$url = 'https://catfact.ninja/fact';
$curl = curl_init();
curl_setopt($curl, CURLOPT_URL, $url);
curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);
curl_setopt($curl, CURLOPT_HEADER, false);
$data = curl_exec($curl);
curl_close($curl);
return $data;
I added this as a snippet called “testSnip”, then added [[testSnip]] to the bottom of one of our web pages. When I refreshed the page, I got a 503 error.
Does anything get logged to the server error log this time?
Nothing appears to have been logged, but based on the date/time stamps on the error logs, is it possible that the error log files are only updated once a day by the host (godaddy)?
I’ve tested this by forcing the same 503 error again, and a few moments later downloading the error log to see if it had been changed, but it is the same as the copy I downloaded 10 minutes ago.
When you go the “System Info” page in the MODX manager (manager/?a=system/info) and click the “View” link in the line “phpinfo():”, is there a cURL section on the phpinfo page and is cURL support enabled?
Maybe you could also ask your host if they changed anything recently concerning cURL.
It shows cURL support enabled & cURL Information 7.84.0, but I will follow up with Godaddy to see what they have to say.
Thank you!
Hello,
It’s been a few weeks, but I finally had a chance to chat with GoDaddy for support on my issue.
They created a cURL test file, and it appeared to be working fine. They said there were no issues on the Godaddy server & also checked the system logs and the server is functioning fine.
After that, I tried again to use the code below, which generated a 500 error, but the error logs still did not show any issue. When I brought this up to GoDaddy, they said I may need to change things to access the proper error logs. I’ve listed their instructions below as well - please let me know if you have any other advice on where to go from here. Thanks!
$url = 'https://catfact.ninja/fact'; $curl = curl_init();
curl_setopt($curl, CURLOPT_URL, $url);
curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);
curl_setopt($curl, CURLOPT_HEADER, false);
$data = curl_exec($curl);
curl_close($curl);
return $data;
Abid A at 8:04, Mar 21:
Let me check what’s best can be done on this.
You can review the error logs by going to Cpanel admin > File Manager > error_log file
You can also follow the below link article to set up PHP error log :
Setup PHP error logging | Linux Hosting (cPanel) - GoDaddy Help USYou at 8:07, Mar 21:
Thanks for the link and suggestion, but I do not see the “.user.ini” file in the location suggestedAbid A at 8:08, Mar 21:
you can just create a .user.ini file on File Manager :
What filename does my PHP initialization file need to use? | Linux Hosting (cPanel) - GoDaddy Help US
So what is the difference between the code in the “cURL test file” and the code in the snippet?
If you put this code in a PHP file on your server and call it, does that work?
<?php
ini_set("display_errors", 1);
ini_set("display_startup_errors", 1);
ini_set("log_errors", 1);
error_reporting(E_ALL);
$url = 'https://catfact.ninja/fact';
$curl = curl_init();
curl_setopt($curl, CURLOPT_URL, $url);
curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);
curl_setopt($curl, CURLOPT_HEADER, false);
$data = curl_exec($curl);
curl_close($curl);
echo $data;
?>
We started to have this issue on multiple sites and figured out it started after turning on mod_evasive in WHM