BobRay / UpgradeMODX

A dashboard widget that detects upgrades and (optionally) installs them from within the MODX Manager
https://bobsguides.com/upgrade-modx-package.html
22 stars 14 forks source link

Error requesting page #76

Open alexsoin opened 2 years ago

alexsoin commented 2 years ago

Error when downloading an update to any version:

Error requesting page /assets/components/upgrademodx/connector.php?action=downloadfiles&props%5Bugm_setup_url%5D=http%3A%2F%2Fname.ru%2Fsetup%2Findex.php&version=modx-2.7.2-pl.zip&_=1653483429638

DeepinScreenshot_выберите-область_20220525165815


MODX REVO: 2.7.1 UPGRADE MODX: 2.3.2-pl

BobRay commented 2 years ago

Do you have an .htaccess file in your assets folder? If so, see if renaming it solves the problem.

alexsoin commented 2 years ago

Do you have an .htaccess file in your assets folder? If so, see if renaming it solves the problem.

No, there is no such file in the assets folder.

BobRay commented 2 years ago

Sorry, I can't duplicate this problem.

Make sure the connector.php file from the error message exists.

Check the file and folder permissions on the assets/components/upgrademodx directory and its files.

Also check the .htaccess file in the MODX root directory to see if it has any directives that could affect the assets directory.

alexsoin commented 2 years ago

I repeated this error, installed modx 2.7.1 on the modhost, choosing a free test plan, chose php 7.1, installed the add-on, chose to upgrade to 2.7.2, the same error is shown again

изображение

BobRay commented 2 years ago

Did you check the file permissions?

Is there anything in the MODX error log? (core/cache/logs/error.log)

If you have access to the server error log, you might find something helpful at the time of the error.

alexsoin commented 2 years ago

in subfolders similar rights to files and folders:

$ ls -la
total 36
drwxr-xr-x  6 s29773 33 4096 May 30 21:24 .
drwxr-x---  8 s29773 33 4096 May 30 21:25 ..
drwxr-xr-x  3 s29773 33 4096 May 30 21:24 assets
-rw-r--r--  1 s29773 33  290 May 30 21:24 config.core.php
drwxr-xr-x  3 s29773 33 4096 May 30 21:24 connectors
drwxr-xr-x 13 s29773 33 4096 May 30 21:24 core
-rw-r--r--  1 s29773 33 3891 May 30 21:24 ht.access
-rw-r--r--  1 s29773 33 1893 May 30 21:24 index.php
drwxr-xr-x  6 s29773 33 4096 May 30 21:24 manager

errors in modx log:

[2022-05-30 21:31:42] (ERROR @ /home/s29773/www/core/components/upgrademodx/vendor/composer/platform_check.php : 24) User error: Composer detected issues in your platform: Your Composer dependencies require a PHP version ">= 7.2.5". You are running 7.1.33-44+ubuntu18.04.1+deb.sury.org+1.

errors in nginx log:

2022/05/30 21:31:25 [error] 11217#11217: *1768598 access forbidden by rule, client: 11.11.111.11, server: s29773.h10.modhost.pro, request: "GET /core/docs/changelog.txt HTTP/1.1", host: "s29773.h10.modhost.pro"
alexsoin commented 2 years ago

This problem is relevant both on modhost hosting and on jino hosting. If necessary, I can test on other hostings.

BobRay commented 2 years ago

I really appreciate all the testing.

No need to go to other servers yet. Two is plenty.

Have you tried updating PHP to at least version 7.4? Composer requires a higher version than you have and I suspect Guzzle, which downloads the files, does too.

The nginx error looks like it might be the nginx version of mod_security The other one is clearly about the PHP version, which could be your problem.

I'll try to find time to do more testing on this.

BobRay commented 2 years ago

I just installed MODX 2.7.1 locally (under PHP 7.4). I did see some warnings during setup about deprecated PHP features, and setup crashed, but not until after it updated the site. I was able to log in and the Manager worked fine.

I installed UGM and CacheClear, cleared the cache with CacheClear, and launched UGM. It updated the site to 2.8.0 with no problems at all.

My recommendation would be to update PHP to 7.4, then update the site to MODX 2.8.0 with UGM. If that fails, update to MODX 2.8.0 manually and go from there. When updating MODX you can skip over any versions before the next .0 version (UGM will recommend the version to upgrade to).

One more possibility I should mention is that if you have any plugins attached to download or upload file events, disable them and clear the MODX cache manually before upgrading. (I always clear the MODX cache with CacheClear before, and after every upgrade).

alexsoin commented 2 years ago

It seems to me that these moments need to be checked somehow before installing the package, or somewhere in the description of the package to write which PHP version is supported by the package. And since this package is often used to update very old versions of mods (which were inherited) and these servers may have the PHP of the old version, changing which the admin panel will not start for updating, I think before installing this package it will not be suitable or not superfluous. Or at least put on github versions of the package that can be used for older versions of php.

BobRay commented 2 years ago

I wish I could, but in order to do that, I'd have to install every version of PHP on my local machine, and create a way to switch between them, without reinstalling PHP each time (if that's even possible). Then I'd have to test each of my three-dozen-plus packages in every version of PHP with every version of MODX, and do that again every time I make a change to one of them.

If I did that, I wouldn't have time to work on the packages themselves. And that still wouldn't prevent issues like yours completely, since other factors can influence whether a package runs on a particular server. UGM will generally work on any version of MODX after 2.2.4, so your case is actually quite rare. No one who has kept both MODX and PHP more-or-less up to date has had an issue with UGM that I know of.

Anyone who does have a problem with UGM always has the option of updating MODX the old way by just copying the files and running setup.

rusamg commented 8 months ago

Hello everyone, I specially registered to help those who are faced with this problem. It took me several long weeks to understand the logic of the error, because my programming knowledge is weak (more precisely, it is outdated, due to the fact that I have not programmed for a long time). So, like everyone else, I encountered an update problem on one of my sites with a MODX update (Error requesting page /assets/components/upgrademodx/connector.php?etc). I didn’t want to force an update, I wanted everything to work through the widget. The problem started with the fact that for a long time I had the error “Please Install the Guzzle7 extra” in the widget. Naturally, I repeatedly reinstalled and changed versions of both UpgradeModx and Guzzle7, but nothing changed. I assumed that at some stage there was a file access error or a network communication error (this assumption turned out to be correct), so I began to disable all blocking. I completely turned off Cloudflare and it helped, the "Please Install the Guzzle7 extra" warning disappeared in the widget and update options with versions appeared. But after clicking on update, the above error appeared (Error requesting page /assets/components/upgrademodx/connector.php?etc). Encouraged, I turned off the WAF (web application firewall) protection on the hosting, but this did not help. I turned on the Chrome developer panel and saw this error in the "Errors" section. Next, I tried to do some diagnostics and found that the script is executed if called directly. I entered in Chrome (i changed my website address to ---, you must insert yours) http://---.com/assets/components/upgrademodx/connector.php and it returned me some options means that script working fine. This means there are no problems with file access rights. But when i call it with parameters in address line (http://---.com/assets/components/upgrademodx/connector.php?action=downloadfiles&props%5Bugm_setup_url%5D=http%3A%2F%2F---.com%2Fsetup%2Findex.php&version=modx-2.8.6-pl.zip&_=1710322012246), as the widget does, then error 403 appears. Thus, the problem occurs because the file with parameters is called, it cannot do what it is intended for and the server throws an error. Since I did not have access to the extended log files to understand what exactly the error was and I did not want to edit the file itself, since it was obviously working, I assumed that some resource was not downloading or there was no access to some file, after which I renamed the main /.htaccess file with numerous settings and turned on back the .htaccess file from the basic version with a minimum of parameters. After everything worked, problem disappears and i updated my modx with this wonderful plugin. So, the algorithm for solving this error including guzzle error globally is as follows

  1. Check all access rights to files and directories.
  2. Disable all services helping with caching protection like cloudflare.
  3. Disable all security protection on your hosting
  4. Return the most primitive htaccess file without any extra settings

I hope my experience will help you and save you weeks of life and agony in finding a solution to this problem.

After upgrading you may return all protection options and modified htaccess file.