I still can’t get Package Manager to work. It shows the packages I have, knows about updated versions, and appears to download new versions. They are in the core/packages directory, but Package Manager can’t find them. It looks like it’s looking in the wrong place for them.
Actually, this is an old site that has been running in a folder for many years. I simply upgraded it in place.
If removing collections is problematic, I can wait until the installer page is working, then use the remove function there.
Did you see the errors I posted about not finding getlist?
Unable to load processor for action “workspace/packages/getlist”, it does not exist as an autoloadable class that extends \MODX\Revolution\Processors\Processor, and also not as a file in “/home1/terrybar/public_html/base-install/core/src/Revolution/Processors/workspace/packages/getlist.class.php”
Check the path in the modx_workspaces table. It should be the core path, e.g.:
/home/username/public_html/directory/core/
I don’t think it was used in MODX 2, but it definitely affects Package Manager in MODX 3.
Bob
The workspace table in the DB contains this: {core_path}
This is in the core/config/config.inc.php
if (!defined(‘MODX_CORE_PATH’)) {
$modx_core_path= ‘/home1/terrybar/public_html/base-install/core/’;
define(‘MODX_CORE_PATH’, $modx_core_path);
base-install is the folder where this is installed.
You might try replacing the value in the workspaces table with /home1/terrybar/public_html/base-install/core/ in case MODX 3 is not parsing the tag. That DB value will definitely cause trouble in Package Manager if it’s wrong. There’s probably a reason why mine has the value hard-coded.
Bob
I hard coded the path in the DB. The installer still is not working, seem hung up on blogit (at least that’s what’s in the error log)
17.02.2022 10:07:58 ERROR MODX\Revolution\Transport\modTransportProvider::latest /home1/terrybar/public_html/base-install/core/src/Revolution/Transport/modTransportProvider.php 264
Could not load updates for blogit-1.2.0-pl: No Package release found.
17.02.2022 10:08:34 ERROR /home1/terrybar/public_html/base-install/core/src/Revolution/modX.php 1784
Unable to load processor for action “workspace/packages/getlist”, it does not exist as an autoloadable class that extends \MODX\Revolution\Processors\Processor, and also not as a file in “/home1/terrybar/public_html/base-install/core/src/Revolution/Processors/workspace/packages/getlist.class.php”
I’m not sure if this matters but I don’t see this file on the server:
/home1/terrybar/public_html/base-install/core/src/Revolution/Processors/workspace/packages/getlist.class.php
I just changed the php version on my server from 8.0 to 7.4 and the installer came back.
I just cleared the modx cache, cleared the browser cache and tried to update Blogit and Databackup but got this error, which I saw earlier.
An error occurred while connecting to the Provider: No Package release found.
I was able to successfully update tinymce, but didn’t try collections.
I’m thinking I could use the installer to “remove” it?
So right now there are three extras that say there is no provider.
Blogit
Databackup
xFPC
Are those three packages available at modx.com/extras?
Is it possible that you loaded them locally and did “search locally for packages” ? that would explain the missing provider.
This is wrong:
/home1/terrybar/public_html/base-install/core/src/Revolution/Processors/workspace/packages/getlist.class.php
The name of the class in MODX 3 is GetList.php not getlist.class.php, so something is trying to load a MODX 2 processor class. MODX 3 corrects the path, but not the filename.
They were not installed locally, all from the provider. However, when I search for them, no results are found. Does the installer check if an extra is compatible with Modx3? If yes, than it makes sense it can’t find them.
Not sure what to do with this?
The name of the class in MODX 3 is GetList.php not getlist.class.php, so something is trying to load a MODX 2 processor class. MODX 3 corrects the path, but not the filename.
Finding a reference to getlist.class.php might help identify the offending extra.
You could search the MODX site files or the code of your extras for the term getlist.class.php
If you download the files, you could use your os’s file search facility. Or put them in a project and search them with a good code editor like PhpStorm. You might find it in just the cache files, or in just the core/components directory.
A query of the site’s DB would let you find any references in your element’s PHP code (so would CustomSearch if you have that), though not in any class files they load.
PS: Your suspicions are correct. BlogIt only works in MODX version 2.4. xFPCA only works in MODX 2.2. As far as I can tell, Databackup is not in the extras repo at all.
I’ve downloaded the files and found the file name referenced in this file:
“C:\Users\terry\OneDrive\Desktop\base-install-3.0\core\components\updater.idea\workspace.xml”
Here’s a zipped copy of that file. It looks like it might be related to the Updater extra?
Isn’t updater or some equivalent built into the MODX 3 core as a widget?
In any event, I’d suggest trying to remove the Updater extra. If that’s not possible, disable any Updater plugins and snippets.
Bob
This is just so much fun!
OK, I did find the core update widget and applied it to the dashboard. Then I attempted to uninstall Updater and Upgrade Modx. Both of them appeared to uninstall successfully, however, if I tried to remove them, they remain in the installer grid–it can’t find the files to remove. They also remained in the dashboard.
However, the big change is that the dashboard has a 500 error. I can go back to any other manager page, but not the dashboard.
So I then went back to the dashboard manager and saw they were still on the dashboard. I would’ve thought the uninstall would have removed them. So I removed the Updater and Upgrade widgets from the dashboard and the dashboard came back. I tried reinstalling the extras in the installer but they remained uninstalled in the grid with updates available. So I updated them both and they now appear in the dashboard.
I’m guessing there was some problem with the older versions of those extras that were installed on my pre-Modx 3 site that has since been fixed.
So now it appears all is well except for the error message about not finding Migx. That’s fine. I assume that will be available soon enough, and I do want that installed on this site. So I’ll wait.
Thanks for all your help on this. Hopefully, no related surprises show up in the next few days.
Terry, believe me, I’ve been there (in fact I’m there now on another extra of mine). 
AFAIK, those dashboard widgets are built into MODX 3. I’m pretty sure they appear in a clean install of MODX 3 and in an upgrade. The extras are something else. That’s why you still see the widgets after removing the extras. It’s possible that widgets and the extras use some of the same classes (in which case, a class with the same name could crash things by redeclaring a class that’s already been instantiated, or by serving up the wrong class at some point.
If the widgets are snippet-based, they could also use the same snippet or chunk names as the extras, which could easily blow up the dashboard or possibly Package Manager.
Interesting.
It would seem to be something to check for during the pre-installation check up. How would anyone know an existing, supported extra would conflict with the Modx core?
Since Updater and UpgradeModx extras are still showing up in the installer grid, will updates appear separately from the core updates? Should they be installed?
Sorry, I don’t know.
Thanks for all your troubleshooting on this guys - I’ve referred back to this thread on a few occasions now as I’ve had the erroring Dashboard problem and the non-functional Package Manager problem on several occasion after upgrades to MODX 3.x.
The Updates dashboard widget definitely seems to cause problems on some sites but not others. Removing it from the Dashboard seems to fix it.
In my latest site with the Package Manager problem, deleting the extra, findParent from the modx_transport_packages table fixed the problem. It’s a very old extra [from a very old site!] so perhaps not surprising that it was the culprit - but it does just seem that some extras mess up the 3.x Package Manager.
Thanks again 
Thanks for the report. 
Batcher is another extra which, as it stands, kills the Package Manager [for me at least] after upgrade to MODX 3.x and should be removed before the upgrade.
If it’s too late, removing Batcher from the modx_transport_packages should get you your Package Manager back. Further cleanup in the components folders is probably advisable.
Interestingly, removing it also fixed the Dashboard problem [even without removing the Updates widget] so I think the two issues look to be linked.
I hope Batcher is updated soon as it’s a great tool.