Doing a manual backup is fairly simple. Just zip up all the files of your install in Cpanel’s File Manager. Then go into PhpMyAdmin and “export” the sites database.
After doing that, you should be able to run the UpgradeMODX extra, which will advise you on which version to upgrade to. I would recommend stopping with 2.8.4 for now.
You’ve tried manually clearing the site cache and visiting with your browser in incognito mode, right?
Thanks, bobray. Much appreciated. I haven’t looked into it, but any particular reasons not to upgrade to 3?
I also wanted to mention - I just stepped away from my manager dashboard and came back to an error reading “Call to a member function close() on string” - I hit OKAY, and refreshed, and everything appears normal, but I don’t believe I’ve ever seen this before. This looks to be an error resulting from the FILES portion of BackupMODX not working
Thanks again for the assistance - I greatly appreciate your help. I still refer to your Official Guide, it’s been extremely helpful in my business.
You want to have a really solid, working 2.8.4 site before going to MODX 3, which is a significant move. Also, there are still a number of extras that won’t work in MODX 3 and you need to figure out whether you need one of them.
I wouldn’t worry about the error, because hopefully, you’ll be getting all new MODX files soon and they’ll all be in the correct places.
I was successfully able to upgrade from 2.6.5 to 2.7 to 2.8.4, but to get back to the the manager after logging back in, I had to delete the first entry in the modx_dashboard_widget_placement table again.
I was having issues with package management not showing anything before, so I thought I’d try it again. After upgrading, still, no packages are showing, and going into Package Management to look for new extras just seems to hang on loading. But the strangest thing is that when hitting the refresh button at the bottom near the page navigator on the Installer page, this refresh button links outside of the manager to one of my site pages. If I refresh using the browser, it pushes all the content of the /manager/?a=workspaces page up on the screen (screenshot below), and if I hover over different areas of the screen, I’m getting links to different pages on the front end of my site.
I’m getting the same behavior in Incognito as well. It’s as if the front end is somehow ghosted over this shifted manager page, but when I look at the source for the manager page after loading and shifting, nothing from the front end appears that it should be there.
When you click the “Refresh” button under the grid in manager/?a=workspaces, it should make an AJAX-request with the action workspace/packages/getlist.
Can you open the developer tools in the browser, to see if that AJAX request works correctly (“Network” tab) or if there are any JS errors (“Console” tab).
The request to workspace/packages/getlist often takes quite some time to execute, as it queries the API for update information.
You could set the system setting auto_check_pkg_updates to No to speed things up.
Can you check the server error log, to see if a PHP error gets logged there?
What version of PHP are you currently using?
When I hit the refresh AJAX button as requested, it takes me to manager/contact.html, which is my page ID 3, so I don’t believe it’s actually processing correctly.
I am getting several errors in the Console tab, shown below, as well as two GET 404 errors for images that shouldn’t be loading when in the manager. The address for the image should be “/assets/images/” when viewing from the front end, but on this Console tab manager is being added before the full URL “manager/assets/images/”, and I have no idea why. These same errors are not occurring in the Console on the Manager homepage, nor are the front-end images being called.
POST - connectors/index.php 404 - from ext-base.js:21
Uncaught TypeError: this.mask.addClass is not a function - from modx.window.js:60
Removing auto_check_pkg_updates allowed my extras grid to load, and allows the AJAX refresh button to work! That being said, I’m still getting the same errors and extra images trying to load, based on “Console” in dev tools. Also, when I click “Check For Updates” on any of the extras, nothing appears to be happening, and then the grid is no longer available to scroll or click within, even though it is still showing, with the same errors showing again within Console.
The only PHP errors appear to be coming from the Wordpress install on the other site hosted on this server.
PHP version - 5.6. We are hosting multiple sites for several businesses from this server, and I’m not sure what version of Wordpress the other companies are using for their websites.
Did you also take a look at the “Network” tab in the developer tools?
A click on “Check for Updates” makes an AJAX-request with the action workspace/packages/update-remote. What is the response of that request?
You should update to a version that hasn’t reached its “end of life”, if possible.
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;