How must the authorization be set for components? 705?
And I install the extras via Extras → Package manager
How must the authorization be set for components? 705?
And I install the extras via Extras → Package manager
This is certainly an unusual file permission. But if your user is the owner of the directory, then this should still work.
Can you install other extras without these errors?
Are there already files in core/components/collections/
?
Maybe try removing the Collections extra completely from core/packages/
and then downloading and installing it again.
When downloading and installing the plugin e.g. Wayfinder the following error message appears…: Could not download and create transport package with signature "wayfinder-2.3.3-pl".
And yes, there are files available in the /collections folder
Heya! Try and install it again, there was a minor infrastructure blip that might have caused an issue for you temporarily.
okay, now the download and installation works, but unfortunately still not with the Extra Collections
Hello everyone. I decided to refresh the topic - a while ago I had exactly the same manager message: HTTP ERROR 500. After logging into the database, I saw that the system had re-created the tables without chonoring the fact that at installation I had requested a different prefix than the predefined one generated automatically. The tables with my prefix were unaffected, but new (empty) tables with the prefix modx??? were created.
I tried copying the data from my tables to the newly created tables by the system - unfortunately, the likely relationships and keys were not transferred correctly. I therefore made a complete copy of the database. I deleted the entire installation. In the database copy via a text file, I changed my table prefixes to the ones newly generated during the new installation. I imported such a crafted copy of the database deleting the ones that were on the database beforehand. IT WORKED !!!
It’s probably better to leave the original table prefixes imposed during installation, since there is probably a mechanism for reactivating database objects, unfortunately without the memory of new prefixes
HTTP ERROR 500 is just a generic response for an “Internal Server Error”. There are a million different reasons why this error message might appear. Your problem seems to be completely unrelated to the original topic.
So when were these tables “recreated”? On an upgrade of MODX? How did you execute the upgrade? From what version of MODX did you upgrade to which new version?