On March 26, 2019 we launched new MODX Forums. Please join us at the new MODX Community Forums.
Subscribe: RSS
  • Hi,

    I just upgraded a neglected site from modx 2.1.6 to 2.7.0. I was getting some php errors before the upgrade that left the front end up, but the manager broken. I found out my shared host upgraded their php, which may have triggered the issues. I backed up my site and did the upgrade. It went smoothly, and everything works fine now, except I get the error: "Warning: constant(): Couldn't find constant 32759 in /home1/mysite/modx/core/model/modx/modx.class.php on line 690" at the top of all of my public pages.

    I suspect this is because there have been so many revisions since 2.1.6 and my database probably didn't quite match up.
    My only addons are wayfinder and spform. Both are up to date.

    cPanel 70.0 (build 66)
    Apache 2.2.34
    PHP 7.0.33
    MySQL 5.6.41-84.1
    Perl 5.26.0

    What can I do to fix this?

    Thanks,
    -Dan
    • You shouldn't have skipped over the major versions (2.2.0, 2.3.0, 2.4.0, 2.5.0, 2.6.0, 2.7.0). That's where the DB changes are made. If you have a backup, I'd suggest starting over and doing the intermediate upgrades.

      I think you're immediate problem might be solved by changing the value of the debug System Setting to 0.

      I suspect that there will be other problems, though, due to missing database fields added since your old version. [ed. note: BobRay last edited this post 6 months ago.]
        Did I help you? Buy me a beer
        Get my Book: MODX:The Official Guide
        MODX info for everyone: http://bobsguides.com/modx.html
        My MODX Extras
        Bob's Guides is now hosted at A2 MODX Hosting
      • I had a feeling you might say that. Changing debug to 0 didn't take away the warning though.

        Thanks Bob
        • What's the code block on/around the line the warning refers to? I'm not seeing what would be triggering such a message in the MODX source code.
            Mark Hamstra • Developer spending his days working on Premium Extras and a MODX Site Dashboard with the ability to remotely upgrade MODX and extras to make the MODX world a little better.

            Tweet me @mark_hamstra, check my infrequent blog at markhamstra.com, my slightly more frequent ramblings at MODX.today or see code at Github.
          • @Mark Hamstra - the first line here is line 690 in my local 2.7.0-pl install (it's in the setDebug method):

            $debug = (is_int($debug) ? $debug : defined($debug) ? intval(constant($debug)) : 0);
            if ($debug) {
               error_reporting($debug);
               parent :: setLogLevel(xPDO::LOG_LEVEL_INFO);
            }


            This happens in the modX class constructor:

            $debug = $this->getOption('debug');
            if (!is_null($debug) && $debug !== '') {
               $this->setDebug($debug);
            }


            As I read it (the double ternary operators make it difficult to read), $debug is coming through as a string. Because it's a string, it fails the is_int(), test so defined($debug) executes. If the number in the debug System Setting is not a defined constant, the error gets thrown. It shouldn't, imo, because error_reporting() accepts a bitmask, so any integer, defined or not, should be allowed, and the description of the debug setting says any valid integer will work.

            Maybe the is_int() should be is_numeric(), which would pass a numeric string.

            Or maybe it should be this in the constructor:

            $this->setDebug(intval($debug));


            Another issue is that in the xPDO getOption() method, if the key is not a string or an array, the default value is returned. But the getOption() call in the modX constructor's debug section has no default.

              Did I help you? Buy me a beer
              Get my Book: MODX:The Official Guide
              MODX info for everyone: http://bobsguides.com/modx.html
              My MODX Extras
              Bob's Guides is now hosted at A2 MODX Hosting
            • Bob,

              It's not going to be practical for me to roll the site back to 2.1 again and install all those between versions just for the sake of this minor error message. Everything else about the site seems fine. But, the error message is bothering some users, so I'd like to try a band-aid fix.

              As I mentioned before, setting debug to 0 in the manager had no effect.

              Is it feasible for me to tweak the class constructor somehow, like by changing the code to "is_numeric()", or to set a default in the constructor's debug section as you suggested?

              I'm not really a programmer. I have some basic training in c++, so I understand the concepts you're talking about here, but honestly, solving it myself is above my pay grade. I'm just going to end up copy/pasting whatever you tell me to see if it works or not.

              Thanks,
              -Dan
              • I think changing is_int to is_numeric in line 690 of the /home1/mysite/modx/core/model/modx/modx.class.php file will eliminate the error message, but be prepared to change it back if things don't work out.

                I can understand why you don't want to revert the site, but at least check the DB for the fields listed here and add them if they're missing: https://bobsguides.com/blog.html/2016/06/27/missing-db-fields-(unknown-column)/.

                  Did I help you? Buy me a beer
                  Get my Book: MODX:The Official Guide
                  MODX info for everyone: http://bobsguides.com/modx.html
                  My MODX Extras
                  Bob's Guides is now hosted at A2 MODX Hosting
                • An interesting thing happened just now, Bob.

                  I had not attempted any of the changes we discussed above just yet, however, I found out my spform wasn't working.

                  While checking into it, I discovered my property set for spform had been lost. I uninstalled spform, downloaded a new copy, reinstalled it, and reset all my properties. spForm started working properly again, and I immediately noticed my php error from before also disappeared. My whole site seems fine now.

                  I figured I would post this just to say that I apparently did upgrade from 2.1 straight to 2.7 without any major hiccups, and that the database does seem to be working fine, except that my spform was busted. However, I suspect that may have actually happened prior to the actual modx upgrade, because I made sure to upgrade spform and wayfinder before I upgraded the rest of modx, but I never actually retested the form. So, I probably lost the property set before the upgrade.

                  Hopefully, this helps someone else.
                  • Interesting. Thanks for reporting that.
                      Did I help you? Buy me a beer
                      Get my Book: MODX:The Official Guide
                      MODX info for everyone: http://bobsguides.com/modx.html
                      My MODX Extras
                      Bob's Guides is now hosted at A2 MODX Hosting