Answered Revo Upgrade from 2.2.16 to any newer version - checkPolicy is a non Object - error

Hi All,

Upgrading a few older sites. From 2.2.16. PHP 5.4.45. Linux/Apache. Hosted by Webfaction. MySQL 5.5.45-37.4

Tried to jump to 2.4.2 but got this error after the Install button is clicked. Note, all the tests passed.
Fatal error: Call to a member function checkPolicy() on a non-object in /...blah/core/model/modx/modx.class.php on line 1880.

The fatal lines in question.

Could this mean the User Object (this) doesn't exist?

So tried an earlier version 2.3.6. Same result. Tried 2.3.0. Same, so not a "too big a jump" thing. Repeated on another website on the same server/setup also at 2.2.16. Same result. In both cases re-installing 2.2.16 works. Suggesting it isn't a "folder not writeable" kind of thing. Note when upgrading using 2.3.0 the checkpolicy call is on line 1876.

Perhaps a database issue, Users not found? But I'm thinking the hosting company setup. Webfaction are awesome (like a VPS for $9.99/month) but they are more Python experts. Perhaps PHP or MySQL has been updated since the installation a year ago.

I had deleted the cache(from the manager). Upgraded all packages (list below) and Flushed Sessions. Then manually deleted the core/cache. And deleted the Firefox Cache on some runs.

Fairly standard Packages. Breadcrumb, FormIt, GetResources, SimpleSearch, SiteAtoZ, TincyMCE, Wayfinder. A few more on the other site.

This is probably a side effect but my notes from last night state...
After deleting core/cache and browser cache - hit back from the error page and got
Warning: array_merge(): Argument #2 is not an array in /...blah/core/xpdo/xpdo.class.php on line 341
Fatal error: Class 'xPDODriver_' not found in /...blah/core/xpdo/xpdo.class.php on line 1880
Probably a side effect of a half installation.

Had a good rummage around for help. But stumped. At least the sites/manager still work at 2.2.16.

Stuart [ed. note: parthian last edited this post 8 years, 6 months ago.]

Could you report that here?

Quote from: BobRay at Nov 13, 2015, 06:17 PM

Could you report that here?

Done.

Curious, why the need for GIT? Is that the way for all potential bugs (not sure it is a bug with MODx) or because you're sure it is a bug? Is the forum closed to this kind of thing? Should this be closed?

No, it's fine here, but the core developers are much more likely to see it (and fix it if it's a bug) at GitHub, which is where all bug reports go now.

That message, BTW is saying that the context object doesn't exist during a hasPermission() call in setup. Do you have multiple front-end contexts? You might try temporarily renaming the .htaccess file before running setup.

Each project only used the 'web' FEContext. But I may have toyed with the idea a few years ago when first setting up the sites. Tiny chance that I tried it, it failed, I abandoned the approach and somehow a table or setting is stuck in an odd state. But I'd file that under 'last thing to try'.

.htaccess only has FURL stuff. Renamed it anyway as FURLs can cause havoc from time to time. No change.

I've added the very long Success/Warning messages from the successful re-installation of 2.2.16 to GIT (save cluttering this up). Quite a few Error messages but sites appear to be fine. Lots of "Error updating table for class transport.modTransportProvider" and the like.

Signing off for the night (UK). Have a fine weekend. Thanks.

Quote from: parthian at Nov 24, 2015, 02:03 PM

Many thanks to Bertoost on the github page.

Same problems here. After some trying and debugging; the "modx_context" table is missing the "name" field..
So to fix it; try adding "name" in table "modx_context" as a VARCHAR 255 and try running the setup again.
Is this one not covered in some versions between this two @modxcms ?

All went well after that.

Thank you! I had the same error and that worked for me too.

You might want to check the other fields listed here: https://bobsguides.com/blog.html/2016/06/27/missing-db-fields-(unknown-column)/ to make sure you have them.