I don’t know what exactly the problem is, but there seem to be many problems with permissions. You don’t have permissions to create/delete files/directories.
Maybe make sure all file permissions are correct, before you start the upgrade process.
Seems that the most problems depends on the permissions. Have to contact the support and hope that they can help.
Typically, permissions for all folders should be set to 0755 and all files to 0644.
Also, if in your earlier attempts, you changed paths and URLs in config.inc.php or the three config.core.php files, and any of them are incorrect, that will keep UpgradeMODX (and any other method) from working.
1 Like
Ok, now I have some questions. I have installations on different providers (Hosteurope, netcup, dogado, Strato, IONOS), older 2.8.x and new 3.0.x
A new 3.0.3 installation works at Hosteurope with standard permissions 750 and 640. Seems that this is ok instead of 755/644? Or do I have to change the permissions?
For assets, core/cache, packages and some other directoriess I have to change the permission to 777, otherwise I get an error during installation. Of course the config.inc.php gets a 777 during installation, after that I return to 644.
Even though the core/config.inc.php is ok, all config.core.php at Hosteurope installations are:
define('MODX_CORE_PATH', dirname(__FILE__) . '/core/');
define('MODX_CONFIG_KEY', 'config');
These configs at other providers show a long path. Why at Hosteurope this configs are unchanged after installation?
Hosteurope has a restricted server management for shared hosting. In the file management section I can change permissions system wide and I can set user and group permissions for directories and files. Standard is ftp permission for the user and server permission for group.
Is this ok or should I change any permissions?
Do your files have different file owners? For example, when you upload a file with FTP is the file owner different than when you create a new file in PHP?
The same user should probably own all files do avoid such additional complications during installation.
1 Like
For files uploaded or folders created via FTP the owner is the FTP user. Files uploaded in MODX or also folders created within MODX have the group owner.
Now I had another try on my horrible site at Hosteurope. I cloned the old file system (all activities via SSH), cloned the database. Changed all folders to 755 and all files to 644 and set all user permissions to the group user. MODX version is 2.8.3.
Changed assets, core/cache, core/import, core/export and core/packages to 777.
Checked and edited the config.inc.php to the right entries for database and paths.
Changed the 3 config.core.php to the correct core path.
Cleared the core/cache manually.
Calling the site itself returns a 503 error. Manager URL let me log in. Left side is empty (resources, elements, data). Right side shows empty dashboard widgets. Access to system settings returns a blank area.
It’s a mess …
EDIT: moved the setup directory for 2.8.3 to the server, run the setup. Now I have the old seite and the manager works as expected. Means: the clon is ok and identical to the live site.
Now I need the correct way for an upgrade to 3.0.1 or 3.0.3.
A note: with the group user for all folders and files deleting the setup folder works after installation. Seems that I have to set all files/folders to the group user for proper functioning.
I tried now the extra UpgradeMODX and the upgrade to 2.8.5 was a success. All ok.
Next step: upgrade to 3.0.0-pl via UpgradeMODX. I checked all permissions and paths in configs, cleared the core/cache manually. Removed all dashboard widgets except the UpgradeMODX. Deactivated all plugins.
Upgrade runs without problems. Cleared the cache manually, than logged in to the manager.
This is the result:
An error occurred…
TypeError: count(): Argument #1 ($value) must be of type Countable|array, string given
Errors:
- count(string “provider_err_connect”)
- MODX\Revolution\Processors\Workspace\Packages\GetList->checkForUpdates(object, Array ( ) )
- modDashboardWidgetUpdates->render()
- MODX\Revolution\modDashboardWidgetInterface->process()
- MODX\Revolution\modDashboardWidget->getContent(object)
- MODX\Revolution\modDashboard->render(object, object)
- WelcomeManagerController->process(Array ( ) )
- MODX\Revolution\modManagerController->render()
- MODX\Revolution\modManagerResponse->outputContent(Array ( ) )
- MODX\Revolution\modManagerRequest->prepareResponse()
- MODX\Revolution\modManagerRequest->handleRequest()
Resource tree is empty.
One entry in the error protocol of MODX:
[2023-03-31 13:20:44] (ERROR in MODX\Revolution\Transport\modTransportProvider::latest @ /is/htdocs/.../core/src/Revolution/Transport/modTransportProvider.php : 264) Could not load updates for getdate-1.0.0-pl: No Package release found.
Not relevant for this, I think?
Server error log contains only this:
[Fri Mar 31 13:28:04 2023] [authz_core:error] [pid 9267] [client ...] [host www....] AH01630: client denied by server configuration: /is/htdocs/.../core/docs/changelog.txt
Clicking “Extras → Package Management” => endless loading animation with “Checking for package updates…”, nothing happens, the list is empty.
What now??
This error seems to stem from the “Update” dashboard widget. Maybe (temporarily) delete this widget from the dashboard (manager/?a=system/dashboards).
You can ignore this.
Try setting the system setting auto_check_pkg_updates to “No”.
There seems to be a problem with getting the update information from the package provider. The changed system setting value won’t fix it, but you should at least see the list.
I’ve seen similar problems before, but I still don’t know why some people have problems requesting package information with cURL from the package provider.
1 Like
Deleted all widgets, then the error message disappeared. Could set the UpgradeMODX widget: dashboard is ok now.
Resource tree is empty furthermore.
Cleared the cache another time manually: resource tree is empty.
Helps! Now I can see the extras list.
Activated all plugins. Can see and edit all Elements (Chunks, Snippets and so on).
Resource tree remains empty and previewing the site gives back only this:
Array ( [id] => 1 [type] => document [pagetitle] => … Some images between the code, that’s all.
Cleared the cache, set config.inc.php writable, started upgrade to 3.0.1 via the extra UpgradeMODX.
Now I’m on 3.0.1, no error messages, but the resource tree is still empty, the site preview is chaos.
Upgraded to 3.0.3 the same way, same result.
Tried to find a resource via the search function, opened it. An endless error message:
Error: Failed opening required ‘/is/htdocs/…/core/model/modx/modprocessor.class.php’ (include_path=‘.:/usr/share/php8.1’)
Errors:
- /is/htdocs/…/core/components/collections/model/collections/collectioncontainer.class.php:2
- include_once(string “/is/htdocs/…/core/components/collections/model/collections/mysql/collectioncontainer.class.php”) in /is/htdocs/…/core/vendor/xpdo/xpdo/src/xPDO/xPDO.php:678
- xPDO\xPDO->_loadClass(string “CollectionContainer”, string “collections.mysql.collectioncontainer”, boolean “”, string “/is/htdocs/…/core/components/collections/model/”, boolean “”) in /is/htdocs/…/core/vendor/xpdo/xpdo/src/xPDO/xPDO.php:656
- xPDO\xPDO->loadClass(string “mysql.collectioncontainer”, string “”, boolean “”, boolean “”) in /is/htdocs/…/core/src/Revolution/modX.php:2553
- MODX\Revolution\modX->loadClass(string “CollectionContainer”) in /is/htdocs/…/core/vendor/xpdo/xpdo/src/xPDO/xPDO.php:807
and so on …
???
Note: the php version is not the problem. Changed to 8.0: same result.
EDIT: checked the path “/core/model/modx/modprocessor.class.php” from the error message.
This file is missing, in the folder is only a modx.class.php
Checked the installation files from regular download. This file is also missing there (3.0.1 and 3.0.3).
The missing file is only in the 2.8.x versions (with many more files and sub folders).
Hah! Found this post: Installing Modx 3.0 alpha-2 - #5 by markh
There @markh wrote about updating Collections extra to 4.0.0 … and that was it! Upgraded and now I can see the resources.
Instead, there is a new (little) problem, which I will probably have to fix by hand. All date template variables (for a news overview) are on “01.01.1970” in editing mode. The output on the frontend ist ok.
After changing the domain a new error occured. The frontend is missing some elements.
Big problem with template variables. They are there in the system, assigned to the templates, but missing in edit mode of the resource.
The error log of MODX shows this:
[2023-03-31 15:40:47] (ERROR @ /is/htdocs/…/core/vendor/xpdo/xpdo/src/xPDO/xPDO.php : 666) Could not load class: modFileHandler from modfilehandler
[2023-03-31 15:40:47] (ERROR @ /is/htdocs/…/core/vendor/xpdo/xpdo/src/xPDO/xPDO.php : 1272) Problem getting service fileHandler, instance of class modFileHandler, from path
Server log is empty …
Any ideas?
Seems that there is a problem with MIGX? I can deinstall and reinstall it, nothing changes.
This is a screenshot of a fresh 3.0.3 installation:
and this is the MIGX window in my problematic installation:
What’s wrong with this system?
These are not correct, and could be a large part of your problem. I’d advise hard-coding the path to the core directory for now in all three config.core.php files, like this:
define('MODX_CORE_PATH', 'C:/xampp/htdocs/test3/core/');
Leave the CONFIG_KEY line alone. As usual, clear the site cache manually after the change.
BTW, you have run Setup, right? That usually (not always) straightens out the config files.
Leave the
This is probably the issue that is fixed with this pull request.
1 Like
All done right during the last trials, I adjusted all the paths beforehand and always cleared the cache manually. At least I could upgrade to 3.0.3 without any error messages. But now MIGX is corrupt. During all upgrade trials I only deactivated all plugins. I will take today a new turn, but deinstalling all extras before update/upgrade process.
I am ready with the process. Upgrade done step by step from 2.8.3 to 3.0.3 at the end. Deinstalled all extras during upgrades. All done via UpgradeMODX.
Last steps were an update of Collections and pdoTools.
Now the site works as expected. Frontend and backend are ok.
1 Like
I’m glad you got it sorted. 
Thanks for reporting back.
I’m glad too. And I know, that this Provider (hosteurope.de) is very difficult for MODX sites on shared hosting packages. It’s the only one (that I know) having such a strange permissions concept.
Have learned so much last days, thanks to @halftrainedharry , @smashingred and @bobray !
1 Like
This topic was automatically closed 2 days after discussion ended and a solution was marked. New replies are no longer allowed. You can open a new topic by clicking the link icon below the original post or solution and selecting “+ New Topic”.