Try renaming the folder core/packages/tinymcerte-2.0.9-pl to core/packages/tinymcerichtexteditor-2.0.9-pl.
There seems to be some confusion with the package name.
The transport package has the name tinymcerichtexteditor-2.0.9-pl.transport.zip but the folder inside it has the name tinymcerte-2.0.9-pl. I believe this should be the same: Either both tinymcerichtexteditor or both tinymcerte.
Hm … tried some times, now loaded the package again and the name of the package is now tinymcerichtexteditor-2.0.9-pl.transport.zip (instead of tinymcerte-2.0.9-pl.transport.zip before). And now it was installed correct.Spooky …
MODX\Revolution\Processors\Workspace\Packages\GetList->checkForUpdates(object, Array ( ) ) in /www/webvol20/87/wukxzeiisxji9mr/recompany.se/public_html/manager/controllers/default/dashboard/widget.updates.php:78
modDashboardWidgetUpdates->render() in /www/webvol20/87/wukxzeiisxji9mr/recompany.se/public_html/core/src/Revolution/modDashboardWidgetInterface.php:81
MODX\Revolution\modDashboardWidgetInterface->process() in /www/webvol20/87/wukxzeiisxji9mr/recompany.se/public_html/core/src/Revolution/modDashboardWidget.php:134
MODX\Revolution\modDashboardWidget->getContent(object) in /www/webvol20/87/wukxzeiisxji9mr/recompany.se/public_html/core/src/Revolution/modDashboard.php:122
MODX\Revolution\modDashboard->render(object, object) in /www/webvol20/87/wukxzeiisxji9mr/recompany.se/public_html/manager/controllers/default/welcome.class.php:109
WelcomeManagerController->process(Array ( ) ) in /www/webvol20/87/wukxzeiisxji9mr/recompany.se/public_html/core/src/Revolution/modManagerController.php:178
MODX\Revolution\modManagerController->render() in /www/webvol20/87/wukxzeiisxji9mr/recompany.se/public_html/core/src/Revolution/modManagerResponse.php:114
MODX\Revolution\modManagerResponse->outputContent(Array ( ) ) in /www/webvol20/87/wukxzeiisxji9mr/recompany.se/public_html/core/src/Revolution/modManagerRequest.php:173
MODX\Revolution\modManagerRequest->prepareResponse() in /www/webvol20/87/wukxzeiisxji9mr/recompany.se/public_html/core/src/Revolution/modManagerRequest.php:143
MODX\Revolution\modManagerRequest->handleRequest() in /www/webvol20/87/wukxzeiisxji9mr/recompany.se/public_html/manager/index.php:60
I have seen other cases where people had this problem.
On some installations there seems to be a problem with reading data from the package provider API using cURL.
As a temporary workaround you could set the system setting auto_check_pkg_updates to No. This doesn’t fix the issue, but you should see the list of the installed extras again.
This should be resolved now. The recent updates to the provider introduced a new format of error message and it was missing an expected element in the package manager code inside of MODX.
The update was to the package provider service. You do not need to do anything. However, it seems that something is still wrong with certain packages and I am trying to determine what it is specifically.
Hey everyone on this thread. We have pushed an update that should fix the vast majority of issues. Can everyone undo their hotfixes (auto_check_pkg_updates back to Yes) to see if we have any remaining issues? If so, can you PM @opengeek your server’s IP address so we can dig further into your issue?
I’ll look into this to help take some off your guys’ & gals’ plate. HUGE steps forward were made in the MODX 3.x.x releases. Understandable that some things may have been overlooked. Will report back soon with my findings.
Also, maybe the default sort could be adjusted. Currently a search for “ace” shows the desired package (that exactly matches the search term) only in 8th place:
getDate is marked as breaking at 2.8, so it is not supported in the version of MODX you are in. I’m looking into the problem of search returning the 0.0.0 version data when it does not match supported versions. I’ll also look into the sorting.
It’s technically correct, but there was apparently a big misunderstanding in presenting the “breaks_at” field to extras authors. If it “breaks at” 2.8, that would exclude 2.8 from being supported. However, the form for submitting extras presented the breaks_at field using the words “supports up to” which would be inclusive. We will need to adjust some extras to solve this misunderstanding.
That said, I can see it in the old MongoDB data. It seems some invalid data prevented it from being migrated. I’ll try and diagnose it and see if I can resolve it.