BobRay
Doesn't work in MODX3
Installing dashboard widget works, but on the actual dashboard instead of the widget is a block of text showing the error followed by a block of stack trace info.
Launching the dedicated resource in the tree that uses the snippet UpgradeMODXWidget also generates the same error.
This error gets generated:
Fatal error: Uncaught Error: Undefined class constant 'MAJOR_VERSION' in /home/rainbowt/modx3/core/vendor/guzzlehttp/guzzle/src/Utils.php:118
That's an interesting error as it's actually failing in the core. Perhaps UpgradeMODX ships with guzzle and something's getting mixed up?
Yes, guzzle is included. I wonder if changing the use lines in the upgrademodx.class.php class file and the three use lines in the download.files.php processor class to reference the MODX3 guzzle library would work:
use GuzzleHttp\Exception\RequestException;
@Mark-H Do older versions of MODX allow autoloading guzzle?
@rainbowtiger I haven't been able to duplicate this. I see the normal stuff and the program runs to completion. Setup works, but The Manager Menu is missing. Can MODX3-alpha1 be installed by copying the files and running setup? What about MODX3-alpha3? If not, there's no way to test UGM.
Well, that's what I did (copy files and run setup). I upgraded from a previous version. Maybe that's what messed up my site, because there are a bunch of things not working that really should be.
I just did a clean install of Alpha 3, and after installing UpgradModx, I get the same error message as before.
Did you install Alpha 3 by downloading and unzipping the files, then running setup?
Right after installing, the dashboard widget displays the error, and viewing the resource with the UGM snippet displays the error.
Try this: go to System Settings, type "feed" in the search box and disable the two feeds (security and news). Clear the cache and see if you still get the error. The feeds probably use Guzzle, and that may be causing the conflict (and could explain why I don't get it, since I have them turned off).
Tried that, and it didn't work. Tried turning off everything but UGM in the dashboard, and still getting the errors. Also, that wouldn't explain why the dedicated resource, which doesn't use the dashboard, doesn't work either.
Weird that I would get the error and not you if we are both using a clean install of the same version. I'm happy to give you access to my installation, if that would help.
Also very weird that the constant is undefined, rather than an attempt to redefine.
I think I can see why you're getting it and I'm not. We have different versions of Alpha 3. In the version I'm using, the Utils.php file is only 68 lines long and doesn't contain that constant. In the latest nightly, it's 388 lines long.
My guess is that MODX recently updated to Guzzle 7, while UGM is using Guzzle 6, although I can't find a commit where that happened. GitHub no longer has a facility to search commits by keyword.
The error you're seeing has been reported in other platforms (e.g., WordPress).
MODX 3 setup apparently requires PHP 7.2.5 so I won't be able to test until I upgrade PHP.
Yes, I have the latest alpha installed. As I said, if you want access to my installation, just let me know.
Hey guys. Just posting this as a comment here because I think those two might be related:
Failed opening required '/var/www/html/core/components/upgrademodx/vendor/autoload.php' (include_path='.:/usr/local/lib/php') in [..]
This happens when trying to load the dashboard widget. Hasn't happened before, just happened on a fresh install where we auto-installed UpgradeMODX. I disabled the widget for now on the instances, however I think it might help.
Hey guys. Just posting this as a comment here because I think those two might be related:
Failed opening required '/var/www/html/core/components/upgrademodx/vendor/autoload.php' (include_path='.:/usr/local/lib/php') in [..]This happens when trying to load the dashboard widget. Hasn't happened before, just happened on a fresh install where we auto-installed UpgradeMODX. I disabled the widget for now on the instances, however I think it might help.
Yeah, I just upgraded a bunch of sites through SiteDash to the newer version of UpgradeMODX, and now the dashboards are hosed. This error shows up in all Revo 2.8.1 installations.
azeller, is your core folder outside the root, or renamed? Looks like the new version of UpgradeMODX has some hard-coded path to the core folder.
Thanks for the heads up! I've updated the 2.1.4 package at modx.com/extras.
For those experiencing the problem, you can get into the Manager by putting this in your browser's address bar (corrected for the site URL and name of manager folder):
yoursite.com/manager/?a=resource/update&id=1
Once you're in the Manager:
- Go to Extras -> Installer.
- Uninstall and remove UpgradeMODX
- Re-download and re-install UpgradeMODX
Or just change line 180 of the upgrademodx.class.php file to:
$path = MODX_CORE_PATH . 'components/upgrademodx/';
Sorry about the trouble. For the curious, this got by me because my dev. environment has another vendor directory at that location.
The new version should also work in MODX 3.
@BobRay Just to clarify, did you replace the 2.1.4 package or issue a new release? Looks like 2.1.4 is from a few days ago from before these reports?
Edit: to clarify, a replaced 2.1.4 package wont be offered as an upgrade (neither in MODX nor in SiteDash) so people who have the broken release are kinda stuck with just a replaced package. Releasing a new 2.1.5 with the fix would be much appreciated in that case :)
@Mark-H Good point. I'll release it as 2.1.5 as well. I did download the current 2.1.4 package and confirmed that the change was there, but I hadn't thought about SiteDash.
Hey guys, @BobRay going to update resource 1 is exactly what I did to get around the dashboard :) That's how I got to the settings to get rid of the widget. Thanks for the hint though, good to have that documented for the others.
And yes, we always move the core directory outside of the web accessible root. That was the case for me as well @SnowCreative - Updating to 2.1.5 fixed it for me.
The new version should also work in MODX 3.
Yes, seems to be fine in MODX 3 now. Thanks!
Were you able to use UGM to upgrade to MODX 3? When I tried that, it worked, but I got some weird deprecation messages during setup.
I got those messages during setup, but how would I actually test using UGM to upgrade, since the latest official version is 2.8.1?
OK, did that and reverted my "version" system setting to alpha1 instead of alpha3. Upgrade went just fine, although there were these deprecated notices in the log:
[2021-03-23 21:50:56] (ERROR in xPDO\xPDO::getTableName @ .../modx3/core/vendor/xpdo/xpdo/src/xPDO/xPDO.php : 1282) modSession is deprecated since version 3.0. Replace references to class modSession with MODX\Revolution\modSession to take advantage of PSR-4 autoloading. [2021-03-23 21:52:07] (ERROR in xPDO\xPDO::call @ .../modx3/core/vendor/xpdo/xpdo/src/xPDO/xPDO.php : 773) modAccessContext is deprecated since version 3.0. Replace references to class modAccessContext with MODX\Revolution\modAccessContext to take advantage of PSR-4 autoloading. [2021-03-23 21:52:07] (ERROR in xPDO\xPDO::call @ .../modx3/core/vendor/xpdo/xpdo/src/xPDO/xPDO.php : 773) modAccessResourceGroup is deprecated since version 3.0. Replace references to class modAccessResourceGroup with MODX\Revolution\modAccessResourceGroup to take advantage of PSR-4 autoloading. [2021-03-23 21:52:07] (ERROR in xPDO\xPDO::call @ .../modx3/core/vendor/xpdo/xpdo/src/xPDO/xPDO.php : 773) modAccessCategory is deprecated since version 3.0. Replace references to class modAccessCategory with MODX\Revolution\modAccessCategory to take advantage of PSR-4 autoloading. [2021-03-23 21:52:07] (ERROR in xPDO\xPDO::call @ .../modx3/core/vendor/xpdo/xpdo/src/xPDO/xPDO.php : 773) sources.modAccessMediaSource is deprecated since version 3.0. Replace references to class sources.modAccessMediaSource with MODX\Revolution\Sources\modAccessMediaSource to take advantage of PSR-4 autoloading. [2021-03-23 21:52:07] (ERROR in xPDO\xPDO::call @ .../modx3/core/vendor/xpdo/xpdo/src/xPDO/xPDO.php : 773) modAccessNamespace is deprecated since version 3.0. Replace references to class modAccessNamespace with MODX\Revolution\modAccessNamespace to take advantage of PSR-4 autoloading. [2021-03-23 21:52:09] (ERROR in xPDO\xPDO::call @ .../modx3/core/vendor/xpdo/xpdo/src/xPDO/xPDO.php : 773) modAccessContext is deprecated since version 3.0. Replace references to class modAccessContext with MODX\Revolution\modAccessContext to take advantage of PSR-4 autoloading. [2021-03-23 21:52:09] (ERROR in xPDO\xPDO::call @ .../modx3/core/vendor/xpdo/xpdo/src/xPDO/xPDO.php : 773) modAccessResourceGroup is deprecated since version 3.0. Replace references to class modAccessResourceGroup with MODX\Revolution\modAccessResourceGroup to take advantage of PSR-4 autoloading. [2021-03-23 21:52:09] (ERROR in xPDO\xPDO::call @ .../modx3/core/vendor/xpdo/xpdo/src/xPDO/xPDO.php : 773) modAccessCategory is deprecated since version 3.0. Replace references to class modAccessCategory with MODX\Revolution\modAccessCategory to take advantage of PSR-4 autoloading. [2021-03-23 21:52:09] (ERROR in xPDO\xPDO::call @ .../modx3/core/vendor/xpdo/xpdo/src/xPDO/xPDO.php : 773) sources.modAccessMediaSource is deprecated since version 3.0. Replace references to class sources.modAccessMediaSource with MODX\Revolution\Sources\modAccessMediaSource to take advantage of PSR-4 autoloading. [2021-03-23 21:52:09] (ERROR in xPDO\xPDO::call @ .../modx3/core/vendor/xpdo/xpdo/src/xPDO/xPDO.php : 773) modAccessNamespace is deprecated since version 3.0. Replace references to class modAccessNamespace with MODX\Revolution\modAccessNamespace to take advantage of PSR-4 autoloading. [2021-03-23 21:52:10] (ERROR in xPDO\xPDO::getService @ .../modx3/core/vendor/xpdo/xpdo/src/xPDO/xPDO.php : 1253) MODX\Revolution\Rest\modRestClient::__construct is deprecated since version 2.3.0. Use the modRest classes instead. [2021-03-23 21:52:10] (ERROR in MODX\Revolution\Rest\modRestCurlClient::__construct @ .../modx3/core/src/Revolution/Rest/modRestCurlClient.php : 31) MODX\Revolution\Rest\modRestClient::__construct is deprecated since version 2.3.0. Use the modRest classes instead.
I think those may go away in Alpha 3, though alpha three is still a nightly and doesn't show up in the list yet.
Update: I just trashed a site with UGM going from 2.8.3 to 3.0.0-RC2. Still don't know why, but UGM hung near the end of the process. The site is in a subdirectory and UGM failed to find one of the processors.