Issues with REST API

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 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.

1 Like

same issue here this worked

Hm … tried some times, now loaded the package again and the name of the package is now (instead of before). And now it was installed correct.Spooky …

Thanks for the report, I’ve passed it on to the team working on the Provider and we’ll get it fixed up!

1 Like

Everything works but for the extras which are unavailable in my manager that shows below error:

TypeError: count(): Argument #1 ($value) must be of type Countable|array, string given


  • /www/webvol20/87/wukxzeiisxji9mr/
  • MODX\Revolution\Processors\Workspace\Packages\GetList->checkForUpdates(object, Array ( ) ) in /www/webvol20/87/wukxzeiisxji9mr/
  • modDashboardWidgetUpdates->render() in /www/webvol20/87/wukxzeiisxji9mr/
  • MODX\Revolution\modDashboardWidgetInterface->process() in /www/webvol20/87/wukxzeiisxji9mr/
  • MODX\Revolution\modDashboardWidget->getContent(object) in /www/webvol20/87/wukxzeiisxji9mr/
  • MODX\Revolution\modDashboard->render(object, object) in /www/webvol20/87/wukxzeiisxji9mr/
  • WelcomeManagerController->process(Array ( ) ) in /www/webvol20/87/wukxzeiisxji9mr/
  • MODX\Revolution\modManagerController->render() in /www/webvol20/87/wukxzeiisxji9mr/
  • MODX\Revolution\modManagerResponse->outputContent(Array ( ) ) in /www/webvol20/87/wukxzeiisxji9mr/
  • MODX\Revolution\modManagerRequest->prepareResponse() in /www/webvol20/87/wukxzeiisxji9mr/
  • MODX\Revolution\modManagerRequest->handleRequest() in /www/webvol20/87/wukxzeiisxji9mr/

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.

Also maybe take a look at these similar topics:

1 Like

halftrainedharry, your tip worked like a charm :slight_smile:

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.

Hi Jason,

Thanx for your answer.

So how do I Get this “update”?

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?


1 Like

@elizabeth There still seems to be a problem with the Gallery extra on MODX 3.

1 Like

@elizabeth The same problem (as with the Gallery extra) occurs for the MODX Dark Theme extra on MODX 3 (Version = 0.0.0: Released = 1970-01-01):


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.

@elizabeth The package getDate in MODX 2.x also can’t be downloaded and shows a Version of 0.0.0 and a release date of 1970-01-01.

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.

I believe this is wrong. We’ve been using this extras for years now (on current MODX versions of the 2.x branch) and never had problems.

Also, the Gallery extras should work with MODX 3. The necessary changes were made.

Any idea what happened to the SitemapFriend extra?

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.

1 Like

There is no extra called SitemapFriend in the repository that I can see.

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.