We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 3749
    • 24,544 Posts
    You did do an upgrade install, right?

    If so, the most likely causes are:

    1. Some files didn’t get overwritten when you upgraded.

    2. File or directory permissions got changed when you upgraded.

    3. One or more of the new files got corrupted or missed in the transfer.

    One solution is to do a fresh install of MODX 2.1.1 with a new database, and if that one works, copy the manager files (except config.core.php) to your main install. If that doesn’t do it, copy the core and connectors files (except config.core.php and core/config/config.inc.php). Once it’s working, delete the fresh install and its DB.
      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
      • 1892
      • 82 Posts
      Thanks for the help,

      The ftp upload did flag a few errors but as it was flying through the 7,000+ files it was hard to see what problems there were.

      So I downloaded the existing core directory to my local machine, over wrote this with the core directory from the upgrade, changed permissions and then uploaded it in entirety back to my provider. The resource side bar is still missing!

      So I’ll try your next suggestion and do a clean install, if that works for me then I’ll think I’ll then try a diff on the two directories as I’d like to now what’s going wrong for future reference. Although time limited at the moment so it might be a few days before I can try the next stage.
        • 22286
        • 9 Posts
        I believe this is a legit bug. There are three threads on the subject:

        http://modxcms.com/forums/index.php/topic,65924.0.html
        http://modxcms.com/forums/index.php/topic,65217.0.html
        and this thread.

        Incidentally the fresh install hung for me on 2.1.1 as well at the "install" stage. I’ve installed quite a few MODx installs before and have never seen this.
          • 1892
          • 82 Posts
          I think I’ve fixed it on my installation, but would be interesting to see if it’s the same for anyone else. Basically I did a clean install on my localhost machine and ran through all the proposed solutions.

          Eventually got to replacing the connectors directory as suggested by Bob and clearing the cache which fixed it, so I ran a diff on that directory between the clean install and the upgrade. There were two file differences,

          First was connectors/layout/mod.config.js.php

          The upgrade version
          <?php
          define('MODX_REQP',false);
          require_once dirname(dirname(__FILE__)).'/index.php';
          $_SERVER['HTTP_MODAUTH'] = $modx->site_id;
          $modx->request->handleRequest(array('location' => 'system','action' => 'config.js'));


          Whereas the clean install file is
          <?php
          define('MODX_REQP',false);
          require_once dirname(dirname(__FILE__)).'/index.php';
          $_SERVER['HTTP_MODAUTH'] = $_SESSION["modx.{$modx->context->get('key')}.user.token"];
          $modx->request->handleRequest(array('location' => 'system','action' => 'config.js'));


          There was a similar difference in connectors/system/phpthump.php

          So I changed the two files on my upgrade site
          mod.config.js.php
          <?php
          define('MODX_REQP',false);
          require_once dirname(dirname(__FILE__)).'/index.php';
          /*$_SERVER['HTTP_MODAUTH'] = $modx->site_id;*/
          $_SERVER['HTTP_MODAUTH'] = $_SESSION["modx.{$modx->context->get('key')}.user.token"];
          $modx->request->handleRequest(array('location' => 'system','action' => 'config.js'));
          


          and phpthumb.php
          <?php
          require_once dirname(dirname(__FILE__)).'/index.php';
          /*$_SERVER['HTTP_MODAUTH'] = $modx->site_id;*/
          $_SERVER['HTTP_MODAUTH'] = $_SESSION["modx.{$modx->context->get('key')}.user.token"];
          $modx->request->handleRequest(array('location' => 'system','action' => 'phpthumb'));


          I cleared the cache and reloaded the manager and lo and behold the navigation tree appears and works as expected.

          So I’d be interested to know if this fixes for the other reported problems.

          I don’t really know how the upgrade modifies these files, so I’m not sure whether it’s something wrong with my setup or is it something that needs filing as a bug?

          Anyway I hope this helps.

          Adrian


            • 11055 ☆ A M B ☆
            • 3,112 Posts
            would you please put this on http://bugs.modx.com ?
              Rico
              Genius is one percent inspiration and ninety-nine percent perspiration. Thomas A. Edison
              MODx is great, but knowing how to use it well makes it perfect!

              www.virtudraft.com

              Security, security, security! | Indonesian MODx Forum | MODx Revo's cheatsheets | MODx Evo's cheatsheets

              Author of Easy 2 Gallery 1.4.x, PHPTidy, spieFeed, FileDownload R, Upload To Users CMP, Inherit Template TV, LexRating, ExerPlan, Lingua, virtuNewsletter, Grid Class Key, SmartTag, prevNext

              Maintainter/contributor of Babel

              Because it's hard to follow all topics on the forum, PING ME ON TWITTER @_goldsky if you need my help.
              • 1892
              • 82 Posts
              As requested

              http://bugs.modx.com/issues/5185

              Adrian
                • 22286
                • 9 Posts
                I don’t seem to have permission to register on the bug tracker, but I can confirm that apcherry’s solution fixed the issue for me.
                  • 1892
                  • 82 Posts
                  Thanks for letting us know, glad to have helped.

                  I’ve just tried the 2.1.2 (advanced) upgrade, unfortunately this overwrites the modx.config.js.php and phpthumb.php files with the faulty code.

                  If you upgrade you’ll probably have to apply the same patch again.

                  Regards

                  Adrian Cherry
                    • 22303 MODX Staff
                    • 10,725 Posts
                    This is not a bug; you are not making sure that all files in your deployment are writable and this is required when running the advanced upgrade. Also, make sure you do NOT check the "Core Package has been manually unpacked" or "File already in place" checkboxes — these should be unchecked for the advanced install by default and should NOT be changed or the installer will run successfully using the previous release’s package which is already extracted to core/packages/core/ (unless you manually removed it) before you start the upgrade.
                      • 1892
                      • 82 Posts
                      Thanks for that, on going through your check list the problem I’ve got appears to be the checkbox "Core Package has been manually unpacked" is CHECKED.

                      Now I’m fairly sure that I didn’t fiddle with anything I just did a standard advanced install. Still I unchecked this box and the install works fine.

                      So going back to the checkbox because as I say I don’t conciously remember changing any of the settings. So I decided to dig a bit further and I found the /setup/controllers/options.php file with the following bit of code
                      $manifest= 0;
                      if (file_exists(MODX_CORE_PATH . 'packages/core/manifest.php')) {
                          $manifest= 1;
                      }
                      
                      $unpacked= 0;
                      if ($manifest && file_exists(MODX_CORE_PATH . 'packages/core/modWorkspace/')) {
                          $unpacked= 1;
                      }


                      When I look at my modx site the file ’packages/core/manifest.php’ is still there from the previous version so manifest is 1, also the directory ’packages/core/modWorkspace/’ also exists so unpacked is then set to 1, which sets the checkbox to enabled.

                      So yes the solution is to make sure the ’manually unpacked’ in NOT CHECKED which is something I hadn’t spotted. However I’m not sure that this is the default. With the code in options.php this checkbox seems to be set to enabled by default if the two files ’packages/core/manifest.php’ and ’packages/core/modWorkspace/’ exist, which they do in my installation of modx. Is the script supposed to clear these files before installation or post installation, or are we suppose to delete these prior to the upgrade?

                      Regards

                      Adrian